Collaborative Document Editing Over Nostr

[basantagoswami]

Collaborative Document Editing Over Nostr

Motivation

Opening the issue to discuss creating offline-first (aka local first) applications, where nostr identities can do collaborative editing of documents without putting trust in a middleman. Feel free to add any resources you think will be helpful.

Goal

These can make use of CRDTs, or anything else, doesn't matter. As long as a user with a nostr profile is able to invite other users with nostr profiles to privately collaborate on the same document, we are good. The apps may use some special purpose centralized server for hosting the file, but the server shouldn't be able to observe the content of the files, or make changes to the content of the files without the users' private keys.

Use Cases

I'm thinking mainly in terms of replacing these apps with napps:

• Figma (we have PenPot as an open source alternative)
• Google Docs/Sheets/Slides etc (the only alternative we have is NextCloud, but it is terrible)
• Notion (we have Anytype as an open source alternative, uses some decentralized P2P stuff)
• Jira/Asana (we got OpenProject as an alternative)

Although Notion or Jira don't seem like document editing tools, we can effectively represent all their internals with files, so you just need to be able to edit files.

If this can be achieved, then it opens up the possibility of creating a bunch of new napps, where centralized servers (that are not relays) may be required, but have no control over what it's users are doing.

[fiatjaf]

I started writing an answer here but decided to turn it into a big document: nostr:naddr1qq2456tgxedyg4e3tumrxnpn2925jc2t8pp92q3q80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsxpqqqp65ww2eqdq

[sepehr-safari]

this had been on my mind for months! but we have limitations.
making it fully real-time is not possible based on current flow of nostr events.
I will explain:
fully real-time means you can see the current location of others' pointers on your screen (like Figma and Google Docs), and you are observing each letter they type or delete!
to achieve such functionality we're actually DDOSing our relays!! and for every single interaction of a user they have to read an event, save it locally in their database, other user should fetch it, parse it, update the UI, etc.

the flow described by @fiatjaf is more reasonable, but it's not that real-time one might expect.

for the sake of COLLABORATIVE DOCUMENT and without that REAL-TIME part, we can easily develop a flow like GitHub Pull Requests.
I think its flow is already pretty clear, but I will explain:

1. Bob create a public document (publish a 30023 article)
2. Pablo fork it for himself (fetch and re-publish Bob article with his keys)
3. Pablo edit it based on his needs (easy?)
4. Pablo send a pull request to Bob (it could be done by a kind 3xxxx with proper tags mentioning both versions and additional info to be parsed by clients)
5. Bob receives that PR in his client and now can moderate it by approving or rejecting the differences.

[staab]

WebRTC seems like a better fit for the truly realtime stuff, and nostr could be a lower-granularity fallback for when the p2p stuff fails.

[vitorpamplona]

I need to go back to my P2P Nostr research, but yes: I think even low-latency games can be played with two Nostr clients exchanging signed payloads with each other 100s of times per second via something like WebRTC. Relays can then be the fallback when they can't connect directly with one another.

To the pull request idea, I would like to see a non-replaceable history of changes for every document. The head of the document always has the latest version, but a client can load the entire history to figure out which sections were suggested or improved by who. Since we don't have an order of events in Nostr, the architecture will need to be a chain of events each citing the previous with an e tag. If somebody has the full chain of events, that person should be able to reconstruct the latest version of the document by applying each one of them. Of course, forks can also happen. :)

[ralyodio]

i worked at a company that did this. i think they went under. would be really cool. we targeted anyone who uses signed documents to avoid emailing ssn and stuff.

[pcfreak30]

I can tell you from my experience that direct P2P without saving anything is needed. I build on hyper/dat, so you would need to augment nostr with a separate p2p designed for efficiency to enable this, then have nostr handle more persistent data.

Also, another notion alternative that is FOSS but VC funded is https://appflowy.io/. It uses rust yrs as part of a sync protocol and doesn't use P2P, but in the end, it's all about adapting the software.

[melvincarvalho]

You may want to look at this too:

https://github.com/YousefED/nostr-crdt