Communications
One of the most commonly used communications tools apart from email is chat (text, voice and video) which is currently done by proprietary software such as Skype, MSN and Facebook. Recently it has become very unstable, it seems to be since Microsoft took over, but they say they've made no changes to the software. It often crashes badly on startup and also drops connections. I've been waiting patiently for a free software replacement, and this article is a repository of notes I'm collecting about such options.
FSF: Free software replacement for Skype
Skype is a proprietary Voice-over-IP program that uses a proprietary protocol. Skype is seducing free software users into using proprietary software, often two users at a time. Using proprietary phone software means that we can't be sure who is listening in, because we can't see the code. The Chinese government, for example, was found to have been spying on Skype conversations already, and they are probably not the only ones. We do not want to encourage the creation of a Skype compatible client, but instead, we want to encourage you to create, contribute to, or promote the use of free software replacements for Skype, such as Ekiga, and to encourage adoption and use of free VoIP, video, and chat protocols such as SIP and XMPP/Jingle.
Ways to help. The easiest way to help is to not use Skype and to encourage the use of a free software replacement instead. There are a number of programs, such as Ekiga, Twinkle, Coccinella, QuteCom, and SIP-Communicator that are working replacements for Skype. The Mingle project builds on Jabber to provide multiparty calling, and is supported by a grant from the NLnet Foundation. NLnet also supports the openMSRP project in this area. Users of such programs should file bug reports and feature requests to the projects. If you are not a developer, you can consider contributing to documentation and tutorials for such projects, as well as filing feature and bug requests. Developers should consider helping free software VoIP and video, chat, and multimedia communications projects.
Other options
- FSF Skype replacement projects
- Bye Bye Skype - Top Three Replacements
- Free and Open Source VOIP News
- Pichat
Testing
- Ekiga: Fail :-( Centralised service, difficult setup, requires port-forwarding meaning it can't be used from anywhere and is beyond most users capability to set up.
Empathy
We have working video calls with Empathy! it requires a central server, we're just using jabber.org at the moment, but it's an open protocol so we could set it up on the Organic Design server at some stage. It seems to use some peer-to-peer capabilities for connecting streams between clients as file transfers between users on the same LAN were faster than our internet connection speed.
Empathy is the default chat client that comes with Ubuntu. It supports many protocols such as IRC (which we use for our Organic Design private chat room), Yahoo, Facebook, Google talk and many others. The most important protocol for us though in terms of finding a Skype replacement is Jabber which is the original instant messenger based on the XMPP protocol. By creating a jabber.org account and then adding this account to the Empathy chat client, you can do video calls with anyone else using a video-capable chat client that supports XMPP.
Setup was a little difficult, but once we found what the issues were it should be easy for others to set up.
- The password must not be too long (there may be a 16 character limit or something around there
- Make sure that Encryption is selected in the advanced settings of the Jabber account
- Restart the computer after initial installation and setup as it seems to help fix audio/video problems
- There are very few settings for video/audio in the Empathy preferences, it's all done from the OS preferences
- Make sure that your microphone is not muted and input volume is up
Pidgin
After all this long search it turns out that Pidgin supports audio and video for Linux users! and it works much more solidly than Empathy, so we're back on Pidgin again, but using our jabber.org accounts through it :-) you have to select account type "XMPP" though rather than "Jabber" when setting up the new accounts.
Old notes
|
Unification
Unification is one of the main aspects of the project since it is about having a single underlying principle govern the bahviour of many diverse contexts. The Communications nodal organisation is a unification of the processes governing the three most generic informational resources; persistent storage, data processing and network bandwidth. All these have the same processes in common because they're all comsumable resources which require a "bookable" schedule, and the workload of each kind is broken up into packets for processing in the same way.
This unified result can be seen conceptually as an organisation which maintains the concurrent existence of the same information in many separate contexts (each occupying storage resource). Here the term "separate" means that when such information undergoes change, there is a cost in terms of processing and bandwidth resource. This separation means that syncronisation takes time, and the shorter the time, the higher the energy cost. So a global system of harmoncally related cycles (spectrum) is used to allow all contexts to work to a known cycle in their usage and updating of information.
This generic approach allows many other protocols or forms of bookable resource at all scales to be organised in the same way.
Current 2007 plans
The current nodal implementation of this concept is io.c which was developed in 2006 and runs in the peerd.c based peers. io.c currently handles files and TCP/IP streams, but is being restructured to unify all of input/output which currentl covers all kinds of input/output messages from its environment, including keyboard/mouse and time events.
The first step in 2007 for Communications is to get it working in a similar way to the current wikid-based fileSync function but more efficient and robust. It would still use the current wiki as its interface in the same way as fileSync until interface.c is mature enough.
Protocols
The idea is to be able to add new nodes exhibiting functionality for different kinds of caches to be maintained such as filesystem structures, wiki articles, database content, HTML, PDF, email etc. The only differences between them is the sequence of functions needing to be executed within the context of the content whenever changes are detected.
There are many different kinds of attributes or functions which may need to occur to keep different kinds of caches up to date, for example some need to be completely rebuilt when any part changes, whereas others can have only the changed content updated. Each protocol is just a set of specific functions which can transfer these protocol specific states to and from a nodal context. Each item in the rules tree is defining the schedule and the sequences of functions to apply for each destination cache of each source.
Event model
The other aspect of communications is the event-driven aspect, incoming events over various protocols results in the information being hooked into a Down in the nodal reduction loop-tree along with the roles required to process it.
Propagation of change
Each actual period of each cycle is represented by a particular globally known node so that any node can use associations as a common schedule format. Groups of separate nodes need to have common information, but it takes time and energy for changes to any local node space to propagate amongst the others in the group. By knowing the approximate resource requirements required to propagate the changes within any particular context, a suitable cycle can be agreed upon where only the first half of the period is used to propagate changes. The later half of the cycle guaruntees the content to be in a static state which is the same for all in the group.
Transport schedule
| [math]\sum_{i = 1}^{n} {i}[/math] | AB AC AD BC BD | The schedule of traffic between peers as seen from the global perspective and assuming the simplest situation of all peers needing to communicate with all other peers using the same amount of bandwidth, requires (n2+n)/2 sessions to be booked. A session in this case is meaning the booking a portion of bandwidth for the same period of time on two peers and establishing a bidirectional stream between them for that time. |
The central cycle of global activity is the local day/night cycle because that's the dominant cycle determining the timing of information availability. ie that the majority of syncronisation would be occuring at night time.
These total windows of time are divided into static and dynamic slots so that a portion of bandwidth is always available for spontaneous use.
Channels
The content which actually occupies the schedule comes from the applications, starting with the lowest level ones forming the base traffic and schedule within which higher level applications fit. Identity and Security are the low level S&D clients.
All the storage resources managed by S&D can be thought of as channels (like TV channels) where the future content is collaborated on by interested groups or members. This process creates a difference between the current state of the channel and the future state which is the basis of the S&D task queue. S&D uses these differences and the required times of availability at various endpoints of the content to determine what content should be booked for delivery in the transport schedule.
Nodal Structure
The structure of what's contained within what in the loop tree is determined by the order resulting in least context-switches. In the context of S&D this order is
- Root → Resources → Types → Instances → Sessions
So all the kinds of resources (Storage, processing, bandwidth, role-hours etc) have a common association structure defined by the root resource node which specify the general methods such as
- open close read write create delete
These methods are just abstract nodal interfaces defining the methods and associations necessary to act as a resource, the actual code in them is specific to the environment and the kind of resource so is defined in the instance of resource. The storage resources are therefore used in a uniform way so that
- nodeGetValue nodeSetValue nodeInsertKey nodeRemoveKey nodeInsertLoop nodeRemoveLoop nodeGetState nodeSetState
can be described purely nodally in the general resource node and need not be changed in the specific instances.
See also
- Wikipedia:Organizational communication
- Identity
- Nodal Reduction
- io.c - current implementation of storage & distribution in peerd
