Diaspora Part Four

Published on Friday, May 28th 2010. Edited by Rat Outzipape. tag

Existing Solutions
Protocols
Normalisation protocols
This situation has been very much in flux in that there is no one clear set. The two main protocol contenders for normalising multi-sourced data that I am considering here are SMOB Home and SMOB code and StatusNet write up and OStatus wiki. The reason for this is StatusNet may be favoured by the Diaspora team and SMOB is a semantic pathway.
Architecture
The best reference I have found for this is on the libreplanet web site called GNU social. There are three pages of interest.
1. A categorised list of existing architectures, goals and ideas with links and discussion. [5:]
2. A categorised list Group:GNU Social/Project Comparison of existing projects with links and discussion. [6:]
3. A design description of the GNU Social node by a Washington University 2010 graduate Ted Smith. [7:]
Architectural Objectives
Here are some questions.
What are the desirable trade offs between security and a light weight program foot print?
What is the extent to which locally held information should be encrypted?
In other words how far up should the security control be turned?
Some features that very strong security would make more difficult to deliver using p2p architecture and PGP (the most common solution in this space) are:-
i. A lightweight solution suitable for mobiles.
ii. A lightweight solution that is easy to install and use on a user local machine (non-mobile).
iii. A solution that can be deployed to existing always on devices such as DSL routers (because routers already embed their own HTTP servers) or something like a $20.00 USB device that would plug into the router.
libreplanet and Diaspora seem to favour p2p for maximum security, which seems to imply one of the engines discussed in those references.
Those engines offer many capabilities, however to use the straight forward mechanism of foaf+ssl some mapping between their existing security mechanism and this protocol would have to take place (p2p usually relies on PGP).
Further mappings between the protocol of the streams and a semantic representation would also be needed at some stage. It would be important not to be restricted by the communication protocol in such a way as to make this mapping task more complex.
There are two main p2p protocols available, Pyc (which project is incorporating a javascript http server) and XMPP.
The main reasons for looking at these solutions is that they offer secure communication in the p2p context and may also immediately offer the means to track distributed historical data. These reasons are not compelling, the same capability is available in servers using the HTTP protocol.
There are also powerful reasons not to use these p2p solutions that rely on either the Psyc or XMPP protocol.
1. They do not use HTTP and this may have consequences in terms of firewalls and proxies as well as in passing binary data files. XMPP may not support various protocols that are supported in HTTP, for instance the Client-authenticated TLS handshake (SSL) being discussed here.
2. The p2p engine for XMPP may not be as versatile in deployment options as an HTTP based solution, as in many deployments it would be an extra engine where as the engine for HTTP would already be in place (shared host, and possibly mobile device). In terms of code integration the HTTP engine is pretty close to being a bare tcp connection, with a few headers. It is easy to understand, versatile, and extremely widely used.
3. Profile changes that reflect access and privilege control propagate slowly over a network much bigger than 20 individuals unless, as with foaf+ssl, there is an instant alignment on each (automatic) login.
4. With _foaf+ssl_ there is concern about the use case of the transient
log in (at work, or in an internet cafe), but actually certificate creation is straightforward. This is a problem that is solved with foaf+ssl but becomes more of a problem where the node owner may not have their node (seed) with them.
5. Using other protocols for file sharing. If a torrent type solution is envisaged for the sharing of assets and those assets change, change propagation will be problematic and slow over several nodes.
FOAF+SSL Alternative Implementation
In my previous post I looked at the difference between SSL as it assures a security context and FOAF that can be used to determine access constraints for a series of related people or entities ("friends") within that context.
The SSL part is also known as Client-authenticated TLS handshake.
This solution is a no password solution that allows the identity of the authenticated client to be recognised by the server. As this identity refers to a FOAF profile this becomes a means to immediately establish access constraints not just for this authenticated individual, but also in relation to all those referred to in the FOAF (along with some other information also passed at the time of authentication). Research indicates that a very minimal install is possible where the main engine is the browser consuming HTML5 and javascript (AJAX). File reading and writing (with some restrictions) from javascript is possible on the local machine, cross-domain AJAX (using the script tag) can consume JSON(P).
It would also be able to authenticate point to point and encrypt and decrypt content locally. Typically the user would be able to drag and drop (as in HTML5) individuals or entities into different categories representing their access to assets in the clients control. Both authentication, multiple on line identities (for different situations) and access becomes very straight forward to manage.
Summary of Advantages of foaf+ssl for Identification and Authentication
1. HTTP will not encounter firewall problems.
2. Engines, importantly for the client, are ubiquitous and will not need to be installed.
3. It can deal with binary data without extra work.
4. Likely the server footprint is small and available for all sort of devices including mobile.
5. Can be deployed on shared hosts (if you don't allow full access because I'm on a shared host that is easy to introduce as a constraint.)
6. Different sorts of servers can be used for different purposes, for instance non-blocking polling, comet, reverse AJAX can all be made available, as needed. Not all server services have to be or should be deployed on every node.
7. Replication and redundancy can be introduced in this way without every node having to play a full part in either.
And in the foaf piece:-
1. Provides a ready solution to the problem of data aggregation and all sorts of additional mark up of that data, e.g. history, availability, authorship and so on.
2. Immediately associates access rights of individuals and groups with designated data types.
3. Allows immediate propagation of changes in those rights.
4. Can be stored in LOD (Linked Object Cloud) i.e. very versatile manner, not dependant on one data base or type of schema so long as it handles the rdf.
5. Opens out the rich vista of semantic mark-up and queries.
6. Can be expressed in RDFa on the client; AJAX transparent request are possible.
7. It relies on the existing architecture of the internet, would entail an hierarchy of servers where those relied on to do more of the work would also be relied on to always be on. Replication could be introduced at this level. (These might not be tasks given to mobile devices, for instance. But they could be tasks installed on DSL routers, that are always on anyway.) The architecture would remain distributed.



Resources
1: smob.me home
2: smob.me code
3: StatusNet write up
4: StatusNet OStatus wiki
5: GNU Social categorised list
6: Group:GNU Social/Project Comparison
7:Ted Smith's GNU Social node
8:FOAF+SSL Alternative Implementation
9:Client-authenticated TLS handshake
Adam Saltiel
May 2010

0 comments:

top