[Freedombox-discuss] Abstracted configuration (was: Re: Friendika)

Henri Asseily henri at asseily.com
Wed Jul 13 16:51:54 UTC 2011


On Jul 13, 2011, at 6:05 PM, Aitor Pazos wrote:

> I'm not an expert, but I'm worried about how many federated social 
> alternatives are being developed, in many cases without tackling the 
> underlying problems. We have protocols for our needs, we just have to 
> integrate them, because each one is good for different needs. We have http for 
> asynchronous communications with ostatus (microbloging/status), webdav (file 
> sharing), groupdav (events and tasks) and html for posts, We have xmpp for 
> synchronous communications (including audio and video) and collaboration. E-
> mail should be supported for a complete user experience. The servers are 
> already implemented and they are already federated services. It's a matter of 
> introducing some abstraction on top of them (akonadi already integrates almost 
> all this kind of services) and integrating user management, permissions, etc., 
> and build the web interface on top of that abstraction. But I could still use 
> all my normal clients (Kopete, Choqok, Dolphin, Kontact) which is something 
> very important for my. If we change the underlying protocols, what will happen 
> with all this software? Will developers bother to adapt their applications to 
> the "new definitive" protocol before fixing the working protocols? Are we 
> willing to render all this great applications useless? 
> 
>>> WebID
>>> is an SSL infrastructure - which solves privacy issues at a cost of
>>> everybody being accountable to an SSL signing authority. There are other
>>> lesser technical issues, but this is the elephant in the room.
>>> 
> 
> WebID uses SSL, but as far as I understand it doesn't rely in any CA. The 
> certificates can be self-signed and they will work the same. It uses the 
> private key installed in your PC (which might not be very convenient) and 
> checks if it belongs to the public key (which you have copied sometime before) 
> returned by the FOAF file. If they match, your friends server can be sure that 
> you are who you claim to be
> ( http://www.w3.org/wiki/Foaf%2Bssl ). In this scheme it doesn't matter which 
> the CA is.

Speaking of abstraction, to me the critical piece is that configuration of the box (which includes user-based configuration) should be decentralizable and out-of-box. I've been working with cellphone companies on such configuration aspects based on DNS routing, where the device can self-configure itself when given a single domain (in this case xxxxx.tel). Often the issue with configuration is finding the config API's access point(s). DNS here can help a lot, and with such an abstraction layer it becomes trivial to change or update the config mechanisms, as well as propose multiple protocols for such config.

For example, say I want to configure a box and upon install I'm asked for a single domain. I enter "henri.tel" (any domain will do, but .tel domains have a much easier time dealing with NAPTR records).
The installer can then automatically grab my public personal info (name, org, etc...). It can also do a lookup on say installer.fbox.org._apps.henri.tel to grab whatever NAPTR records are there for installer config, for example. And whatever other app that needs config info or a permanent access point could store its stuff in app.fbox.org._apps.henri.tel
However one sets that up, the idea of having an abstracted single access point solves many problems, chiefly storing config and or runtime data in the cloud without being subordinated to a 3rd party (i.e. having 0 switching costs), or subordinated to any one protocol.
--
Henri Asseily
henri.tel




More information about the Freedombox-discuss mailing list