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:
wikiwikiweb http://c2.com/cgi/wiki
wikibase http://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