I’ve investigated FedWikis a bit further and want to keep some notes. It is a system incorporating really cool ideas. I do have some problems with the current implementation though.

Originally I was just interested in getting the FedWikis to run on I2P. But the more I’m getting into it, the more I realise I had some wrong ideas about it, too. Finding good informations took me a while, though. Maybe it’s time to become clear about what I actually want ;) Let’s try:

  • OpenSource
  • distributed, i.e. non-centralised archictecture

Now FedWiki offers those, I think. The problems I encountered are related to other requirements I had made implicitely:

  • Ad-hoc contributions via browser (easy to use)
  • Secure implementation

And these I do not see in FedWikis currently. But let’s go through these requirements and check …

OpenSource

FedWikis are open-source, which is a good basis. It’s licensed as MIT or GPLv2, which seems fine, too. The code is rather hard to read for me, as it uses frameworks (node-framework, coffee-script) which I’m not familiar with. And I had a hard time finding information on how it is supposed to work. I’ll try to write these down and maybe I can help to improve that situation on the way. Documentation often is a problem in OpenSource projects, but should addressable rather easily. I’ll come to why I haven’t done so, yet.

Distributed (and Federated)

So what’s distributed supposed to mean? I wrote “i.e. non-centralised” above, but that’s still not really clear. I think of independence of specific instances running by assistance for cloning whole instances. The difference between distributed and federated as I currently understand it, is that federated systems talk to each other, while distributed systems just points out there are not bound to one instance. Now FedWikis are not doing distribution of content as an application or automatically. The federation is done in each client and pending on the content visited by that client. Note it is not user, as the same user using a different client will start from scratch building up the federation as the users browses through pages.

If the operator/destination/machine of a node vanishes the information can be kept and brought online again with ease though. On any (?) FedWiki you can just request the URL /system/export.json and will get a json encoded file with all the content of the wiki. As pages include their history, this is not just the current state, but also the meta-data. No need for the operator to take care about how to provide exports. And even better: If using the OpenID logins, then the pages claimed by such OpenIDs will have their “rights” transferred as well. The user doing a certain page on a wiki could continue doing that page on another wiki at any time, the ID would be the same on all wikis. That is a clever concept.

Ad-hoc Contributions

When thinking wiki I mostly think my specific usage profile. For wikis that has mostly been doing small edits on the fly while at it. Usually I will have found information using a search engine and having something to contribute. From very small things like correcting punctuation up to bigger things like adding new pages. The latter for me only occurred on wikis I have been visiting more often and was familiar with. Only very rarely have I had an account on wikis. I’ve never thought of reputation and alike. But if I see something being missing or wrong, I don’t hesitate to try and correct it. That means most of my contributions have been anonymous.

FedWikis do allow editing content, by just double-clicking it. What you need to know is, that you are not changing anything on the server. Instead the client will clone the page to your local cache and perform any operations there. If I’m correct, this is indicated by a yellow border around the page. Like a shiny highlight or something. Now that’s a good idea actually, as you get a copy of the content in the process and the server owner is still in control what’s on his server. But it also means, your contribution is not on the server without further action.

That action consists of finding a page displaying your local contributions and offering the send change request functionality. However, although I did activate js, that page did not work for me. It just didn’t show those pages I changed. And as my browser deletes the history and cached content, my edits were gone the next day. This might be due to cookies. I found out that client actually doesn’t display content correctly if cookies are forbidden. As I allow all such stuff only per domain, I probably forgot to allos the cookie from that wiki I was editing. Well … Created an issue to point out the cookie thing. And will need to check that again then.

Secure Implementation

Well, it might be just me here, but I tend to require sites to be at least readable without enabled Javascript. Most website developers do not even seem to check this and many pages are rendered unreadable while Javascript is not allowed. Now FedWikis basically implement a new browser instance as Javascript client within a browser window. The whole federation takes place in that client, only. That makes Javascript a must for the system as whole to work. It is an interesting concept, although it seems to me that an actual client application, i.e. a browser addon or really an application for itself would be better suited. That would allow one to check the code once and decide if one wants to run it. At the moment the client version depends on with which FedWiki site you start your browsing. And not only that, the client seems to dynamically load plugins from sites you visit. Even if considering using Javascript from selected sites, this might not be a good architecture in the scope of security.

Further Thoughts

Could it be different? Well, with a client-app based approach it would. The flexibility which dynamically loading extensions provides is a feature also though. While a client-app could technically still do that, I wonder if that is something it should do in terms of security. But I would assume most sites would be running a default set of plugins anyways, though, and those would all work fine with a default client. But the client-app would kind of separate the wikis from the web, and that probably is as a problem. So can the content be accessible from a browser without running Javascript that much? Well, currently the client requests a page from the server, retrieves it as json and then renders it.

Now it seems sound to assume every server has the knowledge on how to render any of his pages. He also delivers the client that is able to do so. So technically it should be possible to have the server output html instead of json. It actually does but omits many plugins, like the html one that seems to be used for headings regularly. Thus even simple content that actually wouldn’t need any Javascript to display is not readable without. Providing the same functionality as all the plugins would require the server to either be able to use the client-code directly or each plugin to provide a “render on server” version also. The latter seems like lots of work and for the former I cannot say if it is possible.

How about interactivity? Well, having the server display a “edit this paragraph” (content is structured in paragraphs in FedWikis) aside each paragraph wouldn’t be a big thing then. Displaying a html input field with a send button and attributing the change to anonymous if the user is not logged in should actually not be difficult. And moving some functionality to the server might even be beneficial. If I think of wiki pages with many changes (say Wikipedias most edited article?) which as a FedWiki might/probably would have many forks as well, then doing federation in the client might be … actually kind of bad. Let’s say a page has 100 forks around the world. Now currently every FedWiki client would parse the pages history and connect to all servers mentioned therein. I assume it needs to do so to be able to display what forks might have a newer version for example. This information is not on the server as those do no connections. Now this would mean then that a million clients doing the hundret connections each and resulting in 100 million connections. If only the servers would do those connections, then we’d still only have 100 x 100 connections: 10.000. Noteably, if there are no clients, we would also still have those. Probably a design-based tradeoff.

Now I may have wrong assumptions in here and haven’t thought about federation that much. There surely is reason why this is a problem on many ends. But basically federation is a subscription thing and there are some solid protocols to handle those. RSS and XMPP come to mind. If you now RSS from blogs only, just imagine version-changes as the content, and you will understand what I mean with protocol. XMPP you might know from chat-clients only, but those do federation: You allow people to see your online status, those subscribe to your status on the server handling your account and then the server will inform all subscribers on your status changes. A social network like Diaspora basically is the sum of the collections of subscriptions of its users. You subscribe to hash-tags or the the posts of other users.

As said, I’m new to the theoretical foundations of this. But my feeling still is that on a rather technical (protocol) level we have the solutions. We just lack proper software for certain usage-scenarios. Coming back to my original idea of using FedWikis in I2P I don’t think requiring Javascript is acceptable. I’m not sure about the efforts needed to change this. Starting to do that all alone might be too much of a task for me if I don’t get funding for that from somewhere to really get into it for some months. So I’m unsure how to procede.

ClearNet Links:

  • https://github.com/fedwiki/wiki/issues/12
  • http://fed.wiki.org
  • http://plugins.fed.wiki.org
  • http://admin.asia.wiki.org
    • http://admin.asia.wiki.org/backup.html
    • http://admin.asia.wiki.org/claims.html
  • http://dev.asia.wiki.org
    • http://dev.asia.wiki.org/where-pages-live.html
    • http://dev.asia.wiki.org/hacking-federated-wiki.html