Wiki Federation

What is “wiki federation”?

The protocol

Suppose there's a protocol, to which a given wiki (or, likely, "any wiki built on a given wiki software platform (e.g. pmwiki)") may conform. (The protocol may involve an API, certain assumptions/invariants, etc.)

The following is then true of a set, or "community", of wikis all of which conform to the protocol:

Any wiki may link to any other wiki.

Well, of course this is already true—you can create a hyperlink to anywhere you like. But intra-wiki links are typically treated differently from normal hyperlinks to arbitrary URLs—additional capabilities apply to them, such as:

intra-wiki links are checked for existence before being rendered as HTML (and rendered differently depending on whether the link is to a nonexistent or dead page, etc.)
intra-wiki links may be categorized by "wiki group" or "category" or "tags" or other content or metadata of the target wiki page (and, again, rendered differently based on such categorizations)
etc.

The protocol extends these properties (in some straightforward way) across the entire wiki community.

Any wiki may import/transclude any page (or other chunk of content) from any other wiki.

This does not require that wiki page (markup) format be standardized across all wikis (either across all wikis in a community, and certainly not across all wikis that conform to the protocol). It only requires that a defined, predictable conversion function exist between the wiki page/content definition format of any two wikis in the community.

The simplest way to do this is to define some common, baseline format, into which and from which any conforming wiki software may define its own conversion functions (as a requirement of protocol conformance). Two obvious candidates for such a common format are plain text and HTML (each has their own drawbacks and advantages). Needless to say, conversions to/from either of these formats—or from any plausible common format—are necessarily imperfect. This is fine.

Any particular wiki software then has the option of defining specific conversion functions from the content definition format of any other particular wiki software to its own content definition format. (For example, perhaps pmwiki defines a specific conversion function from the dokuwiki format to the pmwiki format. Then when a pmwiki-based wiki transcludes a page from a dokuwiki-based wiki, the transclusion is (near-)perfect and captures the content with surpassing faithfulness; but a transclusion from a pmwiki into a dokuwiki, or from a MediaWiki into a pmwiki, etc., would have to first go through the common/baseline format—resulting, no doubt, in loss of style information, etc.)

Any wiki may search/index any other wiki.

This suggests that any conforming wiki must include search/indexing capabilities. (Strictly speaking, this is not necessary, given the existence of Google, etc.; but a mere Google search does not capture metadata such as categorization of pages into "groups" or "categories"; content "tags"; page author & history information; etc., all of which is crucial to good, useful indexing.)

Any user of any wiki may private-message a user of any other wiki.

Usually, "user" means "editor", but could also mean "registered user", depending on the wiki. (Each wiki is responsible for determining what a "user of the wiki" represents/means.)

Of course, this implies that the protocol must include a requirement that a conforming wiki have a private-messaging feature (and also must require the interoperability, if perhaps not identicalness, of PM features across wikis). ("Across wikis", in this and other cases, may mean "across wikis in a community", or it could mean "across all wikis that conform to the protocol".) It is up to each individual wiki to decide whether its users may receive PMs from, or send PMs to, users of other wikis in the community (or which others). A well-run wiki, built on a well-designed wiki software platform, should also give individual users the ability to make these decisions for themselves; the protocol does not require this, however.)

Any user of any wiki may participate in any conforming forum.

A forum might be:

part of a wiki;
separate from, but associated with, a wiki; or,
entirely standalone.

In any case, a forum needs to conform to (the relevant aspects of) the protocol.

On any such forum, a user is identified as "<User> of <Wiki>". (Ensuring/confirming/enforcing the identity of users is up to each individual wiki!)

User access control may be defined with respect to / on the basis of other wikis in the community.

This somewhat broad category of functionality includes things such as:

Granting user privileges to existing users of another wiki
- "anyone who's got editor privileges on wiki X can also edit pages here", or
- "user X of wiki Y can edit pages here"
Delegating user definition decisions to another wiki ("user X of wiki Y is now considered a user here as well", i.e. importing a user record, without requiring registration or otherwise the creation of an identity anew for a given wiki)
- (This is different from the above, because in this case the user's status on wiki Y—the wiki they're imported from—is henceforth irrelevant; they're "adopted", so to speak)
On forums: "users from wiki X can start topics here; users from wikis Y and Z can post but not start topics; user A from wiki W has moderator privileges here"
Linking together of a user's contributions to multiple wikis (i.e. an edit by user X of wiki Y, made on wiki W, links to their profile on wiki Y, which then catalogs their contributions to all wikis where they contribute as "user X of wiki Y")
- (This does not precluded having multiple different identities; one can be "user X of wiki Y", and also "user Z of wiki W"; indeed one can even be "user X of wiki Y" and also "user Z of wiki Y"; i.e. there's no reason that protocol conformance should undermine isolation (if such is desired) of a person's social/topical spheres even within a single wiki community)

Wiki communities

How is a wiki community defined?

There are several possibilities (which are not exclusive; one wiki community may be defined in one way, another in another, etc.), listed below.

Note that how "heavyweight" the definition of a wiki community needs to be depends partly on the technical requirements of the protocol, so the ideas below are even more provisional than the rest of this document.

Trackers (definition by association with a locally centralized authority)

A "wiki tracker" could provide a list of wikis in a community. A wiki may then associate itself with the tracker (which may require approval from the tracker's operator, or may not, depending on the tracker), and thereby belong to the wiki community defined by that tracker.

This is "locally centralized" authority because while each tracker is a centralized authority with respect to the wiki community it defines, there is no overarching, "globally centralized" authority which regulates trackers in any way.

A tracker may be itself a wiki (i.e. any given wiki software may incorporate protocol-conforming tracker functionality), or a separate, standalone service.

Definition by mutual consent

A protocol-conforming wiki may elect to federate with any other protocol-conforming wiki. These two wikis are then members of the same wiki community.

In this case we are agnostic on the question of exactly what constitutes the wiki community in question. We simply say that any two wikis which are federated with each other are considered to belong to the same community. (Or, in graph-theoretic terms, any complete subgraph of the graph of all protocol-conforming wikis is ipso facto a community.)

Note that "definition by mutual consent" does not necessarily imply "definition by case-by-case explicit mutual consent". On many social networks, for example, becoming someone's "follower" does not require that person to make any decisions about your relationship, but you are now known to them—i.e. you appear on their list of followers. Wikis could work similarly: suppose that any wiki may, at its option, federate with some hypothetical CoolWiki, but this is a two-way relationship, which requires the federating wiki to make itself known to CoolWiki, and to provide all the functionality and access that CoolWiki defines to be required of any member of its wiki community.

One-sided definition (by "subscription")

Many of the features of the protocol are unidirectional. If I want to transclude content from Wikipedia into my private wiki, there not necessarily any reason[1] that Wikipedia even needs to know about my existence (except insofar as my wiki shows up in their webserver access logs). Likewise, even if Wikipedia conforms to the protocol, it's conceivable that I might allow any registered WP editor to post on my wiki's forums—still without Wikipedia knowing about my wiki's existence (and without me allowing Wikipedia any kind of special privileges/access/services with respect to my wiki).

Thus wiki "communities" might be defined unidirectionally, by "subscription". All that this requires is that the target wiki conform to the protocol, and allow "public access" (to all protocol-specified capabilities, or only some). The definitions of some of the protocol features have to be relaxed, in this case; e.g. if Wikipedia and MyWiki both conform to the protocol, and I'm "subscribed" to Wikipedia but Wikipedia doesn't even know of MyWiki's existence, then there's no reason to expect that users of MyWiki have any special privileges on Wikipedia, can message Wikipedia users, have access to Wikipedia content metadata, etc. (The reverse may or may not be true.)

[1] Well, there might be a reason: suppose some content on Wikipedia, which I have transcluded, changes or is removed. What happens to the page on my wiki into which that content was transcluded? If my wiki has no special relationship with Wikipedia, then this might be unfortunate for me; but if Wikipedia and my wiki both conform to the protocol, and belong to the same community, then perhaps I might receive a notification about this; or there might be some special notice or message passed along with the content (instead of just a 404 error or similar); this might permit some sort of caching scheme; etc.).

Prior work

There's a lot, dating back to the very earliest days of wikis.

Discussion & proposals

InterWiki (archived) and InterWikiDiscussion (archived) on WikiWikiWeb
Proposed InterWiki Content Standard (archived) on MeatballWiki: Includes an apparently-defunct link to an implementation of the ICS (archived) for Giki Wiki (an extremely obscure wiki platform)
WikiRobotsTxt (archived) on WikiWikiWeb: The barest sketch of a proposal for a wiki linking mechanism
Unified Recent Changes (archived) on WikiFeatures (via archive.org): A proposed (and, apparently, infrequently implemented) feature: the ability to unify "Recent Changes" feeds across wikis
InterSite Features (archived) on WikiFeatures (via archive.org): A list of proposed "inter-site" (a.k.a. "inter-wiki" a.k.a. "wiki federation") features
WikiFeatures (archived) on WikiWikiWeb; WikiFeatures (archived) (new site); WikiFeatures (archived) (old site, via archive.org)
NearLink (archived) on WikiFeatures: “Smart” or “variable” wikilinks
WikiFragmentation (archived) on WikiFutures (via archive.org): The fragmentation of wikis, and what to do about it
TwinWikis (archived) on WikiWikiWeb: A short commentary related to "Sister Sites"
SubscribedChanges (archived) on MeatballWiki: Federation of wikis with blogs (among other topics)
FilteredRecentChanges (archived) on MeatballWiki: Recent change feed within and across wikis (for federation, and other purposes)

Implementation examples

Eddie's Wiki (archived): An old and obscure wiki platform that implements some InterWiki features; see Eddie's Wiki Discussion (archived)
WikiCreole (archived) on WikiWikiWeb: A common markup syntax for wiki content; see also the Wikipedia page (archived)
SisterSites (archived) on WikiWikiWeb: A page that keeps track of certain other wikis (many now defunct)
Sisterly (archived) recipe (add-on) on PmWiki: Linking to, and transcluding, other wikis in a WikiFarm (i.e. multiple wikis hosted on the save server and using the same installation of the pmwiki software)