Bitgroup

These days the issue of privacy online is becoming more and more important as we hear about the shocking extent to which organisations like the NSA are violating people's privacy and the giant corporations like Facebook and Google are misusing our personal information. Social networks have become an important tool for people from diverse locations and cultures to get together and organise, but when this organisation is used for purposes that oppose this corporate and government oppression it gets shut down. It's become very apparent to many people that a new form of social networking tool is required that meets a number of important criteria.

Free and open source: For it to gain widespread use and be as accessible as possible to all people like Facebook and Google applications are it must be completely free to use. But it's very important that the source code be available for peer review so that the users can be satisfied that it's secure and there's no nasty tricks involved such as misuse of personal information of "back doors" through the security systems.

Peer-to-peer: One of the big problems we're starting to see nowadays is that the centralised model of setting up sites on a web-server for the users to access is not very resilient. We're seeing many sites that start of with great ideals when it comes to upholding peoples rights to privacy, but when they become too popular they come under attack by "the global agenda" by being accused of aiding child pornography or "supporting terrorism". They're then forced by law to turn over their user's data or face being prosecuted and shut down. However there are some online applications and services which have come under attack but have not been successfully shut down such as The Pirate Bay and other file sharing applications and the Bitcoin crypto-currency. Although these applications are considered a major problem from the perspective of the global agenda, it's so far proven impossible to do anything about them. The reason is that they have no central point of attack, shutting down accounts or servers or prosecuting people has no effect on these systems. It's for this reason that it's absolutely necessary for us, the people, to have access to a new social networking tool that is completely peer-to-peer.

Supports privacy and anonymity: Another thing that has been growing in importance a lot over the last few years is the ability for users to maintain their anonymity when working online. It's rapidly becoming a violation of law simply to voice opinion that opposes the status quo, which is in itself ample reason, or even a moral obligation, to oppose it! It's important for people who oppose this draconian system to be able to do so anonymously, especially in exceedingly oppressive countries that don't allow basic freedom of speech rights such as China and the USA.

Bitmessage

Anyone whose thought seriously about developing a any kind of peer-to-peer application that has more than basic file sharing functionality will know that there are some extremely difficult challenges to overcome, particularly when it comes to the "sign up/sign in" and the ability for many users to "subscribe" to information. There are many complex issues involved in security and content distribution which are orders of magnitude more difficult to accomplish in a system where there are no fixed servers, and every peer must be considered as a potentially hostile to the network.

The first application which has really made headway in moving the world of peer-to-peer beyond the simple file-sharing application is the Bitcoin crypto-currency. The fact that it's financially oriented creates much more motivation for attackers to try and exploit any weakness in it, but it has stood up to everything the hackers and the governments with their billions of dollars have thrown at it. Now a few years down the track, the Bitcoin code is starting to be used in other more diverse applications such as in the Namecoin alternative domain name system and the Bitmessage secure anonymous messaging system.

Bitgroup

Bitmessage is of particular interest because messaging is a very general application that can be used as the foundation for many other applications - social networking being one of them. And that's what the Bitgroup project is about, building the foundations of a secure peer-to-peer anonymous social network using Bitmessage as it's fundamental communications over which users and groups are formed and connected, hence the name "Bitgroup".

Bitmessage is programmed in Python, and since I've now had some experience working with the Bitessage API through Python when I made the Bitmessage gateway so the main networking aspect of Bitgroup will also be written in Python. The interface will be in JavaScript running within an embedded browser component within the Python application. This is so that it will be very easy to allow it to be run as a web-application server and will also make the interface programming and theming much simpler.

The code is being developed in our tools repo which you can view on our Github mirror here. It'll get moved into it's own repo after it's our of the pre-alpha stage.

Users and groups

The basic functionality required for building a social network application is the channel which is a collection of changing content maintained by one or more users that can be "subscribed" to, or "followed" by many others. This functionality allows for all the different behaviours that make up a social network system such as creating pages, posting items, following and "liking" things, as well as other potential functionality such as blogs, wikis or scheduling applications.

The first step in this "channels" idea is to extend the basic messaging and subscription functionality of Bitmessage to allow for the formation of groups that have not only subscribers that can view the public content generated by the group, but also "members" who produce and publish the group's content together and also have access to the private members-only content.

There are two key features of Bitmessage that allow for the formation of groups. First is that any number of running instances can have the same From address, so sharing the private keys associated with an address (or in the case of a deterministically generated address, sharing the key used to create it from) with other people allows them to become a member of the group by being able to publish information from that group to its subscribers or other members. The second feature is that users are able to subscribe to their own addresses which means that you will receive broadcast messages from others sending from that same address. This means that a many-to-many messaging system can be set up by a group all using the same address to broadcast from and subscribing to it. They can then use the private key component of the address as a shared encryption key so that they can keep some of the messages private within the group.

