[Freedombox-discuss] CCC Meeting Notes

Tue Aug 16 11:13:27 UTC 2011

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Isaac,

Just read your notes from CCC and wanted to comment on the wireless components.
 For the FreedomNodes, I would hope that the plan is to use 802.11a/b/g/n radios
and not tie them solely to 5GHz.  The 5GHz frequency, while often less
congested, has a harder time propagating through architecture, trees, etc. than
2.4GHz.  Since most consumer-grade equipment runs on 2.4GHz, being able to
bridge between 2.4GHz and 5GHz would maximize the options for ad-hoc meshing.

In terms of the Freedom Tower, the 3650-3700MHz band only allows higher-powered
use for "lite licensed" devices -- which means registering the device's location
with government authorities.  3650-3700MHz is also not harmonized globally, so
that could present a problem for sales of these devices in many locations around
the world.

Overall, I love the idea of several different types of FreedomBox equipment;
however, I also want to ensure maximum interoperability and extensibility of the
technology.

- --Sascha Meinrath
Director, Open Technology Initiative
New America Foundation

Date: Mon, 15 Aug 2011 15:40:29 +0200
From: Isaac Wilder <isaac at freenetworkmovement.org>
To: freedombox-discuss at lists.alioth.debian.org,
	discuss at freenetworkfoundation.org
Subject: [Freedombox-discuss] CCC Meeting Notes

********* *BEGIN ENCRYPTED or SIGNED PART* *********

Hello All,

This is Isaac Wilder, from the Free Network Foundation. I convened a
meeting at Chaos Communication Camp a couple of days ago, in order to
talk about FreedomBox, FreedomNode, and Free Network Architectures. I
told those in attendance that I would type up my notes from the
meeting, and send them to the list.

To start, I presented what I saw as a workable architecture: several
protocol daemons connected by a 'graph' or 'identity' manager that
handles access control. We came up with the following list of
essential daemons, in approximate order of priority:
1)HTTP
2)XMPP
3)SIP
4)IMAP
5)TOR
6)NMTP

As far as daemon selection goes, there was (general) agreement that we
should use Apache for HTTP (despite its weight), Prosody for XMPP, and
Yate for SIP.

We also discussed UI, stressing its paramount importance to the
success or failure of the endeavor. The idea of having the user
configure and interface with the box via chatt (XMPP chat) was
suggested. There's also always the fallback position of a web GUI.
Still, many felt that the chat idea has great potential.

Then, we chose to approach the discussion from the angle of open
problems, both short and long term:
1) The ability to generate good random numbers

    a) We could foster the development of a free/open entropy key.
    Problem with this solution is cost.
    b) We could fetch randoms from a trusted upstream source. Problem
    here is with the first Diffee-Hellman exchange.
    c) We could feed a noise-generating circuit into the audio
    interface. This seems like a viable solution on the DreamPlug, but
    is not an option on some hardware.

2) How to build robust, no-hassle mesh networks.

    a) B.A.T.M.A.N. protocol is good, but people have been having a
    lot of success with the new OLSRd. FunkFeuer has had great results.
    b) The problem is with the radios. A single, embedded 2.4Ghz radio
    will not lead to good QoS, plus it should probably be reserved for
    communicating with client devices inside the home/business.
    c) The Free Network Foundation is designing FreedomNode, which is
    essentially the same as FreedomBox but with the addition of two
    5GHz radios, allowing for multiple full-duplex mesh links.

3) Free Drivers (wifi and bluetooth drivers are closed)

    a)Argue with Marvell
    b)Reverse Engineer

4) Persistent Names (which don't rely on existing DNS)

    a)Name resolution based on a DHT. Problem with table poisoning
    could be approached by authorizing and authenticating those that
    participate in the resolution table. This would still introduce a
    degree of hierarchy, but it would be far more distributed than
    what we have now.
    b)Use TOR hidden services. This solution is good for those that
    are running tor, but otherwise require use of tor-to-web. Also,
    the .onion names are not human-readable, so would require further
    resolution via the mechanism above, or existing DNS. This was a
    topic of much controversy. Many feel that it is unnecessary to
    route all FBX traffic through TOR.

5) Grid Dependence (electrical)

    a)Add PV cells to rig. (Again, $$$)

6) Store and Forward Messagaing (The ability to store messages until
they become deliverable)

    a)Utilize Shamir's Secret Sharing Scheme (SSSS), gather physically
    and exchange via radio.

7) Archiving Proxy that maintains privacy and security

8) Distributed Backup

    a)Tahoe LAFS
    b)Pagekite

9) Bitbank

10) One Time Passwords

11) Distributed Search

    a)YaCy
    b)Seeks

12) Stealth Hardware

    a)Sell a version wrapped in some other shell

13) Access control

    a)Friend of a Friend
    b)Case by case + key rating system

We also talked about the incentives for building such a device:
1) Help fight central central control
2) Enable communications that are materially peer-to-peer
3) Enable local verticals

    a)Filesharing
    b)Local information sytems

4) Co-ownership of the PHY layer
5) Save money by building access cooperatives
6) Become our own ISPs

In addition, there were some trains of discussion that do not fit
neatly into any of the categories above. We talked about the
importance of thinking about how technology is actually adopted in the
real world. It is picked up first by power users, and then friends and
family take their tech cues from those their trust and respect, or
from their local technology shop. What incentives do the technically
inclined have to recommend this solution to their friends? What about
the people running a small computer store or internet cafe?

Finally, I talked a little bit about why the FNF is involved in FBX
development, and what we'd like to build using the box as a platform.
I'll summarize it quickly, here, but there's more at www.thefnf.org,
if you're interested.

We'd like to add two 5Ghz radios to the rig, enabling it to establish
high-throughput links to other boxes in the neighborhood. We call this
FreedomBox + radios rig a 'FreedomNode.' We're also working on what
we've been calling the 'FreedomTower.' This is a piece of
infrastructure that would have 5GHz radios and sit inside a mesh of
two to three thousand boxes. It would also have 3650MHz for long-range
links to other towers, thus forming a regional mesh network. Finally,
inside the regional mesh there would be a single 'FreedomLink,' - a
multi-homed, fiber-connected host, sitting in the 3650MHz regional
mesh, and speaking BGP to the global internet. This is a practicable
way to build Autonomous Systems that are owned and operated
collectively. Of course, outside lines could also be connected at any
level of the hierarchy (box, tower, link), and shared among the
community.  The vision is large in scope, but the first step is
definitely to bootstrap the FreedomBox.

Anyways, I hope that this all will jump-start some discussion.

take care,
Isaac Wilder
Directer, The Free Network Foundation
www.thefnf.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOSlDXAAoJEFfmzqn2ZOEsRcgP/0Qo3kFXaDgAyemj4s7jhGWo
BN+UdtWEQdK5Wwrzlj8vFeqOJYkQnRAkotBgL2UOq1K7XnUoia2Z9ixVsaOsGL8T
MF0b2TnmugPFpzK3OPMeS1jwtxGDilzhX5dfj/CgS6g8ObQromaKuXUkdSrEsJsh
Ny50KrXS7Dqg/yqY8iHlCNTVgXGz2DMDOyWHpJQuQA6aRxpv/BBDmAN3oIxmjFLe
KeBRx72+8YX4Lm1fmMUsTFCZC0SC0iGAYged2ppP9GnpB1wBnQvGzywxRB10BLRL
eVVcRU5GI5g3XfPnLBzYXupfQYYHDZ8K0kRuoHQ/MmzzCYmdqrDK5qMhYnYWqTLI
wP32GakuyQPwnCYtxXQDSf+HH9IVeFPoCt5wPmm75ARBQ8bC9kDVwRkc+JHC0dJ5
8T/o6Kb8PtSA7mDwmKrNNPUoIxXa75R7K1kYb2sd1c1UoloYf+DDvj9tNze96Chj
cDQwHruOFFHSQYbo106JFWnSJ0CR2uYVyjiPvi4F3r7/y6hTEqPfma+c1scS+aty
vXG6WCqM8BCCbGfBx98ncpQ2tEg3eCLgm7pAcUk1omlobZ/jhGF/JXB4eTfIEghB
G/HMx8c2B2jttK3PjE+ebfgaF3NcOegSY+tCHk1q59IsfrU20TTOcQZ3cJfubRso
6LJ7DQhlNTE3EO3BHCJu
=wZq1
-----END PGP SIGNATURE-----