This proposal exists both as a personal reference incase I would ever like to return back to begin working on this idea and a public-facing sketch of an idea I see as having a lot of potential to move more people onto free-software platforms if done right. If reading this provides you inspiration, feel free to work off of the ideas below.

Problem: Communal Knowledge Has No Suitable Host Platform

One of the most powerful things to come out of the internet is its capacity to act as a reservoir of crowdsourced knowledge. We might think about websites such as Wikipedia which compile academic knowledge — knowledge which is researched, assembled, and read to learn more about what is true. In a way, this sort of knowledge is knowledge-for-its-own-sake.

But the internet is also home to a different kind of knowledge — practical knowledge. Knowledge whose end isn’t just representing an abstract truth, but very directly oriented towards some practical goal. In other words, it’s less concerned with describing ‘what exists out there’, but instead ‘how to do things’.

The internet is a valuable tool for this type of knowledge in that it creates spaces whereby even very niche communities can find spaces to hold discussions and put their heads together. The sorts of discussions that would traditionally be confined to local word-of-mouth and disappear can now be continuously unearthed, accessed, and preserved by quite literally anyone in the world.

The anonymous, instantaneous, and horizontal nature of the web adds to this, creating an environment in which decentralized experimentation can allow for the rapid testing and selection of cutting-edge ideas. This information tends to occupy a space of being too fresh for conventional outlets to fully verify, but still useful to those who have limited options — potentially wrong information is still more useful than no information at all.

Out in the wild, you’ll find many examples of this:

• Members of the same metro area openly discussing which school system in the area they believe to be the best, relating their own personal experiences, and talking about the specific ways in which official metrics don’t reflect the whole picture.

• Communities centered around legally gray (or black) non-state-sanctioned activity providing a database of resources that’s continually subject to change, as there’s active forces constantly pushing for either takedown or outmoding of prior methods.

• People with a specific hair type collaboratively building a Google Doc recommending specific routines, products, and tips they’ve found for styling and maintenance.

• A group of people with a certain medical condition facing barriers to research (and treatment in certain jurisdictions) putting together spreadsheets and wikis summarizing existing research and creating guides for self-treatment in situations where official avenues aren’t available.

There exist platforms and communities whereby open discussion and exchange of knowledge occurs (even if these spaces are becoming alarmingly endangered), but compilation of knowledge is a different story. Traditional wiki platforms (MediaWiki, Wikia, etc.) do not work for this purpose, as their layout and complexity are overkill for the purposes of communal knowledge. Those platforms are built from the ground-up to handle knowledge-for-its-own-sake use-cases.

However, there still is promise contained within the wiki concept as a whole. Wikis designed to be simpler and more lightweight (closer to developer documentation than encyclopedias in structure) make an excellent fit, and that’s why advanced or organized efforts often use these as a base. Unfortunately, the closest solutions are targeted towards developers (Mkdocs, Sphinx, etc.) and some level of technical savvy is expected to get them running.

The problem is information online gets compiled by people of all different walks of life. Not all of the communities engaged in this activity can reasonably be expected to have the knowledge and resources to self-host. This is why for the majority of these communities, they’ll make do with sub-standard platforms.

The bar for sub-standard here isn’t just platforms that are proprietary or non-user-respecting. A lot of that behavior has been normalized in the modern landscape, and that alone often isn’t enough reason for people to switch. On the other hand, when a platform is genuinely and obviously awkward to use for a purpose, that opens a much larger window for adoption.

In place of wikis, people are using Discord channels, Reddit sidebars, Google Docs, and Twitter threads to preserve their information. None of these platforms are at all remotely designed to preserve knowledge. A lot of them have terrible search functions, are subject to arbitrary deletion and takedown, have limited tools for cleanly organizing the information in question, and in some cases are not clearly intuitive to find.

This is alarming as sites like Reddit and Twitter, which now host over a decade’s worth of obscure information not readily found elsewhere — have started arbitrarily closing their walls, hiding content, and restricting API access more and more. The more this keeps up, the more knowledge society will lose due to entirely preventable reasons.

The commercial market has yet to provide a better alternative, because these social platforms prioritize in-the-moment engagement over evergreen knowledge. Just look at what happens to any news article published a decade ago. But, there is undeniably a hole to fill and it’s a hole most people haven’t thought about filling. And it’s on weird niche stuff like this where the best opportunities lie.

Proposal: Federated Wiki-Farms Can Fill This Niche

The proposal laid out is actually relatively simple: a free-and-open-source (FOSS) wiki-farm which allows for the ability to not just self-host individual wikis but full on instances.

A wiki-farm is defined as a service which allows users to create and manage their own wiki without having to host it themselves. The most well-known example of this is the aforementioned Wikia (now called Fandom). On Wikia, if you want to make a wiki, you just sign up for an account, use their editor, and they publish the pages for you. That lowers the barrier of entry to wiki-creation significantly.

Of course, as stated earlier, Wikia targets itself towards nerd communities and fandoms so the intended purpose is different. But there’s no reason why you can’t adapt wiki-farms to a simpler format, one that resembles the types of simpler wikis we see be used by these communities.

Instead of having a single central host or expecting everyone to self-host, treating each host as a multi-user multi-wiki “instance”¹offers a level of flexibility between control and accessibility.

Any such solution would have to prioritize data portability and redundancy in its design. The flipside of an instance-based model is that community-based hosts (unless managed responsibly) have a higher risk of going offline for a myriad of reasons.

Using a common, generic format for the articles (such as Markdown) would allow for easier importing/exporting of data. Having a backup and import system that’s visible and encourages widespread saving and mirroring of data would go miles to making the costs of an instance going down less catastrophic. Perhaps federation could allow for someone to specify a second instance for automated backups?

Prospects: Can We Use Ibis?

Everything I’ve outlined above is purely theoretical, and a rough sketch of what I would see as an appropriate starting point for designing a solution to the problem. The following is some notes (as of March 2025) regarding one possible avenue for building towards this.

When looking for a solution for a problem, it’s generally advised to see if one can build off of existing work first as opposed to jumping into developing from scratch. If such a project exists with enough compatibility in design, goals, and vision, it makes more sense to contribute to the existing project and pool efforts rather than going out and re-duplicating the work for yourself.

One possible base may exist for this initiative. Ibis² is a self-hostable federated wiki software very early in development. The project currently is being developed primarily by Nutomic, one of the lead developers behind Lemmy (a popular federated Reddit-alternative also running on ActivityPub).

I bring up Ibis, because it does seem to check many of the boxes I listed above:

• FOSS-first, non-commercial design, with self-hosting as an option

• Relatively simple interface and light hosting requirements

• Articles which utilize markdown with a live preview

• Usage of federation to duplicate articles across instances for redundancy

However, there is a lingering question that should be taken into account. The purpose Ibis was designed to specifically to compete with Wikipedia; the developers were inspired to start the project due to concerns surrounding Wikipedia’s administration. Of course, a large networked encyclopedia is different in structure than a local wiki for a community’s knowledge. Is that a founding vision which will eventually produce a product that is suitable for communal purposes?

The developers seem to think so, which is reassuring. But if that is the case then, I’d like to offer some concrete suggestions to better bring Ibis in line with these usecases:

• Allow for the ability of one instance to host multiple wikis for accessibility purposes. With Ibis currently, each instance is its own wiki, and in order to create a wiki, one has to self-host. Offering the option³ for instances to be configured either as “multi-wiki” or “single wiki” can allow users to register on an already-running instance and host their wiki there.

• Begin a campaign to target these kinds of communities and get them on Ibis. The Ibis main page lists use-cases such as fandom pages or developer docs, but actively listing uses not usually mentioned and also identifying, reaching out, and assisting smaller communities to port their stuff would go a long way.

• Add a basic toolbar to the markdown editor. Currently getting an article up requires you to directly input markdown, which does require some prior knowledge of the syntax. Having a built-in toolbar which inserts styles such as bold/italic or heading size would improve accessibility.⁴

Assuming none of these suggestions directly conflict with the intentions or wishes of the lead developers, realistically anyone (including me) could take upon these tasks, either as a PR or an independent word-of-mouth marketing campaign. Of course, it’s worth having an open discussion about whether or not this strategy is worth pursuing, if Ibis is a project suited for this end, and if the suggestions listed above are the best ways to see that end through.

This post is simply the first draft of notes towards that end. Any further updates regarding progress from either me or anyone else on this task, I will continue to follow up with.