Why Nostr? What is Njump?
2025-06-06 05:48:15
in reply to

Dikaios1517 on Nostr: I have been using Joplin, encrypted and synced to my Nextcloud. This could work for ...

I have been using Joplin, encrypted and synced to my Nextcloud. This could work for collaboration, as well, but as with anything encrypted, you would need to give the collaborators the decryption key, so you will likely want to have a separate profile for notes you need to collaborate on, and share the decryption key only for that profile.

If you don't need encryption, I believe Joplin allows you to go that route, too.

As for a Nostr-based note app that allows for collaborative editing, well... we don't really have a Nostr-based note app yet. Best option is using a long-form client and only publishing to a private relay you control. However, most long-form clients just publish to your outbox relays by default, and don't offer a way to override that. The best option I can think of for this would be Comet.md. This is a local-first note app for desktop, so it's not cross-platform. However, it does let you publish your note to a specific relay, and only that relay, even if it is not one of your outbox relays.

Note collaboration is still a problem that needs to be solved. The way Nostr currently handles all notes is that a note can only have one possible author, identified in the "pubkey" field of the note. The signature attached to the note must be valid for that pubkey. There's a couple approaches to collaboration that I can think of possibly working.

First would be the way that has already been implemented for wiki notes. These notes have one author, but anyone else can come along and fork the note, which creates a separate note that only they can sign. However, if the original author likes their changes, they can merge them into their own version of the note. Amethyst also has something like this for "suggesting edits" to regular text notes. But no one ever uses it because Amethyst is the only client that supports these types of edits to regular text notes, so those on any other client will just see the original note.

Another approach would be to have a new standard for assigning collaborators. In this case, the original author would sign the note, and then they would sign a separate, special kind of note that references the original note ID and lists the pubkeys of approved contributors. If any of those npubs submit a new version of the note signed by their private key, the relay will accept it, but keep the copy of the original owner's version, in case they want to revert the change. Clients would display the most recent version of the note signed by the owner or any of the approved contributors, but also display to the owner the option to either commit the changes made by their contributors, or revert their changes. If the owner commits the changes, a new version of the note is created with the owner's signature, and all previous versions can be discarded by the relay. The relay only keeps the revisions of the contributors if they are newer than the most recent version signed by the owner.

Obviously, this second option is more complex and would require new relay logic to implement, so it may be a while before we see anything like it.
Author Public Key
npub1kun5628raxpm7usdkj62z2337hr77f3ryrg9cf0vjpyf4jvk9r9smv3lhe