What are current approaches of collaborative nostr notes?
Is this already solved on a technical level?
If we would have collaborative markdown editor like https://hedgedoc.org/, how would we sent and find the event?
I guess it would have a `d`-tag to identify the document, but how would we identify allowed collaborators?
Or think of community-curated collections of content. How would I follow and edit a list that could be edited by multiple pubkeys?
Query by `d`-tag, kind and then just take the most recent event?
cc nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z nostr:npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf nostr:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q
Login to reply
Replies (10)
Events can have the keys delegated, so that multiple npubs can edit the content contained in the 30040 index. That also means that each npub can sign his own articles, for instance, and then tie them into a group blog.
Addressable events have a kind in the 30000-39999 range and a d-tag and an a tag that looks like
["a", "<kind>:<pubkey>:<d-tag>", "<relay hint>"]
Indexes allow you to determine the order in which the content appears, but you also just show most-recent first.
I don't know, if that answers your question.
Simpler and cleaner than key delegation is to have a shared key, like we have for nostr:nprofile1qys8wumn8ghj7mn0wd68ytn9d9h82mny0fmkzmn6d9njuumsv93k2tcprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7qpqs3ht77dq4zqnya8vjun5jp3p44pr794ru36d0ltxu65chljw8xjqxqf9se , and use that for the index.
If you want to collaborate on one article d-tag, just have the client take the fork with the newest created_at, from within some community/relay or set a list of collaborators. Everyone has their own version, and you think up a scheme for which version is primary. Or you can have collaborators recommend their favorites. Which ever receives the most defers is listed first.
What you're describing is more wiki than longform article. You can include wikis in an index, like I did for https://next-alexandria.gitcitadel.eu/publication?d=gitcitadel-project-documentation-by-stella-v-1 (those are all 300818 wiki pages with Asciidoc markup, not 30041 articles).
https://github.com/nostr-protocol/nips/blob/master/54.md
You could add an optional "collaborators" tag to your events, listing which pubkeys are on the editing team.
they also call them "parameterized replaceable" and they make sense in that they create a secondary link between them to decide whether to allow replacing and deleting the old version
i haven't thought about it much but i also haven't thought of a better way to implement such a thing, it makes sense
nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5 can you create an issue on nostrability?
I found this link: (I think they give some clues)
kanban https://github.com/nostr-protocol/nips/pull/1665
Shared replaceables via event property keys #1228 https://github.com/nostr-protocol/nips/pull/1228
Task and workflow NIPs #1767 https://github.com/nostr-protocol/nips/pull/1767
Yes, that is also how I would have thought to do it. Thanks!
Thanks! Yes a shared kanban has the same challenges, will look into it!