[Freedombox-discuss] towards a business plan

[Yannick]

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

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

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

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.

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

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 ?

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

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