I was looking at the code and something caught my attention. I see that instantiating a peer would spin up a goroutine that would wait on the context.Done channel and then close some of the underlying dependencies.

https://github.com/hsanjuan/ipfs-lite/blob/master/ipfs.go#L128

I might be wrong, but it seems like there's no way to wait until this shutdown process is actually finished. The autoclose goroutine is not signaling anywhere when it's done.

Wouldn't it be more correct to provide explicit Close method so that users of ipfs-lite could chose to wait until the peer is actually closed? Another approach could be providing an explicit Start method that would block and could accept a context for being canceled.

When I build the example file on ipfs-lite/examples/litepeer/litepeer.go I get the following error

> go build ipfslite.go
# command-line-arguments
./ipfslite.go:21:8: undefined: ipfslite.NewInMemoryDatastore

The gocid version is too old to support the parsing of the k51qzi5uq******** format CID.

Hi, we need to update ipfs-lite to use the bitswap provider, because of this:

../go/pkg/mod/github.com/ipfs/[email protected]/format.go:131:16: undefined: cid.CodecToStr

go-cidutil is out of date.

Hello,

What about adding IPFS PubSub feature to ipfs-lite?
did you already try that?
did you find some difficulties implementing it?

I know it's one more feature which may not fit the lite side of this project, but it opens a lot of new area to explore on IPFS, especially for projects like grpc-ipfs-lite, android-ipfs-lite, and so on... which are based on ipfs-lite.

Let me know your thought.

Hi,
I just ran into a strange situation, which is probably not caused by ipfslite itself, but it's a starting point for my inquiry. I run a few servers with ipfs peers, and my executable uses ipfslite (albeit a bit older version, 1.4.2). For peer database, it uses badger storage. I found 55Gb of data on one server, and 58Gb on the other. I was wondering, is this to be expected, or maybe it has something to do with the storage choice. I have some other peers running ipfslite, but using MongoDB as the storage for the peer database. To what I can see, they don't have this problem.

Thank you - any info would be appreciated.

I have noticed some changes in go-libp2p-core and it would be nice to have the latest stable and usable versions.

Currently go-libp2p-core is set to v0.0.3, while v0.0.6 is out there (and it brings a set of breaking changes. semver convention missing here). Not required, but to avoid problems it would be nice to have it upgraded!

IPFS is creating Rust versions. Simple as ipfs-lite is, it can prove how IPFS would be fully on Rust.

Does this support joining private IPFS networks with Swarm keys?

This project looks promising :)
It would be nice to add some examples to how to use it

This library does not re-provide DHT records. So after 24h of adding anything to the DHT they will expire.

package main

import (
	ipfslite "github.com/hsanjuan/ipfs-lite"
)

var ipfsNode *ipfslite.Peer

func main() {}

for me crashes with

panic: duplicate metrics collector registration attempted

goroutine 1 [running]:
github.com/prometheus/client_golang/prometheus.(*Registry).MustRegister(0x4b00469?, {0xc000796b60?, 0x1, 0x12?})
        /Users/marcel/go/pkg/mod/github.com/prometheus/[email protected]/prometheus/registry.go:403 +0x7f
github.com/prometheus/client_golang/prometheus.MustRegister(...)
        /Users/marcel/go/pkg/mod/github.com/prometheus/[email protected]/prometheus/registry.go:178
github.com/libp2p/go-tcp-transport.init.0()
        /Users/marcel/go/pkg/mod/github.com/libp2p/[email protected]/metrics.go:37 +0x1b3
exit status 2

go version

go version go1.18.1 darwin/amd64

go.mod

go 1.18
require github.com/hsanjuan/ipfs-lite v1.4.0

Also tested with v1.3.0. It's weird cause the library used to work with me. Paused the work on my project for ~2 weeks and can't get it started now. But I also isolated the issue fairly much so I don't know what is going on :/ Any idea?

I am currently using the ipfs-lite along the ipfs daemon on the same host. I have a private swarm for the ipfs daemon that is independent from ipfs-lite's swarm. I communicate between the nodes and share state using go-ds-crdt, which is powered by ipfs-lite as shown in the example in the go-ds-crdt repository.

However, I observe some strange behaviour in the ipfs daemon when ipfs-lite is running along:

• Some nodes cannot download data from certain other nodes. The node that cannot download data can swarm the other nodes and see them as providers of the data. However, they cannot download the data (neither using the gateway nor using ipfs get.)
• When I stop ipfs-lite, the node can find the data and download it.
• It seems running ipfs-lite along ipfs daemon creates confusion for the nodes in terms of routing, even though ipfs-lite is using in memory datastore and a different dht etc.
• I set up ipfs-lite following the example from https://github.com/ipfs/go-ds-crdt

I was wondering if this behaviour is expected?

I'm assuming this implementation still keeps a repo (assuming by the datastore requirement). Doest it make sense to include the GC and the pinning/unpinning methods?

There might be cases where an application might want to retain the files besides adding to/ retrieving from network.

Would that be something to consider including into a Lite version?

would it be possible to add a file wrapped in a directory with this library?

Dependabot was set up to create pull requests against the branch dependency-upgrades, but couldn't find it.

If the branch has been permanently deleted you can update Dependabot's target branch from your dashboard.

View the update logs.

Hi, I ran into a weird problem. I am using ipfs-lite in a distributed database project. The nodes in the ipfs network are using ipfs-lite to store and fetch json data structures. Each cluster is isolated in a private libp2p network using a PSK. A MongoDB collection is used as key-value storage.

Things are generally working very smoothly, but recently I noticed a newly spun node is not picking up data from the ipfs network (and it is supposed to replicate whatever the network has). After a week of digging, I found out that some dags are stored without the /blocks prefix, so instead of
/blocks/CIQDACE5RYSBN36AFODMQM6JQ7EITZ3GXYC32H5CVR2IM562R3WVTYY
I am finding
/CIQDACE5RYSBN36AFODMQM6JQ7EITZ3GXYC32H5CVR2IM562R3WVTYY
Otherwise, the dag data is ok.

The whole problem seems to originate from a while back (anywhere between 2 and 12 months ago). I only ran into it because accidentally many nodes in one of my networks died, and this was the only node left standing. So this node became an accidental "source of truth" for all content. And the content was there, however ipfs-lite was not able to load it because of the malformed keys. And it was also not able to fetch it via bitswap because no other nodes with content existed at the time. Working in a private libp2p network seems to be quite dangerous in this regard.

To confirm the bug, I checked out nodes on the other networks I have running, and indeed all the older nodes have a number of these malformed keys. Some have a set of correct keys, then a set of malformed keys, then again a set of normal keys. Since I was upgrading and fixing the executable over time, my theory is that at some point my executables were writing dags with faulty keys, and the behavior stopped after an update. But I have no way of knowing exactly when any of this happened.

My question is - would you happen to have any idea on why the keys were malformed? I see that ipfs-lite is actually not implementing dag.Get() and dag.Put() method, and is instead using the default implementation. So whatever happened must have been in a related package, not in ipfs-lite as such. But you're my best starting point :)

I am fully aware the problem is complex and not easy to explain, so if you need any further info, I'll be more than happy to provide it. Thank you in advance.