[Freedombox-discuss] CCC Meeting Notes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I decided to respond and comment on some of the FBX issues/topics raised
by Isaac in his notes below:
On 08/15/2011 03:40 PM, Isaac Wilder wrote:
>
> 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.
Why is FTP missing from this list? Is the idea to use HTTP in its place?
> 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.
I do not quite understand the idea of configuring and interfacing with
FBX via XMPP chat. How do you envision such process? It seems to me that
web interface might be more user friendly (which is very important for
FBX) since people are already familiar with it. We want the learning
curve to be as gentle as possible.
> 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
If I understand your concern correctly, then I disagree that ALL Wifi
and bluetooth drivers are closed-source. h-node is a database of
hardware devices that are compatible with a fully free operating system.
For example, drivers for many Atheros chipsets are free software:
http://www.h-node.com/wifi/catalogue/en/1/1/undef/undef/yes/undef/undef
There are also bluetooth drivers which are free software:
http://www.h-node.com/bluetooth/catalogue/en/1/1/undef/undef/yes/undef/undef
> 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.
DHT for name resolution seems to be a great idea. Based on my
understanding of DHTs, they seem to be exactly what we need in a
distributed network of a large number of nodes and join and leave the
network frequently.
> 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.
I agree with Isaac's and Vasile's opinion about including TOR on FBX. I
think that routing through TOR should not be the default configuration.
Those who want to use TOR always have an option to do so in addition to
the core services (as long as there is enough storage space for it on
the FBX, of course).
> 5) Grid Dependence (electrical)
>
> a)Add PV cells to rig. (Again, $$$)
Dependence on the electrical grid does not seem to be among the most
pressing issues that need to be addressed for the initial release of the
FBX. In the future, the cost/ grid independence dilemma could perhaps be
solved by manufacturing two different versions of the hardware box: A
less expensive version without PV cells and more expensive version which
includes them.
> 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.
It is escaping me how Shamir's Secret Sharing Scheme relates to storing
messages until they become deliverable. Why not simply store messages in
an encrypted text file until they can be send? I am obviously missing
something here. Can you please elaborate what exactly you meant here?
> 7) Archiving Proxy that maintains privacy and security
>
> 8) Distributed Backup
>
> a)Tahoe LAFS
> b)Pagekite
Never heard about PageKite before. It seems to be very very cool!
> 9) Bitbank
>
> 10) One Time Passwords
>
> 11) Distributed Search
>
> a)YaCy
> b)Seeks
If it is too costly to include a search engine as a server on the FBX
itself and one of the objectives is moving away from Google search to a
more privacy-aware search engine, then I suggest DuckDuckGo as an
alternative.
> 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
As most of us know, the problem of better data access control is one of
the motivating factors for the creation of the FreedomBox project. We
need work very carefully to implement this right else we will not succeed.
> 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?
One of the major incentives for those who are technically inclined to
recommend new technology to others is in many cases the fact that they
themselves are better off in one way or another if those around them
with whom they interact use the same new technology. Communication
protocols are good examples of this. For instance, unless I get those
with whom I communicate to use SIP instead of Skype, I am stuck using
Skype regardless of how tech savvy and progressive I am. In my opinion,
this is a big incentive.
> 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.'
This sounds like a good idea to me. Hopefully the cost of the device
would not climb too high as a result. We also need to make sure that it
is relatively easy to add those 5Ghz radios to the FBX hardware. It
would be a pity if the progress of building the Free Network was
hindered by the fact that there is no practical way to add the radios to
the Box.
> 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.
I am looking forward to continuing the discussion. I hope that at least
some of my comments will be useful.
Martin Dluhos
> take care,
> Isaac Wilder
> Directer, The Free Network Foundation
> www.thefnf.org
>
>
>
_______________________________________________
Freedombox-discuss mailing list
Freedombox-discuss at lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOTbrxAAoJEOzT5+ruTKvqCDgIAKzL6CVu8+MbvOOCX+WZQzFp
EH3cMDPJ/pwb6UvBeVd7GkjkoCfzMa0tc8bpUqg8IM1g9crZB1NVKcg+DT7M4tYa
zzh0r+842xJbKYFWXOmX3rXAbMhV3MAG/yFLOOsEfmV+5B7Bx8+vEpGi5uC50oDf
jptvYaHl/pb00K6GQ7W2BQweGs05iq/ReTcfVFNt8Ld9HsIeApdyv+pfwz1azXeU
6TqTLztfwp8dTsxPgGNPlDxckXiOSYFIwDqQDJl1C+XQ2sa57ZbD5rSnYuS0tllr
SBjBPx8gN7ZXugBJoO0CUTE/Mqyhv0WZsemUAWOQ4Fa7pMCNE6mPUotPbhEwhZc=
=rO74
-----END PGP SIGNATURE-----
Reply to: