expand_less
I've been investigating and deep design work on using the ipfs/ipns abstractions in the Decko ecosystem. Starting from the storage and distribution end, If we store Decko content in a Merkel tree representation, content objects within it, that is the trees and blobs in each Decko instance at initialization and as local changes accumulate, then we can put these hash pointers to immutable trees to good use. For all the content that is "read everyone", it is ok to share data over ipfs and represent it as hash pointers. A handful of initial hash pointers to content is all you would have to actually copy to start an instance, the rest of the published initial content.
That is the immutable parts, the creation of a local instance would necessarily involve creating mutable objects in ipns. A process would need to trace the initial content from the hash pointer for the latest release, and that would instantiate content references by tracing paths through the namespace. The content still unchanged from initialization, or updated in a new release would be referenced from the decko.org namespace. Local changes would get new signed entries that can replace references to other namespaces. This process would be a lot like managing a git workspace. Local changes are made to trees and blobs and a commit is created that references these updates and the original tree. While in process of preparing a commit, you have an action like git status that tells the differences between 1) the tree you are building on., 2) The changeset staged to be committed, and 3) the contents of the workspace. Similarly, we will have 1) as the current /ipns/MyDomainID/ 2) /ipns/MyStageID could be a possibility, and 3) local or server copies of trees and blobs.
{ {"Left": "/root/based/keyname" } {"Right": "mytag" }
{"Type": {"/": "hash of type card"} } {"Content": "Value in card"} {"key1": {"/": "Hash of +key1 child card"} } {"key2": {"/": "Hash of +key2 child card"} }}
That would be the content (JSON) of a card. Note that we can't link 'up' the tree from this node or we would be creating a cycle.
Links
[[https://c7.se/go-and-ruby-ffi/|Ruby FFI]]
[[https://github.com/ipld/ipld|Go ipld]]
[[https://github.com/ipfs/ipfs|Go ipfs]]
[[https://tour.golang.org|Go Tour]]
[[https://golang.org/pkg/|Go Packages]]
[[https://github.com/ipfs/go-ipns|Go ipns (Namespace)]]
That is the immutable parts, the creation of a local instance would necessarily involve creating mutable objects in ipns. A process would need to trace the initial content from the hash pointer for the latest release, and that would instantiate content references by tracing paths through the namespace. The content still unchanged from initialization, or updated in a new release would be referenced from the decko.org namespace. Local changes would get new signed entries that can replace references to other namespaces. This process would be a lot like managing a git workspace. Local changes are made to trees and blobs and a commit is created that references these updates and the original tree. While in process of preparing a commit, you have an action like git status that tells the differences between 1) the tree you are building on., 2) The changeset staged to be committed, and 3) the contents of the workspace. Similarly, we will have 1) as the current /ipns/MyDomainID/ 2) /ipns/MyStageID could be a possibility, and 3) local or server copies of trees and blobs.
{ {"Left": "/root/based/keyname" } {"Right": "mytag" }
{"Type": {"/": "hash of type card"} } {"Content": "Value in card"} {"key1": {"/": "Hash of +key1 child card"} } {"key2": {"/": "Hash of +key2 child card"} }}
That would be the content (JSON) of a card. Note that we can't link 'up' the tree from this node or we would be creating a cycle.
Links
[[https://c7.se/go-and-ruby-ffi/|Ruby FFI]]
[[https://github.com/ipld/ipld|Go ipld]]
[[https://github.com/ipfs/ipfs|Go ipfs]]
[[https://tour.golang.org|Go Tour]]
[[https://golang.org/pkg/|Go Packages]]
[[https://github.com/ipfs/go-ipns|Go ipns (Namespace)]]