From IndieWeb
Jump to: navigation, search

IndieWebCamp projects related to wiki-page hosting/creation/editing on your own site.

Existing Projects

Smallest Federated Wiki

Main article: Smallest Federated Wiki

Smallest Federated Wiki was conceived/created/developed/launched at IndieWebCamp 2011


Main article: MediaWiki

MediaWiki runs,, and is used by IndieWebCamp community members like Tom Morris on


Main article: ikiwiki

ikiwiki is another independent site wiki, and is used by IndieWebCamp community members like Philip Durbin on


Main article: TiddlyWiki

TiddlyWiki is another independent site wiki that can be self-hosted and used as a personal website. See TiddlyWiki for examples.


  • WikiSuite — no known IndieWeb community users


  • Wiki.js — no known IndieWeb community users

The below should be moved to its own stub page and linked here with the {main} template.

Wiki.js is another open source alternative to MediaWiki. It runs as a node.js (javascript) application.

Some advantages of wiki.js, especially in comparison with MediaWiki, include:

  • More visually pleasing, modern interface - uses material icons and user interface
  • More modern development and hosting platform - based on javascript (node.js)
  • Better access control, privacy options
  • sync pages with a git repository
  • better search functionality built-in
  • better, simpler documentation
  • rapid development - a beta version 3 of wiki.js is due summer 2021 with several new features

Some limitations of Wiki.js:

  • No support for backlinks
  • Developed by just one person
  • Multlingual / translation support not as good as mediawiki’s
  • There have been some security issues
  • Harder to install correctly, can't use shared hosting
  • No 3rd party managed hosting options
  • No email notifications
  • Have to create separate url path for each page, no spaces, etc.
    • Seems like this could automatically be done, like in wordpress, mediawiki
  • No easy link curation - paste in a link or reference and have it automatically load a title and potentially other information, like wordpress, wallabag, other options have
  • No structured data? - page properties, metadata, content types
  • No page redirects, aliases, synonyms
  • Can’t edit tag/category pages or use pages as homes for tags/categories
  • No support
  • No SEO enhancements
  • Not clear on caching, performance enhancements - several complain it’s slower than mediawiki
  • Site appears to not work if javascript is disabled
  • No section, block editing / linking
  • Can’t see recent changes
  • No RSS/Atom feeds
  • Not as much rich multimedia / embedding support - although raw HTML input is available
  • WYSIWYG and markdown editors aren’t easily interchangeable - you have to pick one. It would be nice if the WYSIWYG editor saved in markdown format, like some third party open source editors do.
  • No double bracket wiki linking
  • No minor changes, change summaries
  • Not clear on spam, abuse blocking
  • No concurrent editing, conflict handling - although version 3 will apparently support this
  • No option to host as a static site

Project Comparison Sites


Thoughts on how an IndieWeb wiki could be implemented

Features for migrating from PBWiki

There was a discussion on 2021-253 in chat between Tantek Çelik & Ryan Barrett about wiki / topic / evergreen pages on a personal site (in particular, prompted by Ryan Barrett asking Tantek Çelik how his own personal wiki implementation was going as a follow-up from citing his PBWorks wiki), and which features were important / interesting. Needs extraction from logs at:

Static Pages Plus HTTP Headers

This is a brainstorm by Tantek Çelik, originally discussed in IRC 2013-091, captured here for potential iteration.
[1:21pm] tantek: I'm actually thinking of, how do I just use a static HTML page itself as the storage for a "wiki" page.
  • static HTML files as their own storage of their current/latest version
  • previous versions stored elsewhere (e.g. the filesystem)
    • date-time-stamp filename suffixing convention
    • new link rel to link to the previous historical version
    • each version linking explicitly (via invisible <link> or visible hyperlink) to the previous version, and current version.
      • this places a content requirement on the otherwise unrestricted HTML files.
      • alternatively if this information (what is the previous version) is kept in a database cache, it can be sent with the server as an HTTP LINK Header with rel value.
    • the combination would satisfy essential qualities 2,3,4 listed above.
  • for editability, it might be a neat trick to write software that made any static HTML page on your site automatically "editable" if you happened to be signed in with Web Sign-in / IndieAuth.
    • similar to revisions/versions, a page could link to its editing interface/version/query parameter with a rel link as well, e.g. rel=edit, which has been previously proposed as part of Universal Edit Button: links for AJAX-driven edits but could be used for server-based editing state as well. E.g. href="?edit=1". Again this might be best sent as an HTTP Link Header.
    • goal: make a page editable without putting any meta/link in the page itself.
      • should be possible to use HTTP LINK rel=edit to an editing script (for browser plugin discovery)
      • perhaps an HTTP LINK rel=script to execute an editing script (for browsers that don't know about rel=edit).

Interface - there are many ways personal wiki software could provide editing / version browsing features, here are a few:

UI for browsing previous versions:

  • slider in Etherpad
  • what puts up in the header on archived page results
  • That ins/del slider demo I made may be of interest/use 06:40, 2 April 2013 (PDT)

Brainstorm summary:

  1. static HTML page as its own storage
  2. *-date-time suffixed versions of said page in the file system (or perhaps in the YYYY/ directories), linking to latest version and previous versions with rel values
  3. HTTP LINK headers for browser-editing-plugin discovery and javascript-based fallback
  4. Access UIs via query parameters e.g. ?edit=1, ?history

Related project:


Other projects that may be of help with designing/creating/building a wiki content system.

  • MementoWeb
    • -1 memento seems horribly overdesigned, e.g. has way too many rels, none of them actually useful: original, timegate, timemap. - Tantek 16:49, 1 April 2013 (PDT)

See Also