Hey everyone! Just wanted to say hi to the community and let you guys know about my C++ implementations for multiformats and libp2p. Right now multiformats is mostly complete, and I’m about to jump into libp2p soon.
There are currently some other C++ implementations out there, but I wanted to aggregate a bunch of the smaller modules into their umbrella projects, and use the conan package manager for its flexibility. Down the road I plan on adding on a C interface, and Windows, MacOS and WebAssembly targets.
And of course, I’d welcome anyone wanting to work on these implementations with me!
For us idiots who can’t be bothered to type “multiformat” into google, what’s the four-sentence summary of what it is, and when I would ever need to use it?
multiformats is a collection of self-describing protocols, and they are a low-level dependency of libp2p and IPFS. I should mention that I do plan on implementing a C++ IPFS, but it will have to wait until the libp2p project gets on its feet.
Ahh! So a “C++ IPFS” means the daemon, not the client side?
There’s a client side C++ IPFS implementation at https://github.com/vasild/cpp-ipfs-api but its incomplete (I’m currently struggling with how to get access to IPNS with it, to create mutable files). I’m also interested (I think) in IPLD, since I want to have a custom linked-data format (that’s not files, git, etherium, etc.) but again, haven’t quite figured that out yet. I’m slightly concerned that it might be slow-ish (I want to pump around high volumes of very small linked objects)
I had vague hopes that multiformat might help with some aspect of that, but I guess not? It will help others if you add to the README “multiformats is a part of the core protocol of IPFS and lib P2P and etc.” - like a paragraph to explain it to newcomers. Might it talk to secure scuttlebutt?
Considering that that project looks like it hasn’t really seen any love in the last couple years I might want to implement both client and daemon.
multiformats does spec the CID, and considering the age of the repo it might only be able to handle CIDv0 and not CIDv1 and that might be what you’re having troubles with. As for IPLD, I haven’t read into it yet – it seems to be a dependency of IPFS and not libp2p? so I had figured that that would have been on the road to the IPFS implementation.
Thanks for the note on the documentation, I don’t conform to the README spec yet, so I’ll file that issue.
As for secure scuttlebutt, are there other implementations that work with it? I think I remember seeing something about them migrating to libp2p but I’m not sure if that was a suggestion or decision. But hey, I don’t see why we not in either case.
SSB has 3 or 4 or 5 differeint clients, in various programming languaages and platforms (e.g. one is on Android, another on Apple).
It’s interesting to me because, well … the first SSB app is a social-media app, and it works, and there’s lots of intersting lovely people there; I like them. It’s technically interesting, because it works off-line: you can read/post the social media posts when you’re offline, and it syncs back up when you’re online. It even has some kind of LAN-sync thing on local networks. It’s technically interesting because the cryptography behind it is impressive, seems to be a cut above. In principle, one could build all kinds of apps on top of it. In practice … I haven’t tried.
The syncing is interesting: it syncs with those nodes that you’ve declared to be your “freinds”, and then downloads updated data to N hops out (typically, N=1 or N=2) As far as I can tell, there’s no DHT or global namespace. So, for example, during chat, you can #hashtag some topic, but I’m not clear on how all other posts with #hashtag are discovered/downloaded. This may be an issue with the social media cleint, or it might be an issue at the deep protocol level. I don’t know.
Anyway, this is all very off-topic. I will make pull reqs to the IPFS C++ client bindings, if I can figure out what needs fixing and find the time to do it.
So, what is fixed? Have you tried figuring out what needs to be fixed?