[Freedombox-discuss] Leaving the (proprietary) cloud - my roadmap for FB

Jonas Smedegaard dr at jones.dk
Fri Oct 8 16:44:42 UTC 2010


On Fri, Oct 08, 2010 at 05:09:15PM +0200, bertagaz wrote:
>On Fri, Oct 08, 2010 at 04:35:01PM +0200, Jonas Smedegaard wrote:
>> On Fri, Oct 08, 2010 at 03:25:52PM +0200, bertagaz wrote:
>>>> Good point.
>>>>
>>>> First I wondered why you then anyway mention "imap + webmail" on your
>>>> list, but then realized that I actually agree with you - and the key
>>>> here, I think, is *mirroring*.
>>>>
>>>> When I included imap but not smtp on my list, I forgot to mention
>>>> that I would then be using offlineimap to mirror emails from the
>>>> communities and organisations where I have an email account.  Just as
>>>> I do today on my laptop.
>>>
>>> Offlineimap or getmail would be a nice start for the big email thing.
>>>
>>> As it comes up again, I'd like to submit an idea we had with friends when
>>> talking about this issue.
>>>
>>> IIRC the last "distributed email" discussion on this list ended up on the
>>> problem of having a reliable smtp server on a box that might not be always
>>> online. As it was spotted, SMTP supports this case by having the ability
>>> to have secondaries MX, but then the problem was to store data on this
>>> (probably untrusty) MX.
>>>
>>> Now if the problem is to store our emails on other boxes hosting our
>>> secondaries MX, maybe a easy workaround might be to have the sender
>>> SMTP automatically encrypting outgoing mails with gnupg.
>>
>> Biggest issue I see in incoming smtp is the CPU burden of spam
>> filtering.  I would not want to trust peers in judging which emails are
>> relevant to me to receive, weighted against the CPU burden of decent
>> reliability of filtering mechanisms.
>
>The "CPU burden" depends on the email traffic at some point. If people 
>have a very lot of that traffic, they might consider using a more 
>powerfull hardware. I often ask myself how many services a shivaplug 
>can handle. If people use a lot of cloud services, I guess if they want 
>to use the FB, installing it on a more powerfull hardware is a good 
>idea anyway.

Sure, FreedomBox is just one out of many ways towards Cloud freedom.

And I totally agree that we should not restrict ourselves to only 
develop specifically for FreedomBox, but work via Debian so that other 
ways towards similar freedoms gets improved too.

...if you still recognize those as your opinions after my twisting 
around the words ;-)

Or put differently: I do not see the FreedomBox project as "decentralize 
services by moving them to any and all hardware as long as it is running 
locally". The "...on low-resource embedded hardware" is mandatory to me.

I see it as quite relevant to *develop* and *test* on simpler to use 
(for us geeks) hardware.  But a goal of this project is (in my opinion) 
to embed it in low-resource "shoe-box" iron.  That said, there is room 
for disagreement as long as no resource-heavy parts are deemed mandatory 
(else we would need to go separate ways).


>I'm not really comfortable with the "resource" argument, as it is the 
>one that has been used a lot to justify the use of centrally hosted 
>services on big machines "cause it will be faster".

I use the resource argument not to encourage use of central hosting, but 
to discourage such services.

Email by design puts the burden on the recipient, which makes it 
beneficial for spammers.

Other relay mechanisms, like XMPP, have different designs less 
beneficial for spammers, and thus less resource hungry.

We want to bridge central and decentral social networking.  In relation 
to relayed messaging we can...

  1) Receive central email messaging via imap mirroring
  2) Read and write messages via FreedomBox
  3) Send based on FreedomBox relationship knowledge and pririties...
     a) to XMPP-capable friends using XMPP
     b) to SIMPLE-capable friends using SIP/SIMPLE
     c) to SMPP-capable friends using GSM text messages
     d) to status.net-capable friends using status.net
     ...
     z) to others using smtp

