Demos
Hi, last week, we were exposing some ideas to Victor, and he suggested to do a demo at the IPFS hands-on call of the tool that we've been building.
The quality of the call was a little choppy and it was suggested to record a video and add an issue here. So we did a little video demo.
You can also play around with the latest version
Why & where
Finding out why we're doing this is part of the project itself, and we're in a process of dumping our brains into markdowns.
The tool was originally called ipld-mindmap, but we recently did an overall merging/renaming of repositories.
In any case, code, documentation and reasoning live now under the same roof:
https://github.com/interplanetarymindmap/mind-map
Help
David, at the end of the call, asked, how can we help you with?
I'm extremely grateful for all your work and approach to long-term solutions. I understand that some stuff is not ready yet, and it needs its time. No rush :)
Most of my time around the IPFS/IPLD repos have been trying to wrap my head around the IPLD format itself and also around the links. Here there is some stuff that I would love to have...
Solid specs with nice documentation:
- For example, the IPlD specs repo has an
OUT OF DATE in the title, but there is no alternative link.
- I had to read tons of issues and discussions to kind of get an idea of what the state of the art is.
- The uncertainty of not knowing if I'm checking the right stuff takes a lot of energy.
A unified protocol/format agnostic resolver for Merkle-paths/CIDs:
- Right now I need to parse the link to figure out if its an IPNS or an IPFS link.
- And I can only resolve an IPLD object using the ipfs.dag.get API.
- So first I need to abstract the CID because of the ipfs.dag.get API only supports CIDs
- And then check if the CID is a dag-cbor or a dag-pb, to know if I can use the API.
- If its none I use ipfs.files.cat API (with an IPFS link)
- Otherwise, I use the dag.get API (with the cid)
Typed IPLD objects
- I want to eventually represent any IPLD object on the mindmap.
- Knowing how it is formatted can lower the number of assumptions I need to do render it coherently.
- It would be nice to know if the object is an Ethereum block (independently of the serialization format) for example.
- It would be nice something around the lines of self-descriving Multiformat (no idea how)
Strictly typed JS implementations
- I've seen discussions around Flow vs Typescript in the issues.
- I don't think they're used anywhere though.
Your input
- In the form of pull-requests/ideas/references/corrections...
- We're in Berlin for Web3 summit and we will be in Prague for Devcon. If any of you are around, we would love to catch up.
Aloha!
Demos
Hi, last week, we were exposing some ideas to Victor, and he suggested to do a demo at the IPFS hands-on call of the tool that we've been building.
The quality of the call was a little choppy and it was suggested to record a video and add an issue here. So we did a little video demo.
You can also play around with the latest version
Why & where
Finding out why we're doing this is part of the project itself, and we're in a process of dumping our brains into markdowns.
The tool was originally called ipld-mindmap, but we recently did an overall merging/renaming of repositories.
In any case, code, documentation and reasoning live now under the same roof:
https://github.com/interplanetarymindmap/mind-map
Help
David, at the end of the call, asked, how can we help you with?
I'm extremely grateful for all your work and approach to long-term solutions. I understand that some stuff is not ready yet, and it needs its time. No rush :)
Most of my time around the IPFS/IPLD repos have been trying to wrap my head around the IPLD format itself and also around the links. Here there is some stuff that I would love to have...
Solid specs with nice documentation:
OUT OF DATEin the title, but there is no alternative link.A unified protocol/format agnostic resolver for Merkle-paths/CIDs:
Typed IPLD objects
Strictly typed JS implementations
Your input
Aloha!