In our system, users and groups are practically the same thing and are both essentially a Bitmessage address at their core. The only real difference between a user and a group in the Bitgroup system is that users are entities that "own" a running instance of the application and don't have any members, whereas groups are entities that are created by a user and can have other users become members via invitation.

The Bitgroup system encapsulates this users and groups functionality in a class called Group. This class allows messages to be of different types in addition the generic type of message designed to be read by a recipient user or subscriber. These new message types are processed by the Bitgroup application instances internally instead of being read by a user. Any new types can be added for extending the functionality of the Bitgroup system, but initially just invitation, acceptance and confirmation messages are used to add the group membership functionality.

Nodes

The group functionality created by the Group class is a messaging-only system with no persistent content, so the next level of functionality is done by a class called Node which this content aspect in the form of a structure of properties and attachments. A group can have any number of nodes which can be viewed and modified in different ways depending on the extensions the group has installed, for example as a folder of files, a list of historical posts, as a collaborative document etc. Later as more extensions are created, this channel functionality can form the basis for many other applications such as group schedules and decision-making tools.

Interface

Browser-based interfaces are extremely convenient because they allow very easy linking to other sites, and are very easy to develop since there's so many useful tools and technologies available such as jQuery and CSS, and allows groups to open up some of their content to the web for easy access. Some groups could even run a complete web gateway if privacy and security were less of a concern to them so that their members and subscribers could log in over the web like a normal social networking site. Since the browser will be connecting only to our local socket, and our local socket only accepts requests from our own application the browser is safer than the usual situation. However later we'd like to offer the option of an in-application version of the interface using PyWebkit or PyGtkMozembed.

We'll be using the Single Page Application pattern for the structure of the interface code. This keeps the roles of the Python and the JavaScript very clear with no need for a messy mish-mash of interface functionality spanning both the sides. The entire interface application will be written in JavaScript and only reloads the page/application when the user changes the context to a different group (since each group decides for themselves which extensions will be active and therefore which JavaScript will be loaded in the page).

The local part of the URL consists only of the group name or Bitmessage address and everything after that is the hash-fragment, so that only a change in group will result in a page-reload. The URL format after the hash is a slash-separated path, the first element being the currently selected view and subsequent elements being decoded by that view's URL-routing method and sent to the relevant method for processing.

To allow for more rapid interface development and make it easier for other developers to be involved and extend the system we're including jQuery and using jQueryUI for all the interface elements such as tooltips, progress bars, tab-sets etc.

The Python side of the application is purely involved with Group communications across the network and with keeping the group's property structures up to date. Any new messages or changes to properties are reported to the JavaScript side (via a 1px SWF to avoid Ajax polling) when they occur.

Extensions

Extensions will play an important role in the Bitgroup system. The idea is that extensions are used to extend the base Group class, but each group's members can choose what extensions are active for their channel based on their needs and their security concerns. Python is an excellent language for this kind of thing because not only does it have multiple inheritance allowing a group's class to be defined from the base Group class, the Channel class and all of the group's enabled extensions, but also it allows these to be defined dynamically during run time. This is exactly what we need because the interface must allow the user to move quickly between different groups which may all use different sets of extensions. Of course this could still be done in any other language, but it can be implemented particularly concisely in Python and is actually a recognised principle called Mix-ins.

As well as the mix-in method of extending the system an event/hook system is being included so that extensions can register a callback method with any of the key events that occur in the application. The stack of registered callbacks for the events are part of the Group class which means that every group will have a different set of registered callbacks depending on the extensions the group has chosen to enable. This prevents extensions from having access to any information via callbacks for groups that haven't enabled the extension.

Adding new views

To add a new view, an extension defines a class, adds a render method which populates the content div, and adds the class to the available views in the app.views list. It may also add the view name to the various node types that should have the view.

{{{1}}}

Custom events

We need to add custom events throughout the code that extensions can subscribe to so they can adjust or extend the behaviour of the application. Extensions will initially only be available on the JavaScript side and will use the jQuery trigger method. Events are triggered with parameters passed to the handler that are specific to the event are packaged inside an args object so that they can be adjusted since JavaScript doesn't support passing-by-reference on non-object variables.

This is an example of an event the could be triggered by an extension:

{{{1}}}

Here the argument foo is being output after the new bgNewEvent event is triggered to see if any handlers have changed it's value. We precede the event name with the "bg" prefix to ensure there's no conflict with existing events in the environment.

A handler could subscribe to this event and modify the foo value as follows:

{{{1}}}