You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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
a unixfs file would support
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:
This is clearly not what we want, this is much better:
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:
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.
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.
The text was updated successfully, but these errors were encountered: