NosDAV should eventually be able to handle it. It's basically a port of Solid (Social Linked Data) to Nostr.

What is allows is users to read a page, edit a page, create a page, delete a page etc. You can also set the access control so that others get edit permission, or even the whole world gets edit permission.

Rather than put the whole of wikipedia in a relay, which would take up a lot of space, it allows pages to be created on a compliant web server, with authentication via NIP-98.

It already supports markdown, but I've not put in the WebAccessControl NAV yet, but it'll look alot like UNIX permissions. You could then quite quickly start a markdown thing similar to the original wikipedia, but with nostr users. There's a few tricks to make it slightly more decentralied too.

But I guess you want censorship resistance. Might be possible since it's federated out of the box. But even federated has single points of failure. A more content addressable part similar to IPFS could be done. There could be some censorship resistant pages on relays, but then you need bigger relays.

Nice idea, in any case.

Reply to this note

Please Login to reply.

Discussion

Wikipedia censorship comes in the form of competing edits, where ideologically opposed individuals engage in narrative combat. How would such disagreement be resolved? My rough thought on this topic is to enable content to be composable by users based on competing sources using whatever client-side filtering and whitelisting desired by the user. (Same as the Primal content moderation model for Nostr.)

each user can choose which edit they want

or flavour but flavors will need a strong hand. You can think of Wikipedia.org as the Wikipedia Flavour…

nostr:npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24 where the NosDAV code?

the main point of nostr is any flavor cant censor easily if at all, for example there would certainly have been deleted conversations on wikipedia

💯

⚡️ incentives / requirement for some flavours (relay or relay network) would be real nice for quality control and incentivization.

Thinking about how this might work and I’m wondering pay sats to the author referenced in the footnote?

Editor/contributor splits could

be calculated on the amount of edits on the article.

Also thinking there needs to be some split between the flavour maintainers (like centralized org such as wikipedia foundation) and the editor/contributors (decentralized)

Then how to incentivize relays to host and howto incentivize editors to contribute? ⚡️ tipping, ⚡️ subscription or some form of ⚡️mining would be interesting. Also what about article bounties? ha! People contribute ⚡️ to areas of knowledge or specific articles to grow them. Brainstorm…

Had another thought, since wikipedia accounts are completely created with extremely no/low cost which allows some untold # of bad actors, using nostr pub/priv keys is no brainer plugin, as the unpaid editors (well paid in altruism) now currently are the primary spam deterrent.

Augmenting the Altruism-Coin with ⚡️ would provide some new blood into the editing system.

Anyway, this will conflict with Wikipedia culture, so only way is forward and engage on demand.

yesss

This is great effort. Compatibility with WebDAV would open up a lot of use cases and has permission model already.

nostr:npub1929tcqjxtdpgl7lvy2qegagr68ktvymrsnk7gwskesfs4vk92j0scnwqke what issues do you see?

nostr:npub1ekjq2t8zdhs4sycusarwzxas9t0jnuwusssuam5nz0f9e4cm6hqqx6ltq4 we need BrionV on here.

Not gonna happen. :/

Sounds like the bare minimum technically to implement a wiki. 99.999+% of wikis aren't wikipedia alternatives, let alone viable ones. Build "wikipedia for nostr" doesn't strike me as likely to be successful, but go for it, crazy attempts are a way to make progress, at least it can be added to https://en.wikipedia.org/wiki/User:HaeB/Timeline_of_distributed_Wikipedia_proposals