First step in the above is 1) and 3z), coupled with an smtp-only message 
processor (read: a webmail app).  Then if/when we succeed in 
enhancing/replacing the message processor to support pluggable transport 
mechanisms, we can add more routes, and make the smtp route optional 
too, for purists wanting to insist on decentral routing for the 
messaging part of their FreedomBox.


>My own spamassassin instance is not taking that much of CPU resource, 
>and if everyone has it's spam filter, I guess the charge then is 
>divided/distributed.

If everyone is doing spam filtering for _your_ emails and do not receive 
any emails themselves, then yes, the load gets spread out.

But most likely all will receive mail, so will need spam filtering 
somewhere.



>Maybe you don't want email/smtp, for that reason, but I would want to 
>have this feature, so should we just ban the possibility, or try to 
>find ways to implement? I use emails far more than other social 
>services, I'm far more concerned about where they are stored.

I don't ban it.  Feel free to work on distributed incoming smtp!

I will most likely be _very_ interested in improvements in this area - 
for other projects of mine: Organizations of 20-100 users running 
semi-centrally on Mini-ITX size iron.  But I would only want my non-geek 
friends to use ARM-grade SheevaPlugs privately, not Atom-grade Mini-ITX 
machines.


>>> So every user email that would end up on a secondary MX would be 
>>> already encrypted with gnupg. We could do that even for outgoing 
>>> emails send to the primary MX, that would also be a way to have more 
>>> gnupg usage in emails. And that way, stored emails would always be 
>>> encrypted, then even easiest to backup in this (already) encrypted 
>>> form.
>>
>> GPG-encryption do not hide addresses, subject or other headers, which 
>> users who would want to encrypt their backups at peers likely would 
>> want secret as well.  Which means double CPU burden as it needs yet 
>> another layer of encryption.
>
>Well, as long as one of the CPU burden takes place on the sender SMTP, 
>it's not that a problem then. But you're right, it might not be an 
>effective solution for backups in that case.

But it won't be on the sender side - it will be on the relay MX, if I 
understand you correctly.  And we will all act as relay MX for each 
other, I believe (that is the key point of the decentralization: to take 
personal control of our services!) so the burden _will_ be on our own 
FreedomBoxes.


>>>> If using YaCy for search, then that includes some shareable 
>>>> bookmark tools, it seems.
>>>
>>> I know of scuttle, which sadly is php.
>>
>> ...which means I would try to avoid it, but not that we should not
>> consider it when there are no better options, IMO.
>>
>> Please file a RFP against WNPP for it.
>>
>> And generally, please check yourself in aptitude (or other means of
>> looking up packages in Debian unstable) and at
>> http://www.debian.org/devel/wnpp/requested and
>> http://www.debian.org/devel/wnpp/being_packaged (or other means of
>> looking up WNPP in the Debian BTS) if suggested projects are already
>> tracked or need an RFP (or ITP) created. :-)
>
>It's already packaged : http://packages.debian.org/search?keywords=scuttle
>:D

Silly me - I forgot to check there :-P


>>> I'll do some wiki too, I feel that it isn't synced with the 
>>> discussions over here, and this project is laking of an updated 
>>> wiki, to find ways to organize the work. Speaking of that, the 
>>> organisation of this project is really unclear, and it's probably a 
>>> bad thing to start it really.
>>
>> I lost you there.  You feel it is bad to start organizing now?
>
>No, I feel like this project isn't enough organized, laking of decision 
>making processes and all. But maybe I'm too enthusiastic, and want ot 
>see it done, and really soon :)

I see little need for decision making processes.  Most of the tasks, I 
believe, are not tied strongly to one another, so there should be plenty 
of room for disagreements.

We do need to continue discussing, sharing ideas and opinions - in order 
to reveal _where_ we disagree, and where we perhaps do not disagree 
after all, but just use different terms for same things: Would be silly 
if we we do duplicated work due to not realizing that even though we may 
politically disagree, the tools we need for our various visions are 
technically identical.

Great if you (and anyone else) pour some love on the wiki pages!


  - Jonas

-- 
  * 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
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20101008/d6affeca/attachment.pgp>


More information about the Freedombox-discuss mailing list