yeah, that is precisely the use case i see it being for. the idea i see is that you store the document as unsigned collection of these events, that originates in an asciidoc master version. there needs to be a bidirectional codec between the master and storage format, and the rest is handled by standard git commits, and because the document is already segmented neatly, there should be very few chances of several people working on different paths having a merge conflict issue, but it can be fixed i guess. probably just to poll the log in case a user is editing a section of the document that has been updated in the repo.

git itself, for actual signed nostr events tho. so simple. everything is already atomic, there can't be conflicts, although there might be a problem with forks.

Reply to this note

Please Login to reply.

Discussion

No replies yet.