[Freedombox-discuss] FOAF developers taking FreedomBox into their equation
On Wed, Mar 09, 2011 at 09:09:25PM +0100, Henry Story wrote:
> I just added myself to this list yesterday.
I have long appreciated your blog!
> FreedomBox is a great idea and I like the acronym its going to make
> I am not sure yet if FB is hardware or software or both and one can
This depend on who you ask, I guess. Here's my view on it:
Eben Moglen coined the term "FreedomBox". He mostly (but not always)
talk about Free software on Plug devices.
This list was started by Debian developers as direct response to Eben's
inspiring talk at Debconf10 last summer. Eben have made several
talks also at other parts of the FLOSS world, and apparently this
list has become the main melting pot.
I am a Debian developer, so obviously biased: I Personally envision
FreedomBox as Debian-packaged and stabilized-as-a-distro software put
onto Plug computers.
I call the software part Freedom* - because to me the software part is
an integral part of Debian - the Universal Operating System, and thus
as packages generic i.e. not targeted only Plug devices.
Some people here on the list seem interested mainly in developing
protocols and software. In Debian-speak we call that "upstream" because
that is work located towards the source of the "stream" of FLOSS.
>I am working on http://clerezza.org/ an Apache project and would love
>to see if it can run on the same hardware... (sorry it's not GNU)
This is not GNU.
I'd recommend you try get your code packaged for Debian. Not that you
do it yourself (unless you want that particular learning experience) but
that you help encourage others to do it who is into the art of
packaging: Start by filing a so-called "Request For Packaging" (RFP)
bugreport - see http://www.debian.org/devel/wnpp/#l1 - and then add the
resulting bugreport number at an appropriate one of our wiki pages, e.g.
here: http://wiki.debian.org/FreedomBox/LeavingTheCloud .
Next I would recommend to got _elsewhere_ in Debian than this particular
list, to seek someone interested in packaging it. The reason is both
that we are relatively few Debian Developers here and our time is
probably better spent with other tasks than diving into the details of
too much packaging work that others can do too, and also, well, another
angle of same reasoning being that most of us here on the list have
different skills than in Debian packaging.
Then when packaged for Debian, your code makes sense to consider for
inclusion in FreedomBox. In my opinion. Others here may find different
Even if it turns out your particular code project is not included into
FreedomBox at the end, the preparation of it - getting it into Debian -
makes it usable for many other purposes than the rather narrow aim of
Perhaps really the "FredomBox possibly without a box" that you asked
about equals the "get it included into Debian" that I propose? :-)
> I am also currently chairing the WebID incubator group at the W3C, so
> if you have WebID questions don't hesitate to ping me, or join the
> W3C mailing list and ping there.
Thanks for the offer.
Just as you have a general interest in FreedomBox and a pet project, I
also have this "pet idea" of WebID being a central tool in FredomBox,
and RDF being used to maintain/compute human relationship data shared
among the FreedomBox tools that make use of such info (i.e. chat and
messaging apps but not e.g. mesh routing daemons).
A *lot* is still very open. Which means you might be wasting your time
here, but also means if you can help get concrete proof-of-concept
structures (both designs - e.g. ACL model - and code - e.g. SPARQL
lookup espressions) then there is a good chance of that setting the
course of the project ;-)
>On 9 Mar 2011, at 18:22, Jonas Smedegaard wrote:
>> The FOAF and RDF developers - including clever persons like sir Tim
>> Berners-Lee - seem to now take FreedomBox into the equation, judging
>> from this recent mail at their list:
>> for those ok with using a nifty - albeit centralized and thus
>> potentially evil - interface, here is same message via the interface
>> that the FOAF project itself favor over their own archival:
>Not sure I knew of the rivalry you are speaking of. I was happy to link
>there because it did a better job of html mail which some people like
>Peter Williams kept sending. But it does not do a good job on pictures.
>Few archives tools seem to get that right oddly enough.
FreedomBox at its core is about moving from centralized to decentralized
services. About avoiding too much knowledge piling up at places which
might too easily get in the hands of someone abusing the power of such
It is not about facebook.com, google.com or markmail.org being evil.
Instead, it is about their _designs_ tied to centralized operations
being attractive to evil-doers, no matter if already in the house or
kicking in the door later on.
>> I am not clever in crypto stuff so would appreciate if someone else
>> would consider helping them out by perhaps joining that list and
>> follow up on that thread.
>That was part of a longer thread on the WebID mailing list on SSL
>proxies, if you want to understand the conversation.
>my biased summary I think is: if your OS is not OpenSource, or you
>client is controlled by an operator, then of course it will be easy for
>them to place a certificate they control onto your client, and so be
>able to proxy your connections.
>But this will be true of any encryption protocol. If you allow this to
>happen then you will not be quite an individual but an element of that
>organisation. As an employee that can make sense, as a subscriber to a
>telephone service I'd be less happy.
>As for CAs they can of course also distribute root signing certificates
>to various entities. Now with a freedom box it should be possible to
>work out when that is happening, as you can control the server
>certificate and the client.
>something to explore.
Thanks for the summary.
I am very happy to have you participate here!
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature