search

DangerOnTheRanger / maniwani

Imageboard software for the 21st century
MIT License
75 stars 11 forks source link

having a Wiki per board #81

Open DonaldTsang opened 5 years ago

DonaldTsang commented 5 years ago

Something like https://8ch.net/fringe/library.html and https://8ch.net/fringe/faq.html but better, having multiple pages

DonaldTsang commented 5 years ago
DonaldTsang commented 5 years ago

Some pros, cons, and counter arguments

  1. Collaboration with others
    • Public collaboration leaves the website vulnerable
    • Assume that the users can be safe and not post private information
    • Private collaboration can be replaced with Discord/Matrix/Rocketchat/IRC
    • Wikis are far more easier to read than chat logs
  2. Data sharing to prevent deletion
    • Spoon-feeding is a bad way of educating people
    • High noise-to-signal ratio on the internet is equally bad
    • Open rhetoric and anti-ethereal creates enemy advantage
    • Null concern, as it is assumed that the enemy does not argue by rationality but by emotion
    • Other data storing methods include IPFS
    • IPFS's MDWiki is not complete, therefore it is really not that useful without updates
    • Solutions include HTML link directories and *booru
    • Can be seperate services that connects to ManiWani
DangerOnTheRanger commented 5 years ago

A proper wiki system would likely be worthy of its own project. I would much rather provide an authentication bridge as part of the REST API so that users registered on a Maniwani instance could be authenticated with an external wiki.

It is conceivable that a plugin API for Maniwani would be extensible enough that a full-blown wiki could be developed with it, but that would take a very large amount of effort even before considering the development work required to write a wiki system.

DonaldTsang commented 5 years ago

@DangerOnTheRanger perhaps add a bridge for https://wiki.js.org/ ? It looked promising.

DangerOnTheRanger commented 5 years ago

I'd rather simply develop an OAuth2 bridge and let people use that instead - works for a much wider variety of applications and not just a single wiki, and anyone wanting tighter integration would probably be better off coding and maintaining that themselves.