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

Fri Oct 8 14:35:01 UTC 2010

On Fri, Oct 08, 2010 at 03:25:52PM +0200, bertagaz wrote:
>Hi,
>
>On Fri, Oct 08, 2010 at 02:01:01PM +0200, Jonas Smedegaard wrote:
>> On Fri, Oct 08, 2010 at 12:54:34PM +0200, Arthur Lutz wrote:
>>> When I think of the FreedomBox and leaving the cloud, the first 
>>> thing I think about migrating is not my email. One of the reasons is 
>>> that I'm quite dependent on it and don't really want an adjustment 
>>> period right now for this tool. When I think about leaving the 
>>> cloud, I want to migrate the least "critical" services first, so I 
>>> can start trusting my FB (stability, security use etc.)
>>
>> 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.

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

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?

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

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

>>> * google search -> yacy
>>
>> Please file RFP bugreport against WNPP for it.
>>
>> Also, beware that YaCy is Java-based, so heavy on the limited resources
>> of an embedded device.
>>
>> Complex volunteer task: Write a C/C++/Erlang implementation of YaCy ;-)
>
>there is also the seeks project : http://www.seeks-project.info/site/ 
>"free and open P2P design and application for enabling social 
>websearch"

Nice. And written in C++. :-)

bug#589037: Being packaged!

>>> Hope this helps, if people think it's relevant, maybe we can start 
>>> documenting these equivalents (and the migration documentation?) on 
>>> the wiki.
>>
>> Please do!
>
>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?

  - 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/547705c9/attachment.pgp>