Wow! Much more valuable feedback than I expected to receive. You have my upvote, sir.

I am a font of information. Also other things, but certainly information.

The issue with posting only a diff is you pollute other interfaces with junk posts. You could solve this by posting the diff in a custom-JSON operation, but you lose the visibility and the upvoting/downvoting/commenting social mechanics.

There is an underlying problem with the upvoting/downvoting/commenting social mechanics in the context of a wiki, in that primarily they don't work and aren't really part of the way that context exists. Comments in particular are just additionally related wiki-content; when anyone can come in and append/annotate the pages, comments are absolutely superfluous. If someone wants to have a more threaded conversation about the content of a wiki, that's better done on something like a forum or blog environment where threaded conversations are supported. It is far more effective to make a change to a wiki, grab the URL of the new page, then post about it on your blog while making a reference to the wiki source then it is to actually think about commenting in the context of wiki operations. It just doesn't work for that.

This is why Wikipedia, in particular, has a serious division between pages and the discussion about those pages. You can't really have discussion about and around content easily within the context of a wiki, at least as it is traditionally architected. It's certainly possible to imagine some sort of marginalia like Medium provides for commentary which is linked specifically to parts of the text and often presented off to the side, but that's really just supporting the traditional context of threaded conversation with a way to refer to where that conversation is occurring.

Valid points about edit wars .. we need to think about that a bit more.

From my perspective, figuring out how to deal with the contributions of multiple people in the same context is the biggest problem of working with multi-user wikis. Wikipedia does it by effectively creating a hierarchy of editors who decide (the various degrees of success) what the party line is. In a more abstract sense, that is the approach that pretty much all wikis take. That doesn't seem to work with the technology that we have available or the ostensible philosophy being espoused on the platform.

It might be instructive to look at how various large-scale open source projects manage the responsibility for their GitHub contributions – except that we know how that happens. There are hierarchies of authority who take responsibility for various levels of quality release with a handful of people at the top who make the final decision. The counterweight to that is that it is trivially easy to split off your own preferred repository for a given project and begin working on it with whoever you want to. If more people think your branch is more interesting or has a greater chance of success, they abandon the original and start working on yours.

Unfortunately, that metaphor isn't particularly useful for a shared wiki space in this context. You need a centralized authoritative source in order to determine what content should appear on the page but there is considerable friction to splitting off your own "version" of wiki pages under your own authority.

It would be interesting to create a system which made that possible, but then we're back to designing some sort of web of trust mechanism where the primary version of any given page is dependent on the specific choices of the observing user. It's possible and interesting but a lot of work.

I considered the option of keeping the content in a separate database for performance reasons, but decided against it. The content has to live on-chain, IMO, either in posts or under the surface in custom-JSON ops. The off-chain data would be a meta-index of the articles, which would be easy to rebuild by replaying previous blocks of the chain.

Part of the problem of the content living on the chain is that wikis are specifically high dynamic turnover information presentation systems. Note that posts on the Hive blockchain can be edited by the original creator – but those updates are essentially managed as a JSON diff with the original post which gets assembled post hoc at the time of presentation. The reason that's at all plausible is because it isn't likely that a given post is going to accumulate a lot of edits, so it's relatively quick and easy to assemble that post by chasing back blocks because there are that many blocks involved.

Not so for a wiki page. The whole point of a wiki is that the pages are highly dynamic, high turnover elements. The best wikis are using graph representations under the hood to effectively only store diffs and localizing those references so they're quick and efficient to rebuild. Blockchains just are designed for that kind of access profile. They just aren't. They really aren't designed for replayability of highly branching, nonsequential edits. "Distributed ledger" has a very specific and impactful meaning.

I like tools. I love tools. I love new tools. I love wikis for quite a lot of purposes, including some experimentation with replacing blogs in general with various sorts of wiki interfaces – but building a wiki which back ends onto the Hive blockchain strikes me as trying to bolt two things which don't really work with each other together and hoping to get something useful out the other side.

The fact that Hive posts already support markdown linking really obviates a lot of possible use that you might get out of a more wiki-forward interface. That anyone could come along and effectively edit/add links at any point to any content pushes even more redundant content onto a blockchain which isn't great at sorting through diff trees.

We already have problems with people spamming the blockchain and spamming on the blockchain – now just imagine what would happen if anyone could take any post, particularly the most popular ones, and go in to start marking up links from bits of content within it to anything they wanted.

How long would this system last?

I'm not saying you couldn't make it work but I am saying that the results wouldn't work for long, have a vast number of possible exploits, and don't actually make use of the technology for positive ends.

It sucks but there you go.