Keychain depends on IPFS

[Download]

IPFS depends on libp2p. Correct me if I am wrong.
So conceptually it seems weird to me to see libp2p specs being defined in terms of IPFS specs...
But if you check the README of Keychain:
https://github.com/libp2p/js-libp2p/blob/main/packages/keychain/README.md
It says:

Physical storage

The actual physical storage of an encrypted key is left to implementations of interface-datastore.

I understand Keychain is only using the interface-datastore from IPFS. But conceptually this seems wrong. It just seems very weird to have libp2p being dependant on IPFS like this. I guess the best thing maybe would be to extract the interface-datastore out from IPFS the way they did with microformats (and libp2p itself).

Just wanted to mention this here as I think it does betray a problem in the way this is structured currently.

[achingbrain]

Moved this from issues to discussions since this isn't a bug report or a feature request.

The problem as I see it is that the js-stores repo happens to be in the IPFS GitHub org.

I suppose this is interesting from a governance point of view, particularly with the newly formed libp2p foundation being increasingly separate from IPFS, though from a practical perspective the various store interfaces/implementations are very low churn - creating a separate GitHub org to hold them creates a lot of administrative overhead so I'm not sure it's a good long-term time investment.

It could be moved to the libp2p org, though I'd say this is fairly low priority.

[MichaelJCole]

Some feedback on this since it's a discussion :-)

I've been looking to use libp2p/ipfs and gave up on using anything from the go/kubo world because because it links 47 repositories and who knows what it's doing.

The same thing is happening in the javascript ecosystem with dozens of repos.

Extracting all these packages into separate repos creates an extraordinary amount of work and makes documentation and refactoring impossible. There are dozens of dead links in the documentation.

It is extraordinarily difficult to access the value of js-libp2p and helia.

That repo literally describes itself as "internals" - "Blockstores and datastores used by IP-JS internals"

It's one thing to put examples and documentation in a separate repo, but extracting out interfaces is shooting ones self in the foot.

From my perspective, this ecosystem is to unstable and poorly documented to be extensible, so all this abstraction is alot of extra effort for very little value.

Express and it's middleware ecosystem is so extensible because the interface is so trivial (req, res, next). Express could do that because HTTP had been defined for decades and everyone knew what web server should and shouldn't do.

libp2p and helia don't have that foundation to build on.