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

[bertagaz]

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.

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".

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.

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.

> (and no, I won't participate in a supthread on how spam filtering  
> somehow magically can be done both easily, reliable and effectively)
>
>
>> Actually the monkeysphere project is also developping an outgoing SMTP  
>> proxy which would be used by other SMTP to plug with monkeysphere, so  
>> that x509 certificates can be verified by SMTP servers using  
>> monkeysphere. Shouldn't be too hard to add the ability to encrypt  
>> outgoing emails on the fly.
>
> Interesting!
>
> Which reminds me: Outgoing smtp might be relevant even if avoiding  
> incoming smtp.  exactly for the purpose of auto-encrypting to peers.

totally, that would be an interesting feature in a lot of cases.

> I would want my FreedomBox to maintain email encryption preferences for  
> for each of my friends. I.e. GPG/SSL/none? if GPG then inline or MIME?

That'd be nice.

>
>> 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.

>
>>> 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

>> 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 :)

Bert.