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
Anyone should be able to open a pull request. The PR author and the repo maintainers should be able to update the PR's status.
Anyone should be able to comment on a pull request and update their own comment. The repo maintainers should be able to delete a comment.
PRs can be modeled as an OrbitDB Log + Key-Value store (for name & PR status).
Comments can be modeled as an OrbitDB Log, where each element in the list of comments is either
a new comment: author / text / createdAt
an update to an existing comment with a reference to the comment it updates author / text / createdAt / updateRef
Access Control
The OrbitDB maintainers say that it will soon be possible to define a gateway function indicating whether to accept an update to a DB entry, so that we can require that updates have the same author as the referenced PR/comment.
Internals
OrbitDB uses an append-only log called ipfs-log as the persistence layer for an operation-based CRDT. Every entry in the log is saved in IPFS and each points to a hash of previous entry(ies) forming a graph. Logs can be forked and joined back together. The transport layer is pubsub.
Persistence
The maintainer says that "there's a 'pinning' tool coming out soon too, which allows to run a cluster of nodes that can automatically pin the databases, thus making them available when the original poster/user is offline, eg. make sure the content/db is available"
PRs can be modeled as a Replicable Growable Array + Multi-Value Register (for name & PR status, where repo maintainer's writes > author's writes)
Comments can be modeled as an RGA, in the same fashion as an OrbitDB log (as described above). Each comment / update would be signed with the author's key and any update which does not have the same author as the referenced comment would be discarded
Access Control
The peer-star-app maintainers say that they are currently working on building out the security model, but it should be possible to do the equivalent to what was described above for OrbitDB.
Internals
peer-star-app uses delta CRDTs over a highly scalable ring topology built on floodsub (protocol description). Groups of peers sharing CRDTs are called a Collaboration (analagous to an OrbitDB database)
Persistence
The maintainer say that they are planning to build a service that can be used to persist collaborations
The text was updated successfully, but these errors were encountered:
On pull request structure - could also have tags field (or tag comment type) for labels/reviewers/assignees/etc (I'm fine with doing that later to keep initial thing simple)
I suggest we model Pull Requests as a CRDT
Each Pull Request should have
open/closed/deleted
Each Comment should have
Access Control
Anyone should be able to open a pull request. The PR author and the repo maintainers should be able to update the PR's status.
Anyone should be able to comment on a pull request and update their own comment. The repo maintainers should be able to delete a comment.
OrbitDB
PRs can be modeled as an OrbitDB Log + Key-Value store (for name & PR status).
Comments can be modeled as an OrbitDB Log, where each element in the list of comments is either
author / text / createdAt
author / text / createdAt / updateRef
Access Control
The OrbitDB maintainers say that it will soon be possible to define a gateway function indicating whether to accept an update to a DB entry, so that we can require that updates have the same author as the referenced PR/comment.
Internals
OrbitDB uses an append-only log called ipfs-log as the persistence layer for an operation-based CRDT. Every entry in the log is saved in IPFS and each points to a hash of previous entry(ies) forming a graph. Logs can be forked and joined back together. The transport layer is pubsub.
Persistence
The maintainer says that "there's a 'pinning' tool coming out soon too, which allows to run a cluster of nodes that can automatically pin the databases, thus making them available when the original poster/user is offline, eg. make sure the content/db is available"
peer-star-app
PRs can be modeled as a Replicable Growable Array + Multi-Value Register (for name & PR status, where repo maintainer's writes > author's writes)
Comments can be modeled as an RGA, in the same fashion as an OrbitDB log (as described above). Each comment / update would be signed with the author's key and any update which does not have the same author as the referenced comment would be discarded
Access Control
The peer-star-app maintainers say that they are currently working on building out the security model, but it should be possible to do the equivalent to what was described above for OrbitDB.
Internals
peer-star-app uses delta CRDTs over a highly scalable ring topology built on floodsub (protocol description). Groups of peers sharing CRDTs are called a Collaboration (analagous to an OrbitDB database)
Persistence
The maintainer say that they are planning to build a service that can be used to persist collaborations
The text was updated successfully, but these errors were encountered: