Welcome to the CommunityWiki!

We talk about communities both online and offline: management, teaching, conflicts, mediation, and some tech talk mostly about tools used for online communities.

Feel free to join in. See WelcomeVisitors to get started as a contributor.


WikiMeet are CommunityWiki’s InternetOfficeHours – regular video calls on no specific topic.


If you’d like some contact and this time is insane for you, there’s also LionsInternetOfficeHours:

  • Every Sunday
  • Noon, Seattle Time (8p UTC)
  • (same Discord server)


We take notes in RiseupPad during meetings and them move them to CommunityWiki


Alex doesn’t want to meet. To compensate the inability to see him, he sends us pictures. ๐Ÿ˜น

See also


Early draft. Please help us shape this manifesto

Complex systems have failed us. Therefore, we need simple systems.

What is a simple system? A simple system is a system which can be maintained and completely understood by one person.

What's so good about them? They make sense.

Ideas matter. Focus on IdeaReuse: write thorough docs. The system does not have to be open-source, because systems that are simple enough can be reimplemented when needed.

How to make my system simple?

  • Keep protocols unambiguous. When every client implements a protocol in a different way, simple systems fail. Therefore, make it hard to implement them in a different way.
  • Drop features when they are not needed. But note that simple doesn’t mean easy or primitive. Do not drop features when they are hard to implement. Do not drop features when they are hard to use.
  • Use open standards because they make the software more reliable and interoperable. Also prefer using existing and known standards over obscure ones when it makes sense.
  • Think about humans first and machines second. After all, computers were made to serve people.
  • Make sustainable software because such software is expected to run for ages. It doesn’t mean it has to be bug-free. It means that the bugs can be worked around. It often implies open source.
  • Make it easy to install your software. It is easy to install software that has few dependencies, few requirements, where installation is short, where configuration is either automatic or obvious, in one place, where documentation is easy to find and easy to follow along; it has a section that helps people get a running system as quickly as possible.
  • Make your software extensible. Extensible software is simple software that doesn’t try to cover all the use cases. Instead, extensions can be added successively as those use cases become more obvious. Note that having extensible protocols is not a good idea.


Let’s keep it in tree mode to solve questions one by one.

  • ๐Ÿ„๐Ÿฆ agreed that:
  • ๐Ÿ„: I have gathered several links on CyberRachel related to PermaComputing?. We can get some inspiration:
  • ๐Ÿฆ: I think CodeReuse often works against Simple Systems, because all code embeds assumptions, and trying to fit assumptions with incoherent assumptions makes things messier and harder and more complex, not simpler.
    • ๐Ÿ„ gave an example when CodeReuse is not that bad (and it doesn’t contradict the statement given by Lion; note the word often): โ€œTake a look at any web wiki (that is, everything but Phoebe and TwinWiki which run on Gemini). They all use HTTP libraries, I’m sure none of them reimplemented it. I don’t think it makes them more complex. In fact, it makes them simpler! Sure, there are assumptions, but HTTP is thoroughly documented, just like in one of our principles.โ€
    • ๐Ÿ„: I understand why you say that โ€œCodeReuse often works against Simple Systemsโ€ but I can’t think of any example. Can you find one please?
      • ๐Ÿฆ: I don’t have one example, I have 10,000 examples. I personally think that almost the entire history of programming is an example.
      • ๐Ÿฆ: Consider: You want to create a simple website. You use Django, because that’s what you were taught. You’re reusing code, but it’s far in excess of what you actually need to do what you want to do. You end up writing your own systems for what Django has automated, because Django’s system was written with assumptions that don’t really apply for your situation. For example, you’re writing a wiki like Oddmuse, and Django admin interfaces assume that Users have passwords.
        • ๐Ÿ‘จโ€๐Ÿš€: But if you want user without password you can just disable it, If you want to change anything in django standart components - you can configure or change it without any pain. You don’t need to rewrite whole framework. Also, custom components for frameworks can be reused, and it is wery useful and allows to keep systems simple - programmers don’t need to write own compoments every time.
      • ๐Ÿฆ: Yes. For example, you are attempting to write a GUI that has a right-click circular menu. You discover that your GUI library has no way to implement this feature, except by a very, very strange route – by creating transparent pop-up dialogs, (say) and very carefully positioning them on the screen. You have to do some round-about things, perhaps going outside of the capabilities of the GUI system at times, in order to get what you want. It’s like this, because the library was written with assumptions that don’t really apply for your situation.
        • ๐Ÿ„: Good examples! Comparing your examples and mine, the one with wikis, I noticed this: using implementations of protocols is ok, using complicated frameworks that run using the same implementations of protocols is not ok: HTTP lib is simple, Django is not.
          • ๐Ÿฆ: OK, but I’m saying something deeper than that. I’m not saying that “complicated frameworks” is at issue; I’m saying that all frameworks are in question, by the simple fact that frameworks embody assumptions. There is a fundamental ignorance between the author of the framework, and you in your situation.
      • ๐Ÿฆ: I’ve written this with the examples of off-the-shelf code-reuse, but you can also apply personal code reuse. Just it’s harder to find examples that everybody can relate to, because it’s necessarily discussed in terms of personal projects, which by definition, others don’t know about.
      • ๐Ÿฆ: Abstractly, and like I said before, every library or continent of code is written as a collection of steps and promises. Violate those promises, and you have a hard time doing what you’re doing. CodeReuse means pulling in a continent of code from somewhere else, and now you are dealing with all of the dependencies and requirements and assumptions and complexities that that continent of code brings with it.
    • ๐Ÿฆ: The people I know who are masters of SimpleSystems write by hand the things that other people go to great lengths to “oh, let’s use this package, let’s use that package.” They write it by hand because they understand that the mechanism that they need is simple, does not require much code, gets maximal effect, and creates minimal exposure. They look at the mass of code that comes from some package, and they realize, “I do not benefit from pulling in that entire body of code.” They look skeptically at code, not eagerly. They know what is meant by the Go maxim, “The Go player is reluctant to make a move.”
  • ๐Ÿ„: The Law of Leaky Abstractions. Are leaky abstraction ok for simple systems? After all, some abstraction leak may provide extensibility.
      • ๐Ÿ„: For protocols, it is not ok, of course.


Wiki movement is close to being dead. We all know that. One can only imagine how this wiki used to be years ago. Lively, pulsating. Something like that. However, since Epoch 2020, CommunityWiki seems to be getting back on legs!

  • WikiWikiWeb is dead
  • MeatballWiki is dead
  • EmacsWiki is close to being dead. Daily edits still occur but it’s probably dust compared to the days of EmacsWiki glory (there were days like this, right?)
  • MoinMoin is dead
  • Name a wiki. It’s probably dead.

But what’s not dead? Atlassion Confluence (a proprietary product), WikimediaFoundation and wikis on wikifarms like Fandom (used to be Wikia) that describe modern media. Even wikis on services like GitHub or GitLab? are not widely used.

WikiPedia damaged everyone, people have FearOfEditing.

We have a dream. We have a dream that one day wikis will be a dominant form of collaboration. We want communities to be centered around wikis, not chats or source code repositories. We want people to lose their FearOfEditing and just write.

And we think it is going to happen. It won’t be the same as in the days of WikiWikiWeb, of course: wikis will become more personal. Note the whole DigitalGarden, SecondBrain? and [[Memex?]] discussion circulating around the nets. People are starting to realize they need something wiki-like. Perhaps, a vast network of loosely connected wikis is what we really need.

The revival

Remember that MoinMoin is dead? MoinMoinTwo? is actually being developed. Cool.

WardCunningham is also busy developing SmallFederatedWiki. There are Zoom meetings every Wednesday and an active community around that technology.

๐Ÿ„ TimurIsmagilov: Do you have your personal wikis? I started one in July or August or something like that. I tried MediaWiki and MoinMoin but ended up developing my own engine MycorrhizaWiki. So far my home wiki (called CyberRachel) has around 1150 pages. It’s enough for someone to spend a noticeable time consuming all the content I’ve generated. That’s the plan. I will tell my family to publish a snapshot of Cyberrachel to the net when I die. Something for researchers to research. Part of legacy, yeah.

And more and more people start their personal wikis or similar projects. It’s something to explore.

The revival of the wiki technologies is knocking at the door.

What do we do?

So, what do we do? How do we revive wikis? I think developers and users of smaller WikiEngine, not something big like MediaWiki, should unite. Here, on this wiki, for example. There are at least two of us: TimurIsmagilov with his MycorrhizaWiki and AlexSchroeder with his Oddmuse and Phoebe and the whole TransjovianCouncil concept. Let’s find more people and bring them together. We’ll figure out what to do, maybe. And if we don’t, well, so be it.

Who do we call here? Who’s developing wiki engines nowadays?

Wiki engines for the new decade

Assuming the whole personalization of wikis trend, here are some things features modern wiki engines should seriously consider.

1. Embedded {b|gem|ph}log

For every user, perhaps. Fandom used to have it. I’m not sure about now, the site is so difficult to navigate that I don’t know how things have changed. has a Diary. Afaik, CaseDuckworth? ~acdw seems to running Phoebe which also has blog-like functionality. Doubleloop has their site separated into Stream (blog) and Garden (personal wiki).


GoogleDocs? has it! People use it. People need it.

3. Integration with other media

First of all, all engines should adopt OpenGraph, preview of links in messengers is really cool. MycorrhizaWiki already does that; it will also display previews for RocketLink by fetching opengraphs.

  • ๐Ÿ„: Alex blocks preview-hungry bots and is generally opposed to bots.

I also want to add copying of data from other sites. Something like cloning tweets, posts, whole webpages. It’s really convenient for personal wikis. See Mycorrhiza:Idea/Import

  • ๐Ÿ„: Is it legal to copy articles, including paid ones, into your own wiki?
    • What if you share those copies?

Also, bots that remind people of new edits on wikis should be made. For example, I’ve made a Discord bot for KlavaWiki that checks for new edits on the wiki every 10 minutes and notifies people in a special channel if there are any edits. It made people more aware of the existence of the wiki.



See HalfVisualEditor and VisualEditor.

5. Structure

Be it a table of contents on which to hang things like Confluence, or some sort of agenda like OrgMode.

This may include showing just a subset of context pages from the table of contents: all siblings at the same level and all child pages, for example. Examples include MycorrhizaWiki, Notion, EverNote, GitBook, etc. A common feature.

Here’s how it works on mycorrhiza. For example, we have this structure of hyphae/pages:

  • a
    • a1
    • a2
      • a2a
  • b
    • b1
  • c

For hypha a, this is what is shown:

  • a
    • a1
    • a2
      • a2a
  • b
  • c

For hypha c, this is what is shown:

  • a
  • b
  • c

6. BackLink

Some people claim to need this feature for their PersonalWiki. TimurIsmagilov does.

Intersite backlinks can be done with something like Webmentions. Seems like a great way to connect wikis together.

Locally, the wikis descending from WikiWiki all had backlinks implemented by having their page title be a link to a search of that page title. WikiWiki had it, UseMod had it, Oddmuse has it.

Unsolved wiki issues

Yeah, wikis are problematic, and we’ve known this for many years. Let’s talk about these issues. Let’s spell them out, and admit that we don’t want to solve them and why.

Wikis are chaotic and we can't find anything

Search is an unsolved problem, specially when not all pages are equal. Sure, on Wikipedia they are. But in an environment with blog pages that age, with projects that shut down, those pages are not as important as other pages. Integrating this information into search engines is hard.

One way to solve this for blog wikis is to sort wiki pages by date descending (followed by all the non-date pages), and search them in that order. Hardly a generic and resilient technique.

Another way to solve this for projects (common endeavours by groups of people) is to put each project into a separate namespace, like the RPG campaigns on Campaign Wiki, for example. That works well for self-contained projects.

If the projects are overlapping, there’s additional overhead: where to put new pages, how to link pages in other spaces, and so on.

A special syntax could be introduced to indicate how important a page is. A page which starts with this โฌ‡๏ธ would be on top of search results:


Results could also be viewed by view count for the last year. Popular pages are probably what you want.

Adding structure is less interesting than adding content

New stuff is added but nobody maintains the forward indexes (menus), nobody adds tags, nobody cleans up tags, nobody deletes outdated text, nobody rewrites related pages because everybody prefers dumping a new page into the wiki and hopes that readers will know which ones are the deprecated pages and which are the current pages. Needless to say, this is why wikis fail.

It is morally acceptable to edit other people’s signed texts. BeBold. But people don’t really do it.

A wiki engine that enforces a form of structure could facilitate this problem. See MycorrhizaWiki’s tree structure. You just end up categorizing everything.

Adding text to your own blog is more rewarding that donating it to a wiki

Writing a page on your blog is a way to get credit. People like you, they subscribe to your feed, they leave comments on your posts, you, you, you! You are king!

On a wiki, not only are you limiting your audience to your fellow wiki members (probably no more than a handful of readers), but it will get drowned, reworked, vandalised and forgotten. There’s a lot of work you need into the system for it to work. The only reward is when the current wiki editor crew is jiving and jamming and there is joy in seeing that interaction, there’s joy in seeing your text improved by others. But seeing is believing and when you’re starting out, it is hard to believe.

Perhaps that’s why PersonalWiki have become more popular.

Wikis for community work great if they describe something in particular. A popular TV show, book, etc.

KlavaWiki case

We’ve recently started a wiki called KlavaWiki for an active keyboard community in Russia. Really active community, I mean. There were accounts created for each and every one. Now go to and see that it’s not that lively (still more lively than most wikis out there). I’ve heard people talking things like โ€˜Yeah I’ll finish writing the stuff and publish a polished version to the wiki laterโ€™. Until then, they are posting thoughts into chats and discuss it there. Well, it makes sense, of course, but then you can’t find anything. Chats are ephemeral. Wikis are the true power. Over time, surfing a big, aged wiki is so much better than scrolling through messages in a chat room.

NB. The keyboard community I mentioned spent two weeks configuring the discord server. Several hour-long voice calls, detailed discussions, etc. I played an active role in that. And it’s still nowhere as good as an active wiki could be.

Update: slowly the wiki has become more filled with content.

See also

โ€œAnnouncing Stack Overflow for Teamsโ€:

For a while developers thought wikis might be the solution. Anyone who has used a wiki for this purpose has probably discovered that not very much knowledge actually makes it into the wiki, and what does is not particularly useful, doesnโ€™t get updated, and honestly it just feels like a bunch of homework to write a bunch of wiki documentation about your code when you donโ€™t know if it will ever help anyone.

Discussion trees


  • Alex: I see Confluence being used every day at the office. I see people talking about ZettelKasten and Roam every now and then. I see single-person VimWiki mentioned a lot. TiddlyWiki is still being recommended to others. So I agree! Wikis are not dead. They have simply splinted and mutated.
    • ๐Ÿ„: Do you think Confluence is good? I’m skeptical towards it and I’m not really willing to try it out but I expect it to be quite good. ZettelKasten, I hear this word so often! People are hyping hard. VimWiki, a local-first wiki, I can’t imagine it being practical in any way. TiddlyWiki is quite cool. I keep wondering, do people’s personal wikis are mostly text? Mine’s is about 50% media and I can’t imagine it being different. Also, I can’t imagine TiddlyWiki being comfortable for images. I mean, I tried it. Oh, there is also Notion. It’s slow, laggy, complex, but people seem to like it. They have a great usage of emojis btw.


  • Alex: Love the intro! ๐Ÿ˜
    • ๐Ÿ„: A good intro makes a good speech! One day this page will go to the wiki history…


  • Alex: I don’t know whether Emacs Wiki was ever really “alive”, actually. I must have posted about a thousand pages before other people started contributing on a regular basis.
    • ๐Ÿ„: That EmacsWiki story is kinda disappointing. Why don’t people just get the idea and start contributing their time?

New pages for products


  • ๐Ÿฆ: they have staying power
    • ๐Ÿ„: For some reason for some people simple systems are more difficult to use. Do we take that into account?

Stuff by ๐Ÿฆ LionKimbro

  • forget the web browser – who needs a web browser? HTTP doesn’t have to mean HTML
  • schematics – schematic as visual form of communication; not well supported by text editors & text entry widgets
  • mass quantities – translating personal scrips and scraps to globally overlapping constellations
  • the experience & philosophy of community – why do you want to collaborate with those people in the first place?
  • bar-coded data, and human-interpreted content

Mobile ecosystem

CiprianCraciun: I think that one major reason why wiki’s are “dead” is the emergence of smart-phones and the whole “mobile and application” ecosystem. When wiki’s were popular, the majority of contributors and visitors used desktop web-browsers (in fact there was no “mobile” then). However, the wiki’s didn’t transition well to the mobile-first world we are in right now. Thus, perhaps if wiki’s are to be revived, then perhaps at least mobile-friendly consumption should be a priority.

new: 2021-08-23 09:48 UTCAlex Schroeder: Yes, could be. Certainly editing a wiki via the mobile browser is painful. I don’t like to do it because navigating a big text area and finding the place where you wanted to edit something is cumbersome. Writing more than a few lines is also cumbersome. And then there is the whole issue of making the CSS mobile friendly.

The only aspect my wiki has addressed is comment pages (disabled on this site). Comment pages are like Wikipedia “Talk” pages, but they have a form at the end, and whatever you type there is simply appended to the page.

Something I would have liked to add is section or paragraph editing. Wikipedia has section editing. You this limits the amount of text you have to navigate in your text area.

The CSS could always use more work, unfortunately.

If you have any ideas, I’d love to hear more!


Gemini is both a simple, new protocol to serve HyperText, and a simple, new markup language. It has it’s own site, Project Gemini. That’s where you can find the specification, as well as clients and servers.

It was born out of various needs:

  • the need for a simpler web, something that doesn’t need the behemoth of a browser as a client
  • the need for an update to gopher: UTF-8, doing away with the menu/file dichotomy, and so on
  • the wish to specify it in such a way that it could not easily be extended

The last item, for example, led to the decision to not use the typical “headers” for requests and responses of the Gemini protocol. You know the ones, from both mails and HTTP. It does have status codes (but fewer than the web), but it doesn’t have methods such as GET, PUT or POST. It has MIME-types, but it doesn’t have content negotiation.

The Gemini format (also known as GemText) is particular in that it is line-oriented.

A line of text is a paragraph, to be wrapped by the client. It is is independent from the lines coming before or after it.

A list item starts with an asterisk and a space. Again, the rest of the line is the line item, to be wrapped by the client.

A link is never an inline link like it is for HTML: it’s simply a line starting with an equal-sign and a greater-than sign: “⇒”, a space, an URL, and some text.

It’s weird, it’s small, and it’s different.

See also:

## On Gemini

Learn more...


Define external redirect: GoogleDocs CaseDuckworth PermaComputing SecondBrain Memex GitLab MoinMoinTwo

EditNearLinks: TwinWiki MoinMoin WikiEngine WikimediaFoundation GitHub MeatballWiki UseMod WardCunningham EverNote MediaWiki WikiWikiWeb HyperText EmacsWiki WikiWiki VimWiki


The same page elsewhere: