• attachment:dc10-freedombox.txt of FreedomBox

   1 FreedomBOX BOF - August 6, 2010 - 9:30AM
   2 
   3 = What do we base it on? =
   4 
   5 unstable?  might make sense - tom
   6 
   7 architectures to support?  shivaplug is armel
   8 
   9 wrt* is underpowered and has kernel issues.  also these routers don't have much storage.
  10 
  11 put our energy into the application stack.
  12 
  13 need to have a development platform.  shivaplug is the answer.
  14 
  15 d-i has issues on guruplug specifically but not on shivaplug in general
  16 
  17 this project might be a nice way to test CUT
  18 
  19 hopefully we do the infrastructure to enable the applications to come out
  20 
  21 identity - project moonshot (what is that?)
  22 
  23 plugpbx is a project to get asterisk deployed on sheevaplug with munin, webmin, etc.
  24 
  25 sam: layers we need.  lowest layer #1 - server-capable network connectivity, even if behind NAT.
  26   layer #2 - naming.  be able to get to it from anywhere.  rendezvous services.
  27   layer #3 - friends list layer.
  28   layer #4 - application isolation.  security.  make sure our credibility isn't damaged.
  29 
  30 liw - why would someone want this?  (how do we "sell" it?)
  31    "server at home" is exciting to us
  32 
  33 many people don't hate facebook for the same reason we do -- mainly speed and interface issues.
  34   if we want to convince quilters do switch from facebook, you need an argument more than "freedom".
  35    - bdale
  36 
  37 cory doctorow has a novel-length explanation of why we care about this problem. -sam
  38 
  39 ian: best 3 compelling reasons are:
  40   - backups
  41   - portability.  don't like having data trapped in a particular social network.
  42     just send data to whatever sites.
  43   - a good citizen that makes your computing activities better.
  44     if we add privoxy, people will think we're saviors from on high.
  45 
  46 for any given person purchasing it, there is, for them, a killer app.
  47 
  48 perhaps use this as an opportunity to build an ipv6 network to get around nat problems
  49 
  50 killer app doesn't have to be the same at every stage.  might not want to worry about first
  51 million when worry about the first 10,000
  52 
  53 if you're going to get a wireless AP, get something with a stack on it anyway.
  54 
  55 market it as a platform to build on.
  56 
  57 which features are we going to focus on.
  58 
  59 a lot of what we're talking about has already been implement.
  60   tao? - distributed backup/filesystems
  61   identity layers - diaspora, pgp (pgp shouldn't be visible to the user)
  62   routing - ipv6 might not work from beginning, should focus on door tor
  63   have something for every killer feature except ui, glue (and diaspora)
  64 
  65 bdale: we should divorce concerns about specific hw platform from decisions about stack of protocols
  66 
  67 liw: ui - this thing shouldn't provide sysadmin stuff at all.  shouldn't have to touch to keep it working after initial setup.
  68 
  69 there has been an alioth project requested.
  70 
  71 might be useful to apply for a grant, perhaps from the soros open foundation.  (some disagreement about this)
  72 
  73 this needs to be transcribed into the wiki.
  74 
  75 there are a bunch of layers that we need to be paying attention to.
  76 
  77 should degrade gracefully.  
  78 
  79 http://wiki.debian.org/FreedomBox is up now.
  80 
  81 IRC.  #freedombox