nips
nips copied to clipboard
nostr-protocol
NIP-54: decentralized wikis
The basic idea is to have multiple articles with the same name, each created by a different pubkey, and filter between them, but have them all publicly accessible for different perspectives.
"A change in perspective is worth 80 IQ points." Alan Kay
These ideas is being implemented and experimented with in https://github.com/fiatjaf/wikistr and https://github.com/fiatjaf/nwiki, but it's still a work in progress and I'm not sure it will work, but it's promising. Please give feedback.
Although having multiple articles for the same name can appear to be complicated to deal with, I think in the end, if this is successful, things will settle down to a couple of mostly canonical articles for each topic, while controversial topics will have 3 or 4 different versions and people will have be able to see all the different takes on each topic, with spam and shitty content filtered out. It only takes a few people in the world participating in the curation process to yield a better decentralized encyclopedia for everybody.
This is all very much inspired by the amazing http://fed.wiki.org/.
Readable (draft) NIP text: https://github.com/nostr-protocol/nips/blob/wiki/54.md
Another important feature of this model is that it allows someone to make a bridge to Wikipedia, for example, by publishing all Wikipedia articles under a dedicated Wikipedia keypair (ideally controlled by Wikipedia itself, but doesn't have to be in the first stage), and others to do the same for smaller encyclopedias out there like https://liquipedia.net/ or https://fediverse.wiki/ (there is no shortage of wikis out there, not to mention all the different Wikipedia languages), or even non-wiki things like Encyclopædia Britannica.
The cool thing is that an encyclopedia -- or an author in this case -- specialized in video games. for example, will have very different information about some player or videogame character than a generic thing like Wikipedia would ever do. And using this scheme these things call all live in the same namespace.
I think the biggest issue, at least in my mind, is picking up the text syntax format for this. I've added an explanation to the NIP about why I chose Markdown, but if someone else has opinions on this it would be great to hear them because I'm a newbie.
The only issue I see is that a replaceable event is not a great base for a WebOfTrust graph. Basically, I can design a page, get all the reputation I want, and then delete the text and change it to an #ad without clearing its WebOfTrust score.
Google solves this with a User Experience component to PageRank which counts the seconds the reader takes to click and come back to the search results. If the user came back too fast, it decreases the association between the term and the page. It's going to be hard for Nostr clients to code the same scoring capability.
The reactions should tag the e too along with the a, that's how I'm making them. Then the client can say: "bob liked an older version of this article". I also expect that eventually people to design relays that will archive specific versions of replaceable events on-demand (for example, whenever I like something this special relay will go there and fetch that specific version and store it for me forever) and not allow them to be replaced. What do you think?
Well, also if someone starts making a bunch of ads that person will not be able to earn too much reputation. These things could work in the beginning but as the system matures and gains more mass it will become increasingly harder to game it.
On Mon, Sep 18, 2023 at 06:28:00AM -0700, fiatjaf_ wrote:
I also expect that eventually people to design relays that will archive specific versions of replaceable events on-demand (for example, whenever I like something this special relay will go there and fetch that specific version and store it for me forever) and not allow them to be replaced. What do you think?
fwiw nostrdb already works like this.
Unlike normal Markdown links
[]()that link to webpages, wikilinks[[]]link to other articles in the wiki.
Maybe this could be a NIP-19 nwiki similar to naddr but withought an author nor kind (assumed to be 30818). So just the d tag identifier and optional relays.
Then use regular markdown links with NIP-21 [A link](nostr:nwiki1fnt...nqc)
Maybe this could be a NIP-19 nwiki similar to naddr but withought an author nor kind (assumed to be 30818)
Doesn't that break the only requirement of Nostr events? They always have a kind and author.
Why wouldn't you just included the assumed kind and the author of the page?
@erskingardner the nwiki would reference not a single event, but a group of events.
~I change my suggestion to something more generic that could also reference NIP-61 - Unbounded Lists: nset~
~nset is clearer cause it references a set o events. It would encode d-tag, kind, author(optional) and relays(optional). With an author, it supports NIP-61 (a set of events from an author). Without an author, it supports this wiki NIP (a set of events from any author)~
~Referencing by tag could use an unified tag too, I was using u but I will change it to s(set). It can be similar to an a tag but the order is different to allow for lack of author at the end:~
~Referencing a wiki page set: ["s", "<kind integer>:<d tag value>:", "<recommended relay URL, optional>"]
Referencing an unbounded list: ["s", "<kind integer>:<d tag value>:<32-bytes lowercase hex of a pubkey>", "<recommended relay URL, optional>"]~
edit: changed how unbounded lists work
Can links point to a specific version of a page?
They should not. That would break the entire purpose of making this an open wiki and not a centralized one. But authors of one article must have a way to signal their preferred version of other articles and clients should prioritize or highlight these when moving from one article to another.
Ultimately it must be a client choice.
I thought that collaboration on a single article was the core wiki's feature. How can I suggest a small correction for one's article? Maybe a 30820 with my changes in Unified Format, linking to the target 30818 by e and a? Or is this out of scope for now?
It would be useful to consider a PR-style event where a pubkey suggests making a change to an event beyond the scope of this NIP alone. I've seen a few people interested in this functionality and we should avoid having three different ways of doing the same thing if we can avoid it.
It would be nice if articles MUST/SHOULD include a language code tag. You generally want to search for articles of only those languages that you can read.
It would be nice if articles MUST/SHOULD include a language code tag. You generally want to search for articles of only those languages that you can read.
To me an article in Japanese about a topic is very similar to an article written by a leftist or something like that. Both are equally useless but I would like to be aware of the existence and there are ways to take something of useful of both.
This looks good to me, however it needs example events in the [INSERT EVENT EXAMPLE] sections :grin:
Also it would be good to have an example fork event in the "Forks" section
