Skip to content
This repository was archived by the owner on Feb 8, 2023. It is now read-only.

Small Languages for IPLD things (like IPRS) #229

Open
jbenet opened this issue Mar 8, 2017 · 7 comments
Open

Small Languages for IPLD things (like IPRS) #229

jbenet opened this issue Mar 8, 2017 · 7 comments

Comments

@jbenet
Copy link
Member

jbenet commented Mar 8, 2017

Some things, like IPRS, IPLD Transformations, and more, will want to create objects/entities that carry code (or really, point to code). This code would be used for things like Validity schemes (IPRS), file importers (DEX/IPFS), arbitrary IPLD Transformations.

I would imagine that "IPRS Validities" and "arbitrary IPLD Transformations" require different things from the languages. but each need some subset of:

  • pure
  • turing complete or non turing complete
    • depends on the application. IPRS validity probably doesnt need it
  • terminating
  • formally verifiable / verified
  • compilation to wasm
    • so that we can unify execution later.
    • wasm is seeing a ton of valuable research and we'll see tiny VMs coming soon

cc @nicola @cleichner @mildred @diasdavid

@whyrusleeping
Copy link
Member

cc @zignig, who voiced interest in this topic the other day in IRC

@mildred
Copy link

mildred commented Mar 8, 2017

I'll answer here specifically for the aspect of using such a language for IPRS. I agree this would be nice to have a language that defines the validation schemes. There is however two aspects of this I'd like to discuss:

  • First, the complexity of having to implement a language in every DHT peer is probably not negligable. Having different compatible implementations may be more difficult. The footprint of the implementation itself might also be a problem. A malicious verification scheme could bring down the network, or prevent peers with not enough processing power/bandwidth/memory to function. Alternatively, the language could be too restrictive for some applications.

  • It is possible to design a way to exchange records in the DHT where validation happens only on interested peers (providers and requesters). This allows to keep simple peer implementations, enable application-specific schemes, and allows experimenting on validation schemes before they are specified formally. Only some peers on the network needs to implement these specific schemes. I discussed this in detail in Record validation issue with multiple naming systems libp2p/go-libp2p-kad-dht#50

@zignig
Copy link

zignig commented Mar 9, 2017

Most of the investigation I have been doing is into FORTH , I am currently translating the (https://github.com/zuloloxi/mecrisp-ice) pascal emulator into golang.

Forth is a bit cryptic , but it is pure , turing complete and compact.

It also fits in quite nicely with content addressed systems as it can be imaged based , so you can put all codes and rules into verifiable blob.

Hooking it up to IPFS should be straight forward in golang but the interface will need to be planned carefully.

@void4
Copy link

void4 commented Mar 9, 2017

This topic is confuzzling me for some time now. You are trying to build a system in which most data structures are based on the IPLD canonical format. In order to (de)serialize the data, some kind of metaprotocol is needed, these are the multi* prefixes. These definitions have to be maintained by some form of consensus, which could anything from a table in a RFC document or in the most dynamic but also most rigorous case, as a program in some language. IPRS validation and IPLD transformations have very similar requirements. What I'm seeing here is that you look for such a language to be on top and/or independent of the IPLD format. However, it would be possible to do both in the same format, provided you use a homoiconic language. I'm not sure if this is a reasonable idea, it might be batshit crazy, but whatever.

For example, why not use DAGs to transform DAGs?
void4/notes#5
Meta AF, I love it.

Edit: I'll elaborate my thinking a bit further: What is the objective of "Web3" projects such as IPFS and Ethereum? It is making the web more powerful, enhancing machine collaboration (e.g. resource sharing) and human computer interaction. The "common language" of todays web is incredibly weak when compared to the possibilities of a distributed virtual machine. If the Inferno operating system or similar endeavors had succeeded, we wouldn't have these limitations today. Current OSes cannot provide developers with a cross-platform "thin waist" for application development, so the inner-platform effect continues. If Web3 projects were to succeed, current web browsers and applications had to implement all their definitions and languages. I hope, but am not sure whether WebAssembly can provide a good solution for this.

@kumavis
Copy link

kumavis commented Mar 14, 2017

FWIW @wanderer and @axic have a wasm transform to inject op metering into arbitrary wasm code. this would allow you to allocate some amount of computation for some untrusted code, and halt if it does not exist in the allotted compute time

@kumavis
Copy link

kumavis commented Mar 14, 2017

could i use ipld transformations to cast generic binary data as a link with a cid type?

e.g. generic ethereum trie built from generic rlp objects, transformed so that the raw binary values encoded at the leaves are interpreted as ethereum-accounts

if so, might be a usecase to consider for language design

@daviddias
Copy link
Member

ipld transformations to cast generic binary data as a link with a cid type?

Yep! In fact, you were already doing some IPLD Transformations when you made ipld-eth-block (and the others) because the way to traverse and eth block through using the resolver should be just referencing the RLP array and yet, today you can do things like <cid of ethblock>/parent. We will need to change this to be 100% spec compliant, but we also can continue experimenting until we have a formal IPLD Transformations spec.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants