The idea that Hive could be used as a base layer for a wiki has pretty much been around since the inception of the legacy chain. But while there have been several wiki initiatives since then, none of them uses hive to store the text contents.
Wrote a readme today
Now with Propolis Wiki up and running, I thought it might be a good time to explain a bit the technical details how it achieves the goal of providing crowdsourced knowledge in the popular wiki format, while still being available to all readers on any hive interface of their choosing.
I use python in the backend. As it's not as simple CRUD with SQL app, I decided to use the lightweight flask framework.
The frontend uses a few javascript libraries for content formatting and display, but is designed to be as lightweight as possible.
I was looking for a simple modular WYSIWYG editor, but didn't really find anything that was as simple as I hoped. In the end I settled with tui-editor, and managed to create a references plugin that works as expected in one editor mode at least (while breaking the other one, but I'm fine with disabling that for now). This will also come in handy with the future pevo prototype.
There's no need for font sizes or colors in a wiki, but I did include the latex plugin.
While all necessary data is stored on Hive, there is a need for a complementary database storing some information. I chose postgres for its fts capabilities and scalability.
There are a few differences between wiki markup and standard hive markup. <ref> tags for example are a wiki-specific addition and are removed by hive convention. The references also get added to the end of a wiki article. Links in the wiki lead to /wiki instead of /@username, and in the wiki links to articles that yet need to be created are marked red.
Long story short, most work probably went into the various splits, replaces and re-stitches of content. This is done partly with javascript when posting, and mostly in python when retrieving the content.
Another way where content is mutated are the diff views, using the diff-match-patch libraries. Edits of posts are always a patch, which makes it easy to compare articles from different points in time and stores the data in an efficient way.
All posts of the english version of the wiki are published under the account
Any hive user can be added as an authorized account, where the app uses the weight parameter as authorization level, of which there are 3 right now (editor, moderator, admin). The 
The updater script also checks transactions for maliciousness. Authorization can be automatically revoked if for example metadata is missing (which could easily happen by using another interface than the official one for editing), if the operation is blacklisted, or if the username in the metadata doesn't match the signer.
The app can be run as an interface by anyone, but for some functionality it requires the posting or active key. I will hand these out pretty freely if you've been around for a while and show warranted interest.
Posts can be viewed on all interfaces, with a lot of effort going into not breaking the display there.
Planned features include previews when hovering links to existing articles, shortcuts for moderators to move/revert/delete articles, more security features, and a lot more. Get in touch if you want to contribute!
From the content side I hope to get the ball running by using some of my earnings on hive to incentivize authors to provide quality edits. Check out the 
I hope this post gave you some insights, leave your questions and remarks in the comments!
