Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Pull Requests #46

Open
dirkmc opened this issue Jul 27, 2018 · 2 comments
Open

RFC: Pull Requests #46

dirkmc opened this issue Jul 27, 2018 · 2 comments

Comments

@dirkmc
Copy link
Collaborator

dirkmc commented Jul 27, 2018

I suggest we model Pull Requests as a CRDT

Each Pull Request should have

  • author
  • base repo
  • base branch
  • comparison repo
  • comparison branch
  • comments
  • name
  • status open/closed/deleted

Each Comment should have

  • author
  • text
  • created timestamp
  • updated timestamp

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

  • 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"

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

@dirkmc
Copy link
Collaborator Author

dirkmc commented Jul 27, 2018

Read-only implementation of PR comments using OrbitDB: #47

@magik6k
Copy link
Collaborator

magik6k commented Jul 27, 2018

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants