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

[bertagaz]

On Fri, Oct 08, 2010 at 06:44:42PM +0200, Jonas Smedegaard wrote:
> On Fri, Oct 08, 2010 at 05:09:15PM +0200, bertagaz wrote:
>> 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).
>

Low device is important for sure, I was just saying that heavy users will
have to consider switching to more powerfull hardware, as I'm not sure a
shivaplug will be able to handle all services the FB will support. I don't
know if a shivaplug can handle an asterisk server aside with a tor router,
a vpn server, a webserver, a mail server, a xmpp server, and so on...

I guess everyone would agree if I say we want it modular, that is users
being able to choose what service they want to host, but if they are
hosting a lot, some of them being resource angry, fo them and other
people, they might consider using more powerfull hardware I guess. That
was my questions/concerns.

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

Yeah, sorry was close to the troll :) My point was to minor a bit the CPU
debate, as said previously, users will certainly reach the shivaplug
limits if they use it a lot. Maube we should find a way to output to users
how resource angry each service is, so that he/she has an idea of what is
installable on his/her FB.
>
> 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.

That's a nice plan, but ambitious. Would ask a lot more work but would be
great to see it becoming reality. In the meantime, I guess we can use
basic already existing service setup :)

>
>> 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 if everyone is doing spam filtering for his/her mail, it's a way to
decentralize the spam managment, rather than having one big antispam
install on a remote mail server everyone use. Well, decentralized is not
the word, but you get it I guess :)

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

What is the problem wit mini-itx for non-geek?

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

Gnupg encryption would take place on the sender side, that's the idea, so
that emails are already encrypted when coming on the backup MX, they won"t
be written plain on it's disk.

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

Well, to begin to work I guess we would need to agree on the configuration
debate (hack vs debconf) for example. Having a clean decision about that
would help to begin to explore how to implement. But maybe I'm too pushy
on this, and this project needs more discussions.

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


Would love to, but have to find spare time, like evryone around I guess :)

bert.