Hi! thanks for your interesting answer. Certainly it helped me to see the big challenge to implement IPFS using Elixir. I’ll try to understand the ibgib.

I also think IFPS iss approaching the transport layer.

Thanks again and good lucky!

Here is the code GitHub - ipfs/kubo: An IPFS implementation in Go · GitHub

Well, that is a huge, non-trivial question!

They’ve been at it according to github for a couple years now, with over a hundred of contributors and almost 200 current branches! So, you would need to ask not only an elixir expert, but also a IPFS expert - which I’m not sure if there are any experts in both (yet)!

That said, and with the caveat that I know next to nothing of their actual code implementation, I have been learning about how they’re structuring it conceptually. I can tell you that ibgib has many similarities with their goals. I’m using a mechanism that is very merkle-esque. Briefly, the data structure for ibgib is ib, gib, data, and rel8ns. The ib acts as a non-unique identifier, and the gib acts (usually) as a sha-256 hash of the ib, data, and rel8ns (i.e. the “content”). This is the only data struct in the application, as the actual content of the ibgib populations (persisted in the repo) contains the actual “data structures”. As such, it is also a monotonically-increasing database, with no deletes (no “unlinking”). So if you have an ib^gib address, then you have the address to a unique, immutable thing.

So the “heart” as he calls it, the merkle(ish) dag, is there.

Ibgib does not however concern itself with the transport layer, as it is strictly agnostic to how these data get created. And since the gib acts as a hash, it should not matter what the transport layer is. I think (perhaps!) that they’re more interested in supplanting current http infrastructure, and that just isn’t something I’m remotely interested at attempting to do.

But the one big foundational concept is the one he discusses about distributability. Because of this end goal in mind, I have created each individual ib_gib as a process. It is an “immutable state” process, but a process nonetheless. This way, in the future when it grows from a single repo and a single node to a cluster of nodes and whatever db substrate implementations (because the db is just a persistence mechanism), any users can talk to any of their “local” ibgib processes to interact with.

But one of the big problems with using Elixir, and this is probably important for you with regards to your question, is regarding what he discusses in the video you linked as the “offline” disconnected scenario. In order to effect this, you have to be able to have the engine running on any client. This is similar to how git can operate locally on any node and then merge changes/interact with servers, as the servers are just other nodes in the merkle dag.

Elixir, at the current time, only runs where erlang (the BEAM!) runs, and as best as I can tell, that does not currently include apple iOS or Android. Perhaps this is why the IPFS team is approaching the transport layer?

Anyway, I have no idea if this helps you on your question, but I just had to go ahead and respond because IPFS looks very interesting!