RFC: Collaborative Objects

[alexjg]

This is a very rough, incomplete, first draft of an RFC for collaborative objects. Details on exactly what the API will look like, and discussions of downsides and alternatives are still missing.

[kim]

@alexjg Do you want feedback on this already?

[alexjg]

@kim yes, but mostly I'm interested in feedback and questions on the high level architectural approach. I'm still working on specifics of the API.

[alexjg]

Vis a vis non-git implementations, it would certainly be possible to talk in terms of synchronizing and validating an abstract graph of CRDT changes. I think this would be valuable and it's something I am interested in doing but I'm not sure that it's useful for this RFC. I think one of the values of these RFCs is hammering out the more fiddly implementation details so it makes sense to be more concrete.

[FintanH]

Another thought I just had was, "Does this RFC need to be particular about Projects?" I feel like it might make sense to have "collaboration objects" on a Person, but one would essentially just be collaborating with themselves. For example, I could have a list of "favourite projects" on my Person identity, that is tracked over my devices. It's a good chance for Person identities to have metadata that could change frequently, and so wouldn't be suitable to be kept in the Doc itself.

[alexjg]

Interesting thought. We would need to add a similar signed_refs construct to Person identities as at the moments - as far as I'm aware - we don't replicate anything except the identity document itself for Person identities.

I think this is probably worth doing but might be best left to a later RFC?

[FintanH]

We would need to add a similar signed_refs construct to Person identities as at the moments - as far as I'm aware - we don't replicate anything except the identity document itself for Person identities.

It's your lucky day, Person also has signed_refs :) Check it out on a file system near you!

[alexjg]

But we don't replicate that at the moment right? Specifically we only call replicate_signed_refs in librad::git::replication::project::ensure_setup and not in `librad::git::replication::person::ensure_setup. Still, that seems like it would be pretty trivial to add. I would still like to leave this to a later RFC if possible. It seems like it would be a straightforward extension of the concepts in this RFC but I like to keep my scopes nice and focused :telescope:

[FintanH]

Ah yes, that's a good point.

What first brought this thought on was that in your MVP PR you have project_urn as fields and I was thinking that it might not have to be particular to a project. In fact, it would probably be tricky to scope these things to only project Urns unless we check that it always resolves to a project.

[kim]

Does this RFC need to be particular about Projects

No, there's no difference in that sense (or it's a bug :)). The more general term would be "URN".

[alexjg]

I've made a few significant changes to this document. Provided these changes pass muster I think this is ready for merge.

rad_signed_by

I've removed the rad_signed_by key. This was intended to allow schema authors to express things like "comments must be signed by their author" in the schema. Unfortunately I couldn't find a simple way to make this work in the presence of conflicts. The problem eventually becomes equivalent to the more general access control problem which we have deferred to later work. Concretely this means that metadata on components of a collaborative object (such as an author_urn field on a comment on an issue) will not be authenticated - anyone can pretend to be anyone else. The impact of this should be minor as for this implementation of collaborative objects the only people who can modify collaborative objects are project maintainers, who should be relatively trustworthy.

Custom json schema vocabulary

Some keywords in the standard json schema vocabularies do not distribute across merges (consider the maxContains keyword). I have defined a custom vocabulary at https://alexjg.github.io/automerge-jsonschema/spec which specifies a subset of keywords which are safe to use on Automerge documents and specified that schemas MUST use this vocabulary.

[kim]

This marks the beginning of an era, I suppose :) :rocket: