One problem is that ipfs data will leak, as there isn't a way of disposing of it. And since it's content addressed you'll need to ref count the blocks as the data is deduplicated.

To get "ipld" support you just need to implement the ipld store traits, you can easily do that, and then you get all the ipld codecs and ipld collections for free.

I was planning on reimplementing bitswap as a light client notification protocol, but it doesn't seem there is a way to perform the get-providers dht query from the NetworkService. This would be an alternative that would also work for us. I'm going to make the entire network implementation of ipfs-embed replaceable so that I can drop in the light client. The db is already shared between ipfs-embed and the light-client.

@tomaka do you think exposing get-provider and start-providing in NetworkService could be a faster way forward?

This PR doesn't do anything related to the DHT yet as far as I can tell, but one thing to be aware of is that we're customizing the name of the Kademlia protocol to include the id of the chain, as a way to prevent nodes from different chains from connecting to each other.

I suppose that it would fundamentally be better to also connected to a shared DHT, or to IPFS itself, rather than to only the DHT of a specific chain. However, this would be problematic as we are already now suffering from problems caused by the high number of TCP sockets.

a light client notification protocol

Request-response protocols, added in #6634, would be more appropriate I think. They are similar to RPC queries, whereas if you try to emulate request-reponses on top of notifications you will suffer from all sorts of issues.

@tomaka do you think exposing get-provider and start-providing in NetworkService could be a faster way forward?

That'd be totally reasonable.

This PR doesn't do anything related to the DHT yet as far as I can tell, but one thing to be aware of is that we're customizing the name of the Kademlia protocol to include the id of the chain, as a way to prevent nodes from different chains from connecting to each other.

This is what we want as we're using custom codecs and hashers based on the sp-trie module. We have a prototype "chain" pallet that let's you deal with comonalities between chains of ipfs blocks that store user or team data. The "chain" pallet has a list of "authorities" that are allowed to update the head and prove that the ancestor was the previous head. We found this pattern useful for data that is not interesting for all users, like for example your "twitter feed" and where users can follow one of these "chains" to both get updates and replicate the blocks. In the far future we can maybe leverage a more sophisticated incetivized availability system.