| At line 2 added 10 lines |
| !!What We Need |
| |Privacy | Wiki federation members identify themselves using security tokens such as public encryption keys. All data is stored encrypted at each federated site |
| |Redaction | Wiki federation members can specify content as transient and remove it from the federation at will |
| |Embedded | Wiki federation members content appears embedded in each member site. Every federation member has complete control over which content appears in their site. |
| |Quarantine| Sites can be automatically removed from federation based on rules |
| |Instant Messaging | remember the BBS, posting content and chatting are the same thing. |
| |Peer to Peer | the web site is the client, I post to my website, the content appears on your web site |
| | Identity | Federation between people who are actually known to each other |
| |Publish and Subscribe | Your site subscribes to my site, when I add content to my site, your site receives it immediately (JMS over the HTTP!!) |
| |No Edit.jsp | in-line editing, not switching modes. |
| At line 37 added 20 lines |
| !!Peer-to-Peer Federation |
| Not only is it desirable to federate wikis from the standpoint of authors and readers, it is also desirable to exchange the actual content between federated wiki hosts. |
|
| Essentially, each member of the federation has the same content available. Given two wikis which are federated, an agent can modify data in either and the data will be stored in both wikis data store. |
|
| Thus, should a federated site be attacked or removed from the Internet, the content will survive as long as one site in the federation continues to exit. |
|
| Thus a wiki data store should function in a way like peer to peer file sharing systems do. |
|
| !!Example |
|
| I have a wiki (an editable web site). |
| I have 5 friends whom I know well who I wish to allow access to this wiki. |
| Each of these friends has an identity token of some kind in the identity haven. |
| I configure my wiki to allow owners of those tokens access to read and/or write pages in the wiki. |
| I send my friends a URL to my wiki. They do not have to register, they simply have to unlock their tokens to verify their identity. |
|
| In this case, an OpenID provider would be sufficient. As long as I personally collected and verified (e.g. in person) that the OpenIDs belong to the 5 people I know, that would be enough. However, if these 5 people are using a non-trustworthy OpenID provider (e.g. Google, Yahoo!, Facebook) then I will not feel that my wiki is fully protected. |
|
| Actually implementing this would only require a slight modification to an OpenID client to check the submitted ID against an access control list, before redirecting to the OpenID provider for verification. |