Any chance you might eventually consider bridging to MediaWiki

NAB does have the idea of wiki-like pages (mainly used for space configs, sidebars and the policy pages in the footer). Pulling things into notabug's data structures is relatively simple (though for a wiki would be more difficult to keep links working) making things bidirectional is typically harder.

This is because NAB's data structures are all geared towards eventual federation/p2p most significantly in that content is identified by hashes rather than (in the case of saidit) sequential identifiers.

The ingest of SaidIt->Notabug involves converting data from saidit to nab's format. This involves tracking a mapping of all saidit content to the nab copies. This is the mapping of this submission for example

The downside of this is that my Saidit ingest bot serves as a central authority, you have to trust it to be accurate, I could shut it down, or have it lie about content.

This will be true of pretty much any ingest from a more centralized site that allows content editing. (If content never changes this could be different)

I don't think possible to do a totally decentralized federation of centralized data sources as a result. If you ran a nab peer you'd be able to easily replicate my ingest of SaidIt (even in realtime) but other than serving to mirror that content you wouldn't be able to contribute to the health of that federation (The SaidIt ingest bot is a single point of failure) you could run your own of course, but this would duplicate the content and you'd have your own ids/mapping

For many of the same reasons, doing a two-way sync from notabug <-> centralized service is going to be difficult to pull off, and will always have that single point of failure in the ingest. But once ingested into nab, mirroring that content does get quite simple.

With a wiki this potentially gets more difficult (even in the unidirectional case) because you would want to sync edits into nab. Currently saidit edits do not get reflected in nab as it only has a reliable way to detect new items, not new edits to existing items (this is also what makes realtime ingest of saidit votes currently impossible at best these would be a periodic poll and you can't do that realistically against all of saidit's content)

Would you consider modifying the voting mechanisms for more precise results?

The data schema defines buckets for the existing proof of work-based voting, but the displayed scores are aggregated and signed by what I call a tabulator (can be thought of as part of the indexer)

It's possible for spaces to define alternate indexers/tabulators (though these must run as a service somewhere a bit like a bot) The vote counts returned by the tabulator can be totally arbitrary and do not have to correspond to the PoW vote data in any way.

This makes it possible for the nab data structure to support different vote types and communicate the results of those votes between different peers. If/when we figure out the best way to pull in saidit scores I will likely have the SaidIt bot present as a tabulator that simply records the totals from saidit in notabug's tabulator format, and have a space that uses this for sorting saidit content. This obviously wouldn't allow for sending votes back though.

I have some ideas I'd like to hear your take on. Also "categories" and/or metatags?

This is one of those things that working on the saidit ingest got me thinking about after I built out the separate https://notabug.io/t/saidit.all topic structures. I think it makes sense to have nab support sub topics (a bit like usenet) so a topic of programming.javascript.react would propagate to programming.javascript and just programming topics. Doing this is going to require a significant change in my data structures and a large re-process of my database, and is something I want to get in place before we setup the saidit peer because it will be harder to do afterwards.