-
@ Leo Wandersleb
2023-03-26 15:51:29I'm writing this on Habla after fiatjaf shared a link to his article on Habla which had led me to NostrBounties. Both Habla and NostrBounties are the first tools I saw for authoring replaceable content but who is working on Wikipedia already? Didn't fiatjaf start nwiki almost a year ago? Why is our nip registry not decentralized yet? And how could that even work?
Nip33 describes well how one author can maintain a collection of editable events.
But how are multiple authors meant to coordinate and consolidate their efforts on a common body of events? This problem is so far unresolved!
In summary, what we have so far is great to share your collection of articles, your collection of bounties, your ... many things but only things strongly tied to an author.
NostrBounties takes a baby step beyond this by letting others add to a bounty but what will happen if this gets spammed? Does it make sense to tally up all that replied a number to those bounties?
Do we need benevolent dictators for such bodies of events?
When looking at projects like Wikipedia, we can quickly see how having one curator won't work. For smaller bodies maybe but the appeal of using nostr in the first place would be lost if other contributors would be second class.
How can we design a system such that others joining the effort don't have to either:
- live with being second class, merely amending the work of others
- copy all the body of events under their authorship
Can we use pet names here?
For the following to work, we need something like "Parametrized Versioned Events" (proposed NIP) - in contrast to nip-33, these events should not get deleted meaning that retrieving them via their event ID should remain possible after a "replacement" by the author. These events could use kind 40000-49999.
Let's assume, Alice authored nip-999 as a kind-40001 (kind-nip) event:
"author": $alice, "id": "14aeb..8dad4", "kind": 40001, "tags": [ [ "d", "999"], …Now if Bob wants to endorse this nip-999, he can author a kind-40001 event as such:
"author": $bob, "kind": 40001, "tags": [ [ "d", "999"], [ "n", "14aeb..8dad4"] ], "content": "", …And if Carol trusts Bob, she can endorse his version as a parametrized event, meaning including future edits or "n"-dorsements:
"author": $carol, "kind": 40001, "tags": [ ["d", "999"], ["n", "$bob:999"], ], "content": "", …And finally Dave trusts Carol in all things nip and endorses her wholesale:"author": $dave, "kind": 40001, "tags": [ ["n", "$carol", ], "content": "", …Now Erin searching for nip-999 could query for nips and endorsements
{"kinds":[40001],"#d":["999"]}and be offered results together with authored dates and authors' proximity in the social graph. The client can add results from searching for wholesale endorsements{"kinds":[40001],"#n":$listOfFoundAuthors}.So Erin could reference nip-999 as
14aeb..8dad4, making it sticky to the current state$alice:40001:999, trusting Alice as author or delegator. This could be displayed as "Alice.nip999".- "Bob or Carol.nip999" would both add one indirection in the above example but would all resolve to the same nip the same way.
- "Dave.nip999" would again add one indirection but work slightly differently
Where today, Fiatjaf is picking collaborators for his GitHub, collaborators would have to pick people they trust so they can automate some endorsement to drive consensus and discovery - if ever that trust is abused, just like in git, people can update their endorsements and thus undo the harm.
In theory, long chains of endorsements could emerge, resulting in clients needing multiple round-trips to get to the content but in practice, for nips, probably many would endorse some figure head until somebody else takes over, at which point fiatjaf would probably endorse that one but active developers would conscientiously update their endorsements.
/cloudfront-us-east-1.images.arcpublishing.com/artear/PRGE5XHSBBA65HUXBBNKH7K5R4.jpg)
Circular endorsements?
... should be easy to filter out.