tabcat / dynamic-content Goto Github PK

https://github.com/tabcat/dynamic-content/blob/master/ARTICLE.md

Overall feedback

• Needs a Table of contents
• Great article, very well written! I'm excited.
• I love the Sample Outputs section

Understanding Key Components

This is a great primer.

Achieving Dynamicity

• It could be good to show a diagram of what the architecture of OrbitDB -- or other methods people have used to achieve dynamicity -- used to look like, so we could compare.

Dynamic-Content IDs

referring to this section:

Instead, it is a permutation of the CID of an immutable manifest document that describes the dynamic content

This is slightly confusing

I know there is a note that says, "there is an example using this in the bottom," but I think this section could explain more, and set expectations better.

Some questions I have when targeting just this section

• Why do we need this dynamic CID, what is it's purpose?
• Why do i need this manifest json/hashtable/other data?
  • what if someone used manifest = "myManifest" (maybe deserves FAQ entry?)
  • What if there are accidental manifest conflicts for different implementations? (FAQ?)

I think briefly speaking about how this DCID is used as a reference point for the implemented application is important. "This is the key used to query the DHT to determine where offline data we need is" and "This is the key used to publish data, so when we go offline, others can find it" or similar.

• It could be good to link to the https://github.com/tabcat/dynamic-content/blob/master/ARTICLE.md#read-and-write-steps section to point users to how it's used.

Viewed as a Replication Protocol

• I feel like it could be useful to link to, or briefly discuss, orbitDB's attempts and problems earlier in this article to explain the reason for this approach.

Replication

When other collaborators are online, use an application-specific replication protocol for real-time collaboration.

It could be valuable to address this further.

• Why bifurcate replication protocol methods?
• Is the "app specific" replication protocol using IPFS?
• If not, why not full IPFS?

Roadblock, Workaround, and Hopeful Future

• Maybe this section needs more attention and breaking up? Maybe a "blockers" section and current workarounds?

Read and Write Steps - https://github.com/tabcat/dynamic-content/blob/master/ARTICLE.md#read-and-write-steps

• I think this basic "algorithm" for your approach should be much higher in the document.

from: @SgtPooki

Read and Write Steps - https://github.com/tabcat/dynamic-content/blob/master/ARTICLE.md#read-and-write-steps
I think this basic "algorithm" for your approach should be much higher in the document.

from @SgtPooki:

Replication
When other collaborators are online, use an application-specific replication protocol for real-time collaboration.

It could be valuable to address this further.

Why bifurcate replication protocol methods?
Is the "app specific" replication protocol using IPFS?
If not, why not full IPFS?

from @SgtPooki:

Dynamic-Content IDs
referring to this section:

dynamic-content/ARTICLE.md

Lines 48 to 56 in e4df337

Dynamic-Content IDs

When searching the network for static content, a CID is used to find providers in the DHT. When searching for dynamic content a CID is still used. However, this CID does not belong to any static content. Instead, it is a permutation of the CID of an immutable manifest document that describes the dynamic content:

manifest = { protocol: '/some-protocol/1.0.0', params: { network: 1 } } 
cid = CID(manifest) 
dcid = CID('dynamic' + cid) 

Instead, it is a permutation of the CID of an immutable manifest document that describes the dynamic content

This is slightly confusing

I know there is a note that says, "there is an example using this in the bottom," but I think this section could explain more, and set expectations better.

Some questions I have when targeting just this section

Why do we need this dynamic CID, what is it's purpose?
Why do i need this manifest json/hashtable/other data?
what if someone used manifest = "myManifest" (maybe deserves FAQ entry?)
What if there are accidental manifest conflicts for different implementations? (FAQ?)
I think briefly speaking about how this DCID is used as a reference point for the implemented application is important. "This is the key used to query the DHT to determine where offline data we need is" and "This is the key used to publish data, so when we go offline, others can find it" or similar.

It could be good to link to the https://github.com/tabcat/dynamic-content/blob/master/ARTICLE.md#read-and-write-steps section to point users to how it's used.

From @SgtPooki:

Achieving Dynamicity
It could be good to show a diagram of what the architecture of OrbitDB -- or other methods people have used to achieve dynamicity -- used to look like, so we could compare.

Viewed as a Replication Protocol
I feel like it could be useful to link to, or briefly discuss, orbitDB's attempts and problems earlier in this article to explain the reason for this approach.

Something like "If you are familiar with how publishing Provider Records to the DHT works you may have spotted a problem here. ... More detail in Roadblocks and Workarounds"

from @SgtPooki:

Needs a Table of contents

from @SgtPooki:

Why do we need this dynamic CID, what is it's purpose?
Why do i need this manifest json/hashtable/other data?
what if someone used manifest = "myManifest" (maybe deserves FAQ entry?)
What if there are accidental manifest conflicts for different implementations? (FAQ?)

from @SgtPooki:

Roadblock, Workaround, and Hopeful Future
Maybe this section needs more attention and breaking up? Maybe a "blockers" section and current workarounds?