Federated Wiki

Most of the conversation on this page dates back to when wiki was young. As wiki sites proliferated a shorthand for remote references emerged in the form of an InterWikiMap. I consider this a missed opportunity. GitHub has shown us that forking, duplication and even proliferation need not be feared. This leads me to believe time is right for a new start and have done so with a project awkwardly named the SmallestFederatedWiki. -- WardCunningham

Plenty of people around the world are using WikiClones for various private or public things. It would be nice to cleanly allow links between them: the best way at present is to type out the whole URL, which is a little ugly:

http://chrome.mincom.com/cgi-bin/piki.py?PikiToDo

I'm thinking about adding to PikiPiki a feature which allows a word like this:

c2::WikiClones

to link to the Wiki configured as "c2". -- MartinPool

I already did that. I've made a version of PikiPiki with support for extensible federation (SEWF). The difference is that instead of

c2::WikiClones

You do

wikiwikiweb::WikiClones

It also uses a DNS-esque server to qualify URLs, so the database is public and not built in to the server. The server is very simple. It is written in Python and binds itself to port 22. It uses a GNU DBM database for storing hashes. Send it !(quit)! and it quits, send it !(add)! to add an entry, send it an entry (like c2) to qualify it. If anyone's interested in it I can post it on my web server...

Why port 22? Two reasons. First, on a phone, WIKI is 9454. 9+4+5+4=22. Second, on a phone, C2 is 22. So it all makes sense that way.

However, WikiDNS servers can't yet communicate with each other (i.e. mirroring), and the WikiDNS server used has to be specified in the Wiki CGI script itself. It needs to centralize at some point, though... Is there a way we can use the FreeNet implementation? That would make it much simpler and eliminate the need for federation as they would all be on the same wiki base engine... how about wiki::WelcomeVisitors to access this archive? That would mean that a standard Wiki engine would need to be created, and clones would not work properly unless they were perfectly compatible, because a page designed for PikiPiki might move to a ZWiki or OriginalWiki server and would no longer work. If we eliminated HTTP and HTML, and made custom user agents that parsed the Wiki, then it would work perfectly. I'll work on that.

UPDATE: Sadly, this no longer works due to server problem. I was thinking about reimplementing it with an XML database, but then realized that if the number of Wiki's became too large, the database would become huge and impossible to download. Imagine if you downloaded the entire InterNIC database when you went to any site! So, I am instead in the process of creating a version of Phiki (my PikiPiki clone) that allows linking to other Wikis by IP address instead of by name. I'll also try porting Lynx to Wiki syntax instead of HTML, with a couple function modifications (title shows up at top left, all the time; pressing 'e' edits page, 'f' does full text search, etc.) Wikis won't have names, so it will seem to the user as if they are all connected; Wiki files will be parsed by the user agent like HTML is; and it will use a custom protocol that I'll devise tonight. :-) I know no one cares, but I want it written down and this seemed like the best place to do it.

I think it's a good idea, Martin. What are your thoughts on configuration (i.e. c2:: == http://c2.com/cgi/wiki?) ? Would that be configurable only by the wiki admin or by the public? By what mechanism? --TimVoght

One way might be to use wiki macros like we do at our lively VisualFoxPro wiki. See http://fox.wikis.com/wc.dll?wiki~WikiMacros -- StevenBlack

I too think it's a good idea. Here's another possible format:

  wikiname/wikipagename  (eg. wikiwikiweb/FederatedWiki)

where each wiki has a unique name. Name to url mappings could be pulled from a wiki page in a standard format - XML, or just:

wikiwikiwebhttp://c2.com/cgi/wiki wikibasehttp://c2.com/cgi/wikibase ...

This page could be local or remote. A standalone wiki server might read this automatically on startup; or the wiki admin might fetch it now and then with wget.

--SimonMichael

ThoughtsWeaverAdditions --

Cross-Instances References: We have several ThoughtsWeaver instances running. One can cross-reference between these instances (or between ThoughtsWeaver and WikiWiki) using a time-honored notation: this page might be WikiWiki!ThoughtsWeaverAdditions, while I could as well refer to OrgPatterns!RecentChanges as distinct from WikiWiki!RecentChanges or NatureOfOrder!RecentChanges.

This trick never works. The trouble is that satellite wikis have smaller content and audience than wikiwiki. So people who start there end up here and usually add their content here because ... well, because this place has more content and a larger audience. I suspect to do this viably we've got to have some kind of automatic two-way link. Or maybe do it by transclusion ... --PeterMerel

I imagine it as GravitationalFieldsInWiki?: people are drawn to pages in RecentChanges, so things that are active tend to stay active. If WikiClones had lots of links to OriginalWiki then people might go there rather than staying on the clone.

In my particular case the ProjectPiki? is meant to contain discussions about our project, and so they're confidential or not interesting to outsiders. I suppose if we easily linked to and from OriginalWiki then people might accidentally put confidential stuff on c2. -- MartinPool

A FederatedRecentChanges? that aggregated RecentChanges for various public Wiki's might be cool. -- CurtisBartley

MeatballWiki uses the more streamlined syntax: wiki:FederatedWiki to refer to this page. I can hear Occam sqeaking : "why two colons, if one suffices". -- FridemarPache

More recently, MeatballWiki/UseModWiki has published its intermap file for the general consumption of the universe. See http://usemod.com/cgi-bin/mb.pl?InterWiki.

This site preferes to use no syntax what so ever so that AccidentalLinking happens with SisterSites.

CategoryWiki