[Freedombox-discuss] towards a business plan

Paul Gardner-Stephen paul at servalproject.org
Mon Mar 7 12:34:50 UTC 2011


Hello,

On Mon, Mar 7, 2011 at 2:57 PM, Yannick <sevmek at free.fr> wrote:
> Le lundi 07 mars 2011 à 09:47 +1030, Paul Gardner-Stephen a écrit :
>> Hello Yannick,
>>
>> On Sun, Mar 6, 2011 at 11:49 PM, Yannick <sevmek at free.fr> wrote:
>> > Le dimanche 06 mars 2011 à 12:46 +0100, Jonas Smedegaard a écrit :
>> >> On Sat, Mar 05, 2011 at 07:15:18PM -0800, Thomas Lord wrote:
>> >> >Step 1:
>> >> >
>> >> >Let's pick 5 apps.   I suggest email mailbox hosting, chat,
>> >> >instant messaging, blogging and FB-ish "walls".
>> >>
>> >> What is the difference between "chat" and "instant messaging"?
>> >>
>> >> If first one is realtime voice chat, I suggest calling it telephony to
>> >> avoid misunderstanding.
>> >>
>> >> And I suggest to aim even lower that for first iterations.  Not because
>> >> any of them are weak as selling points, but because not all of them
>> >> really exist yet (or are prepackaged in Debian, if that matters yo you).
>> >
>> > Nowadays, there is no more such difference between Instant Messaging,
>> > Voice/video Chat and Telephony. It all converges.
>>
>> Actually, there is a big difference from a technical perspective.
>> IM can handle latency, jitter and other network issues much better
>> than voice can, unless you are happy with >1sec voice latency to
>> buffer your way through these problems.
>
> As far as I know, there is no real Quality of Service on the internet
> yet, which can be regarded as good as it gives the network a property of
> neutrality. Situation is of course different in a local network with an
> administrator, witch is not the case with the freedombox.
>
> Thus it doesn't matter what you try to put in the network, text message
> or voice communication, the latency will be the same. Of course,
> implementors use some "tricks" like using UDP...

I agree that the latency will be the same.  What is different is how
acceptable the user's perspective will be.
1sec latency on IM is okay, but is pretty annoying for a voice call.

>>
>> > One issue is there is 2 free (as in speech) protocols: XMPP and SIP.
>> >
>> > Personnaly, I would prefer SIP because it has a focus on telephony
>> > features, stong backup by hardware vendors for real telephony and allow
>> > to call "real" phones too. The downside is the complexity of the
>> > specification and interoperability issues.
>>
>> Yes, SIP is very good in many ways, but at ServalProject.org at least,
>> we are looking to create a simple alternative protocol (open of
>> course) which will tolerate latency and excessive packet loss much
>> better than SIP does, and will be substantially more bandwidth
>> efficient when calls are not in progress.  We will still support SIP,
>> and have a SIP to our own protocol gateway, but we will use our own
>> protocol where both ends support it to improve performance.
>>
>> It should also be noted that SIP is very chatty when no call is in
>> progress, which can easily swamp a mesh network.
>>
>
> Seems nice... Where is your code source? What is the licence? Will you
> propose a standardisation as an RFC to the IETF?

We have yet to write much of the source for this part, it is just the
planning that we have done at this stage.
However, all going well we hope to have an implementation by mid-year.
 It will be GPLv2 or GPLv3 or similar.
We have not had time to think about putting it out as an RFC etc, but
are certainly willing to consider it.
Let us get the code together first :)

>> > Make no mistake, SIP do support Instant Messaging too:
>> > http://en.wikipedia.org/wiki/SIMPLE
>> >
>> > Another issue is to get a real world wide adress book. The best I know
>> > is ENUM, still with no real backup by governements yet, but there is a
>> > community around it ; see
>> > http://en.wikipedia.org/wiki/Telephone_number_mapping
>> > If the project is willing to replace DNS, I think it should include ENUM
>> > as part of it.
>>
>> The trouble with ENUM is that it needs government cooperation to work.
>> This is why ServalProject.org made Serval DNA (open of course), which
>> lets people claim their own number, and creates a distributed home
>> location register so that you can make calls using real numbers, even
>> if partitioned from the rest of the internet.  I am happy to provide
>> more information on this if people are interested.
>
> This is what some communities do with ENUM too yet, like e.g.:
> http://www.e164.org/
> which the ekiga softphone (I'm part of the team) does use cf.
> http://wiki.ekiga.org/index.php/Enum
>
> Thus we do have several technologies able to map phone numbers and IP.
> One issue here is how to securely attach my phone number to my IP, what
> does prevent a bad guy to attach my phone number to his IP, stealing it?
> This is why the governments should be in the loop.

Well, for our (ServalProject's) primary target being disaster
response, it is better to let people claim a number and then ask
questions later.  Waiting for government or telco's is a recipe for
disaster; it just takes too long.
At present, our protocol takes the form of informing you when you call
that the number has not been verified.
We have provision for a distributed certificate system to allow people
to certify one another's numbers, so that trust can be layered nicely
on top of this.  I would like to get the post office or a similar
organisation to be a certification agency, where you pay them a few
dollars to sign your key.  This makes it separate from government and
telcos, and thus more resilient.  But of course we are happy to
support many certification agencies.

> I'm aware of a workaround for french people, as the french government
> actually use a certificate for online payment, thus I'm able to prove
> using cryptographic techniques I'm really who I am with a backup by my
> government. But it was not meant that way and is far from being user
> friendly at this point.

I didn't know about that, it is kind of cool.

>>
>> > Last but not least issue is the "NAT" issue. But this one is something
>> > that would include most of the services provided by the freedombox: each
>> > freedombox will need a public adress to allow real peer to peer
>> > connection. I would recommend using IPv6 from the start and drop any
>> > form of NAT. This would ease a structure where any freedombox could be a
>> > real server and client.
>>
>> This is fine for devices with support for IPv6, which clearly the
>> freedombox will be.
>> However, if you want compatibility with as many devices as possible,
>> then you at least need a plan for NAT/IPv4.
>> ServalProject.org's approach here is using nodes as gateways and ECC
>> public keys as actual identities.  We can route this as an overlay
>> over IPv4 if necessary, and you could use a fairly sensible ECC to
>> IPv6 mapping.
>
> If I get this right, some nodes with public IP will relay the voice
> stream. Which is the classical approach if you cannot get peer to peer
> connection because of NAT. e.g. see
> http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT

More or less.  It might be private-IP nodes relaying within a NAT,
with hopefully a node at the edge of the NAT also relaying.
I'll explain this a bit more below.

> My question here is who will provide this service? Will it be based on
> your own nodes with your own bandwidth, or is it based on some DHT
> architecture ( http://en.wikipedia.org/wiki/Distributed_hash_table ) in
> witch everybody can be eligible to be a relay ?

All nodes on a Serval compatible network will offer this service
implicitly as part of being on the mesh.
Thus if your node offers a data service, e.g., via cellular, DSL or
satellite, it is simultaneously the gateway and private-IP space
provider.  Note that there is not actually any NAT, because in this
model Serval uses a UDP broadcast overlay for the mesh, so if you had
to, everyone could have the same IP address and it would still work,
and everyone could still communicate.

It's 11pm here and I am rather tired, so please forgive me if  this is
a confusing explanation :)
I speak about this and answer some relevant questions on this topic in
http://blip.tv/file/4697375/

> Beside, for privacy reason, streams should be encrypted with stuff like
> ZRTP.

Absolutely.  Whether we use ZRTP or not, we will have Diffie-Hellman
key exchange or similar so that the voice data can be strongly
encrypted.

Paul.

>>
>> > On the topic of SIP, having a real peer to peer achitecture is the
>> > subject of this effort for a standard: http://www.p2psip.org/
>>
>> Again, I think this is good to support, but I think that it is
>> possible to implement some cleaner, simpler protocols to do these
>> tasks better, and my team and I are actively doing so, and are happy
>> to share that work, and take input from this community.
>>
>
> Sure, you're welcome!
>
> Regards,
> Yannick
>
>> Paul.
>
>
>
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
>



More information about the Freedombox-discuss mailing list