[Freedombox-discuss] CCC Meeting Notes
> 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
> 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.
A notice for the VoIP services software selection:
Yate is not widely diffused abd known, scalable as Asterisk and FreeSwitch.
Asterisk has the wider diffusion but it's a very crappy code and have a
mixture of commercial/free management of the project.
FreeSwitch is 2nd in terms of diffusion but it's very well written,
modular and there is a huge commitment from the community.
Additionally FreeSwitch can be entirely configured trough 'web services'
that means not having to 'deal' with configuration files generation
(http://wiki.freeswitch.org/wiki/Mod_xml_curl) .
I support FreeSwitch as a choice for VoIP system, also for it's wide set
of supported protocols and extensions:
http://wiki.freeswitch.org/wiki/Modules
> 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.
If we want to make something 'configurable' via a XMPP chat it means
that the client OS (Windows, iPhone, etc) must have an XMPP client, so
we are defining a pre-requisite to have a specific software to configure it.
That's not something available in a general Desktop OS, upon fresh
installation.
So XMPP based configuration would add-up complexity for first-time
configuration/setup.
If 100% of routers/ap/switch/servers/network-equipment come with a web
GUI for configuration, probably there's a reason.
> 6) Store and Forward Messagaing (The ability to store messages until
> they become deliverable)
The proposed concept is to allow freedomboxes to be 'movable' when nodes
cannot interconnect each other.
Remember that the WiFi on 2.4ghz/5ghz, unless using directional link and
higher powered transmission, are not very powerful and there are also
great chance that many freedomboxes will not be able to interconnect
each-other at radio-level.
There would probably be a set of conditions/situations where the
freedomboxes will not be able to communicate via radio one-each-other
because they are too distance.
Think if in damascus one activist is far 20km from another one.
They would not probably be able to have their freedombox to connect.
In such condition if someone will phisically act as a delivery system
for data (bringing a freedombox from place A to place B), it would be
able to load/unload data on the path by entering into the coverage area
of other freedomboxes.
An old 'postal service' but for data that could be carried on by man
walking on the streets to reach the coverage area of other freedomboxes.
In a condition like that probably only a Store and Forward messaging
system would work, in order to exchange messages and data.
But maybe such kind of issue would be better addressed by freedomnode
and not by freedombox?
-naif
Reply to: