Roadmap towards IPLD

[nicola]

Let's collect the IPLD bigger picture here

cc (@jbenet, @mildred, @dignifiedquire, @Stebalien)

• new org - (Moving IPLD into its own org #128): move implementations and specs under https://github.com/ipld
• spec refining:
  • cycles/relative links (Spec refining: Relative paths in IPLD ipld/specs#1) - If we add relative links in merkle links, then we can have mutual relationships.
  • attributes in / (Spec refining: Properties in links ipld/specs#2)
  • Find a name space: '/ipld' or '/ipfs' or just hash
  • Use of IPLD pointers as links (Spec refining: Support of IPLD pointers as links ipld/specs#3): right now implementation only support hashes
• query - way to find attributes (or value) that is easy to express (instead of programmatically traversing a tree)
  • selectors (Session Proposal: Designing IPLD Selectors ipfs-inactive/2016-IPFS-Workshop-Lisbon#5 and IPLD Selector notes#12)
    • design/find a nice language
    • research on relational db in directed graph
    • must be simple, fast, reliable
    • must create virtual graphs
  • full query language (later 2017) - more complex query than simple selectors
    • could be unreliable (unless specified)
    • design a query language
    • should create virtual graphs
• programmable data & transformations (Transformations and Crypto #102)
  • IPC (inter-planetary computation) - decentralized compilable computation
  • Transformation - subclass of IPC (but pure, functional and return a graph/value)
  • IPLD objects can be input to IPC or can define transformations in the data itself
  • talk to the functional programming language research folks
  • could be writing contracts & smart signature (?)
    • infinite computation should be possible
    • possible languages to consider
      • web assembly
      • haskell
      • javascript
      • morte
      • LLVM IR
        • maybe there is a need for multipl (multi-programming or multi-language)
• verifiable computation on IPLD
  • consider simplifying lambda auth as a lib in haskell
  • consider extending IPRS, IPC(IPLD)
• abstract paths (Abstractions in IPLD: high level and low level data representations #91)
  • should be able to express abstract paths via transformations
  • could do sharding (consequence of programmable data)
    • is sharing application specific?

I will clean this up in different issues

[Kubuxu]

I will like to add my one cent:
As IPLD will change hashing we can use it to introduce some other changes that would break hash compatibility like for example limiting block size to one that is friendly for storage (proposed is 256KiB) - ipfs/kubo#2122

It would be great to add it to the road map.

[davidar]

possible languages to consider

• Morte: Morte apps#6

[Kubuxu]

I think WebAssembly is one of the best candidates for wire format there is. Code is stored in AST (abstract syntax tree) which allows for very low loading times (as AST is something most interpreters and JITs will process the code to, no need for parsing). The lowest level language (as it is AST) shares a lot in looks with LISP.

WA comes in as bare as language can be. All more advanced functions (for example i/o) have to be requested as a module.

[daviddias]

Moved to ipld/specs#41