Re: [foaf-protocols] replacing email with atom and foaf+ssl

Story Henry wrote:
> In the early days of Atom, people were speaking of using it to replace e-mail.  
> This is in fact easy to do, we just need to try it out.
> 
> 1. The problem.
> ---------------
> 
> Before explaining the solution, it is important to understand the problem.
> Currently Atom works like a public mailing list: everyone can read everybody's
> published email/post/entry. The advantage over mailing lists, is that emails 
> automatically  have global identifiers, and that the content does not need to be 
> shoved around global networks, as spam has to be currently. People GET the entry
> when they want to.
> 
> What we want is to be able to narrow this down, so that one can publish (email) 
> to only a select number of people: to one's friends for example, or 
> just to one person. Ie we want to do the same with Atom as we do with email.
> 
> This requires two things:
>   - A way of notifying someone or a group of a new post for them
>   - A way of allowing software to access a atom entry in one simple click
> 
> 2. The Solution
> ---------------
> 
> 2.1 RESTful Identity and Authentication 
> ---------------------------------------
> 
> foaf+ssl gives us WebIds, global identifiers tied to a public key, which allows
> one click authentication. This works in all browsers. 
> There is more here: http://esw.w3.org/Foaf%2Bssl/FAQ
> You can try some early demos out by going to http://webid.myxwiki.org/ for example or
> any of the list of Identity Providers http://esw.w3.org/Foaf%2Bssl/IDP
> 
> Without foaf+ssl this is not really possible. Getting a username/password for 
> each of one's friends web servers would be impossibly complex, tedious and 
> insecure. OpenId is close, but still too complex, though it can also be made to work
> nicely with foaf+ssl.
> 
> 
> 2.2 A ping mechanism
> --------------------
> 
> It just requires one new relation to be added to a foaf file.  A link to a simple 
> form, which could be a atompub:Collection / sioc:Container [1]. I went into this in
> great detail in a recent post where I cover what I know of the pinging mechanism 
> history, and show how this can be simplified further.
> 
>    http://markmail.org/message/kzsg3qntovmqzbje
> 
> Writing such a pinging mechansim is really really easy. Adding a relation to a foaf is also
> easy, as we can see from the recent adoption by Facebook, which is rdfa enabling all
> its web pages.
> 
> 
> 2.3 Usage
> ---------
> 
>  When you want to publish an atom entry to someone, you would just need one of their 
> WebIds, and give access to only that WeBId for that entry. (A good GUI would speak of 
> this in a human way of course)
> 
>   How would you get that WebId? Well if you have a blog for them, you have their atom ID
> which can be used to find a webid. Or they could just give it to you at a party on a card.
> Or it could be linked to from one of your friends foaf file....
> 
>   When your reader access it, he just connects to your server with https, the server asks
> the client for the X509 certificate, which can be sent. On authentication the Entry is returned.
> That's all there is to it.
> 
> 3. Result
> ---------
> 
> As a result we would have a system that would be pure p2p, RESTful email equivalent. 
> If A sends B a message, only A and B (and routers along the way) need to know about 
> that communication. Nobody else. With email they are routed all over the place, for
> all kinds of people to observe.
> 
> Furthermore one would have built in SSL security in as a default. 
> 
> Finally it is really easy to add client cert support to any application, as this 
> is completely standard based.
> 
> Any thoughts?
> 

Henry,

Good call, I've been thinking about this a lot recently and there is
certainly a huge amount of scope.

Things I'm certain of:

- FOAF+SSL is needed
- HTTP should be the interface
- all communications should be handled RESTfully
- Resources should be Web Access Controlled (via ACL+WebID)
- The receive flow should be: notification of new message, GET message

Thing(s) I'm unsure of:

- Atom(/Pub) vs LinkedData

Linked Data can represent anything we want, surely to use linked data
rather than Atom would allow the scope of this to be so much more,
allowing any kind of "message" to be sent.

Sioc:Container and Items together with the additional sioc type
extensions would appear to cover 99% of scenarios.

Considerations of SPARUL, SPARQL and SPARQL+Pubsubhubbub for custom
notification streams.

However, Atom(/Pub) is already here, defined, widely accepted and would
allow a quick implementation without too much work, and you could ensure
that each message could be handled due to having set parameters in Atom
(whereas in linked data it could be any ontology with no guaranteed
presence of rdfs:label or suchlike)

Further, Atom(/Pub) would add in much scope for current work on the
likes of activitystrea.ms to be incorporated / made interoperable etc.
(and possibly OData/GData..?)

Side:
By defining a standardized HTTP RESTful messaging system with FOAF+SSL
and Web Access Control you remove all implementation specific details
and make something forwards and backwards compatible, so vendors could
easily adopt this whilst remaining in control of backwards compatibility
points (routing messages to email, xmpp, sms etc - preferences for
notifications of messages from certain sources - prioritization of
message deliver messages based on rules).

At the same time it would simplify many types of communication from
service to service and encourage adoption of webid's, foaf+ssl.

All in all:
Sounds feasible and pretty much fully spec'd if going down the atompub
route, perhaps linked data + sparql/sparul/pubsubhubbub is the long term
route but I'm quite sure it would take a bit more work to both implement
and encourage adoption. Brining the REST and Linked Data communities
together is critical though, and can only be a good thing for the future
of the web.

Thanks for bringing this to the table Henry,

Best,
Nathan

Received on Monday, 3 May 2010 20:23:13 UTC