Actually above is similar to my ideas on moving developers.hive.io on chain, but I have not enough bandwidth for that.
Ideal way is to have dedicated front end to make it easy to navigate as a documentation site / wiki, but it should be also have be usable while browsing through general purpose frontend such as hive.blog.
You are viewing a single comment's thread from:
It would be possible to do onchain by authoring users via posting authority but it would be a nightmare to deal with and wouldn't provide any auditing which is critical for wikis.
Hive Multisig to the rescue?
Would be very cumbersome. Posting auth is easier but no way to audit updates. It's just not a good medium for a wiki without a front end app layer.
Well, maybe there's room for some innovation. Combine all these concepts into something that works.
For my idea it is not going to be worse than it is, i.e. compare access control to whatever you have on developers.hive.io, if you want to edit that you go to code repository and you can make your change, submit PR, maintainer then can accept it. Same here, even using mostly what we already have (community, tags, etc.).
Auditing is just extending UI to have history of edits etc.
I was hoping to start with those https://github.com/openhive-network/hive/tree/develop/doc/devs/operations for MVP, but again, lack of bandwidth and higher priorities related to upcoming new version.
Yes, when possible hive flavoured markdown should be used. There are a few cases where the wiki will require additional syntax or functionality though. References are one such case, and I also added latex support (more as a step towards pevo, but useful in a wiki too I think).