See https://github.com/substance/dot/blob/master/README.md for details.
Idea is to have a 'bare' repo consisting of meta data, and a set of log files. Every log is written just by a single user. The owner is maintaining meta-data and a master log.
The master.log is changed only by the owner, by merging pull-requests, where only fast-forward merges in terms of git are possible.
It looks like this:
...
V 10
C userA <...serialized change ...>
C userA <...serialized change ...>
C userA <...serialized change ...>
V 11
i.e. consisting of blocks of changes leading to a shared notion of a document history.
Every user appends to a <user>.pr. Must be based on latest version of master, so that it is considered for merge.
...
V 11
C userB <...serialized change ...>
C userB <...serialized change ...>
i.e. it consists of such blocks too, with the only difference, that only the last block is relevant.
In case of concurrent changes, only one user will land their PR in master (fast-forward rule). The others need to rebase their PR
to the latest state of master, by just appending a new block with changes being compatible with the latest changes in master.
The meta-data part would be used to maintain repo information:
- extra information how to process the content (i.e. how to produce the working-copy from the feed of incremental changes)
- collaborators, particularly how to discover their
PRfeed - who is master
In addition to the 'bare' repo, the owner could publish the working copy, as a dat.
- General advice how to use
hypercoreandhyperdiscovery - or is there a better way? --
datseems not be the right thing ATM, as many ppl writing feeds? - (Not absolutely important ATM) Are there means to make sure that only the intended person is writing to a feed?
- General advice for inviting a collaborator. The (PR) feed would be created and published by a collaborator. The discovery URL would
be stored in the
meta databy the owner. - Any ideas/comments to complement the picture
BTW, this is not only for editing classical 'documents'. In
archivistand now also intexturewe are applying this to maintain a shared entity-db.