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

Stackstream possibilities #25

Closed
krl opened this issue Jul 8, 2015 · 0 comments
Closed

Stackstream possibilities #25

krl opened this issue Jul 8, 2015 · 0 comments

Comments

@krl
Copy link

krl commented Jul 8, 2015

stackstream

I'm getting more and more convinced that stackstream is the way to go, here are some examples on what would be possible.

No link/data separation

Instead of having objects contain links and data, we implement interfaces in the objects themselves.

Objects support commands, that can be thought of as interfaces. For example a unixfs directory would support

ls, <linkname> resolve

a unixfs file would support

<offset> cat

This solves the problem of having a discontinuity between the actual links in objects, and the files a folder contains. If the fanout is explicit for large folders, we get something like:

/ipns/whatever/hugefolder/0/3/3/subdirectory

This is clearly not what we want, this is much better:

/ipns/whatever/hugefolder/subdirectory

However, with the current explicit linking, this will need some extra logic to resolve, the parser needs to know about the type and specific fanout structure of the object it wants to resolve through.

If the stackstream in the objects can request its implicit fanout objects, and just present the result to the parser, we're much better off.

Replication

For replication, instead of looking at the link table, the ls command is used, this should by definition do a full traverse, and also pull all the intermediary tree nodes (the idea is that it has to look at all the nodes to get all the subdirs).

Blockchains

Another great application for stackstream would be ad-hoc blockchains.

The genesis block is defined with a validity function, the validity function is basically that which checks if a given new block is a valid successor. The simplest example would look something like this:

genesis (G)

G cat -> "this is my very own genesis block"
G pubkey -> <somekey>
G signature -> signature over (G cat)
G valid -> <validation fn (stackstream)>

G' cat -> "This should be the second block"
G' pubkey -> <somekey>
G' signature -> signature over (G' cat)
G' valid -> <validation fn (stackstream)>

G' G valid -> Truthy if block is valid according to (G valid)

This is basically a blockchain that can only be appended to by someone holding a specific private key. This could easily be extended to do M of N multisig chains.

The validity function could also be proof of work.

G valid -> (check if hash G' < threshold)

Threshold could also be updated every N blocks, like in Bitcoin.

A Bitcoin blockchain mirroring could be implemented in stackstream as well, it would just need to speak secp256k1, and then any interested node recieving a stackstream version of the bitcoin block would just append it to its local log.

One thing that falls out of this, is that it's possible to have blockchains that actually change their valitity function as it goes along. For multisig, this would allow the set of keys to be changed, so that people can for example be added and removed from the official ipfs release chain.

Along with this, a special ipfs request could be, 'give me the longest chain starting with G'

This requires an additional mapping from genesis -> longest known chain.

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

3 participants