| 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 14 changed one line |
| An "identity haven" would be a neutral place where public keys could be stored safely. Federated web sites can be combined into a social network, where access to the site is determined by the level of trust the site operator assigns to the public/private key pairs. Similar to the way an individual manages they PGP key ring (with keys trusted based on various levels of knowledge of the individual... key signing parties, with keys to be used for access to the web site...) |
| An "identity haven" would be a neutral place where public keys could be stored safely. Federated web sites can be combined into a social network, where access to the site is determined by the level of trust the site operator assigns to the public/private key pairs. Similar to the way an individual manages their PGP key ring (with keys trusted based on various levels of knowledge of the individual... key signing parties, with keys to be used for access to the web site...) |
| At line 26 added 31 lines |
| !!Learning from E-mail |
| *[Pseudonymous Remailer|http://en.wikipedia.org/wiki/Nym_server] |
|
| !!Federating Wikis |
| It would be nice to be able to federate wikis. At the moment the closes feature is the 'sister wiki' feature that some wikis have. It makes it easy to link from one wiki to another with wiki links almost as simple as local wiki links. |
|
| In a Wiki federation, each wiki should be independent and allow the users to federate with other wikis. The goal of the federation would be to allow users and information to move freely between the wikis. Thus it should be easy to: |
| * contribute to multiple wikis |
| * move documents from a wiki to another and replace links with a placeholder/redirection |
|
| |
| !!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. |