wiki-projects

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

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

MediaWiki
MediaWiki runs indiewebcamp.com, microformats.org/wiki, and is used by IndieWebCamp community members like Tom Morris on http://wiki.tommorris.org/

ikiwiki
ikiwiki is another independent site wiki, and is used by IndieWebCamp community members like Philip Durbin on http://wiki.greptilian.com/

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

WikiSuite

 * WikiSuite — no known IndieWeb community users

Wikijs

 * 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 schema.org 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

 * WikiMatrix - compare the features of various wiki options
 * List of wiki software - list from Wikipedia
 * Comparison of wiki software - comparison tables on Wikipedia

Brainstorming
Thoughts on how an IndieWeb wiki could be implemented

Features for migrating from PBWiki
There was a discussion on 2021-253 in chat between undefined & about wiki / topic / evergreen pages on a personal site (in particular, prompted by  asking undefined 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:
 * https://chat.indieweb.org/2021-09-10#t1631298427718000 and rest of day
 * https://chat.indieweb.org/dev/2021-09-10#t1631302774228600 and rest of day

Static Pages Plus HTTP Headers
This is a brainstorm by undefined, 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)
 * use a h-feed to list keep track of previous versions so that one can easily subscribe to changes made
 * date-time-stamp filename suffixing convention
 * 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.
 * new link rel to link to the previous historical version
 * each version linking explicitly (via invisible  or visible hyperlink) to the previous version, and current version.
 * security: as always, when using HTML files for static storage, one must ensure that their project is not vulnerable to directory traversal where a malicious actor can use manipulated URLs to access private content.
 * 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. . 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 archive.org puts up in the header on archived page results
 * That ins/del slider demo I made may be of interest/use --Waterpigs.co.uk 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:
 * http://microformats.org/wiki/version - for new link rels for the previous version/revision and the current/latest version.

Features for a personal wiki
There was a discussion in chat about what features a "personal wiki" should have. A personal wiki is a wiki written by one person for themselves or for a select audience. A select audience may be enabled to read the wiki using capability URLs or by signing in to view specific pages.

's brainstorm
James likes the idea of having a personal wiki for documenting his thoughts on concepts as opposed to writing full blog posts on a particular topic. For instance, James might want to create stubs for topics he is thinking about and add links, quotes, and notes as he learns more about the topic. This would create a useful point of reference for a particular topic.

James is interested in a personal wiki separate from his site. This would help achieve a clear context separation between long-form and short-form content. With that said, the nature of a personal wiki is to serve one's self: it is a personal wiki. Thus, a self-hosted, private wiki may be preferable.

The key features such a wiki would need are:


 * create a post
 * update a post
 * delete a post
 * search through posts
 * view revisions to posts
 * find recently updated pages

Others
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)