[Freedombox-discuss] Working Groups Proposal

[Michal Kawalec]

I can help with Peer Model/Network Protocols (in that order).


Michal

Excerpts from James Vasile's message of 2011-10-17 17:18:10 +0100:
> I discovered last night that my mail to this group has been disappearing
> in to a hole, which explains why my recent emails have generated zero
> response or discussion.
> 
> Here's the working group plan, generally described.  This is a proposal.
> The people on this email list will decide how this actually works in
> practice.
> 
> We can populate these groups on the mailing list and then those groups
> will work via whatever mechanism they deem best.
> 
> Best regards,
> James Vasile
> 
> 
> 
> ## Promotion and Visual Identity
> 
> This team is the welcoming face we share with the world.
> 
>  * Logo and associated branding
>  * Prettier website
>  * Identifies conference and speaking opportunities
>  * Organize hackfests
>  * Encourage media coverage of the FreedomBox project
>  * Recruit more people to the project
>  
> ## User Experience
> 
> This working group will design the layer that the end user sees.
> FreedomBox will live or die based on whether it is easy to use, and
> ease of use for unsophisticated end users is this group's highest
> priority.
> 
> The UX Working Group may also create mechanisms to serve advanced
> users.  It might be the case that the FreedomBox will need a simple
> configuration mode and also an expert mode that we don't expect mere
> mortals to ever see.
> 
> Although UX is a separate Working Group, every aspect of this project
> is connected to user experience.  As such, it is expected that this
> Working Group's members will work closely with other Groups to produce
> a consistent and simple user experience across the many parts of the
> FreedomBox.
> 
> ### Goals
> 
>  * Identification of UX priorities, goals and standards
>  * UX conceptualization to serve those priorities, goals and standards
>  * Execution of that concept in the browser and smart phones apps
>  * Conduct real-world HID trials of the UI
> 
> 
> ## Network Protocols
> 
> This working group will develop the means by which FreedomBoxes will
> talk to each other in a secure, anonymous and private fashion.  This
> is a tremendously difficult project because there are so many
> considerations and trade-offs.
> 
> ### Goals
> 
>  * Evaluate mesh networking options
>  * Evaluate DNS/routing options
>  * Evaluate ways to find other FreedomBoxes and communicate with them,
>    assuming TCP/IP connections.
> 
> 
> ## Peer Model
> 
> The FreedomBox has social built in to the stack at a low level.  What
> that means is that it has a concept of who it (and its users) are
> interacting with.  That knowledge should be available across the
> device and allow the user to treat all interaction with people or
> groups of people in context-sensitive ways.  That means the FreedomBox
> will need a way to store and organize information about peers (both
> boxes and users on those boxes).  It will also have to make that
> information available to the applications on the FreedomBox, including
> existing applications with their own user models.  Finally,
> information interchange between FreedomBoxes will sometimes include
> data stored in the peer model.  What are the concerns about this
> interchange and what steps should we take to do this interchange while
> protecting security, privacy and anonymity?
> 
> This Working Group will recommend a peer model and ways to integrate
> that model into applications, both new and existing and also to
> exchange data with other boxes.  It will possibly develop software to
> implement its recommendations.
> 
> This Working Group can assume that data interchange will take place
> over protocols selected or developed by the Network Protocols Working
> Group.  This group should not develop protocols.
> 
> ## Configuration
> 
> Beneath the user interface, there needs to exist a layer that actually
> manages configuration.  This is the layer that edits text files to
> enact user choices, sanity checks those choices, rolls back changes,
> maybe files reports so we can identify option conflicts, etc.
> 
> This group might reasonably start by looking at Nick Daly's excellent
> config work.
> 
> ### Goals
> 
>  * Create an API for talking to the UI layer.
>  * Prevent conflicts or breaking the box.
>  * Enact config choices (edit text files, change db entries, run
>    scripts, etc.)
>  * Record new conflicts so we can prevent future conflicted config
>    states.  Optionally report that data.
>  
> ## Social and Applications
> 
> Decentralizing the web requires self-hosting the applications used by
> so many people as part of their daily lives.  Email, (micro)blogs,
> social networks, photo-sharing, shared whiteboards, file sharing, etc.
> This group will evaluate existing software and identify software that
> can be hosted on the FreedomBox in conformance with its goals and with
> minimal changes to the software.
> 
> ### Some Goals
> 
>  * Separate data from applications
>  * Export/import/interoperation with existing services
>  
> ## Security
> 
> This Working Group will identify the security concerns that plague any
> effort like the FreedomBox.  They will review new code, review
> existing software packages, and gently apply their paranoia for the
> good of us all.  It is recommended that this group work closely with
> the Network Protocols team.
> 
> There is a tradeoff between security and ease of use.  This group
> seeks to illuminate rather than defeat that tradeoff.
> 
> ### Goals
> 
>  * Allow as much communication as possible while protecting security,
>    privacy, and anonymity.
>  * Identify the trade-offs between security and ease of use and
>    recommend points along the continuum FreedomBox might inhabit.
>  * Allow security-minded users to have security while interoperating
>    with users who choose less secure mdoes of operation.
> 
> ## Documentation
> 
> This Working Group will develop documentation standards and execute
> those standards to provide end users as well with all the information
> they need to use a FreedomBox.  This Group may also create
> documentation for developers.
> 
> The existence of a Documentation Working Group does not free others
> from writing and maintaining documentation.  Documentarians will work
> closely with other Working Groups to *help* with the documentation
> effort and to standardize it across the project.  Responsibility for
> documenting FreedomBox technology, though, remains with those who know
> it best-- e.g. those who develop, customize and package it.
> 
> 
> ## Platform Group
> 
> The Platform Group tweaks Debian, packages software, studies
> deployment, brainstorms the path from a stock Dream Plug to a working
> FreedomBox, investigates other platforms and anything else involving
> the layer from the OS on down.
>