Release notes for v0.6.1

It’s been a long time since our last release, but we’ve been busy 😉 Below is a summary what’s new in the software.

Group-based privacy for channels/forums/posted

Forums, channels and posted threads (and any entity represented by a a “GXS group”) can now be limited in their distribution. This happens in two different ways: limitation to a group of pseudo-anonymous identities (the ones in People), or limitation of a group of friend nodes (the ones in Network). The choice is available when creating, or when editing the properties of a forum:

Both features considerably enhance the privacy of media that uses them. They stand for the base architecture element of a future social network layer.

External circles

External circles represent sets of pseudo-anonymous identities. A new tab in “People” allows you to create/modify them. A lot of options and handles are available there, for maximum flexibility. The downside is that the whole thing can be a bit scary 😉

People need to meet two conditions in order to be a member of a circle: they need to “apply for membership” and they need to be “granted as member”. Only the administrator of a circle can grant you, by adding you in the “invitee” list. This two-way membership not only allows people to request membership, but also prevents arbitrary circles to be created in order to spam unwanted information/data through neighbour nodes.

The GUI displays circles for which you are a member (a.k.a. “Circles I belong to”) and other circles. The bullet displays information about your status. Yellow means that you’re either applied and are waiting to be accepted, or invited and have the possibility to accept to be a member.

A contextual menu in each circle and each invitee/member of a circle allows you to act appropriately. This can be used to e.g. request membership for one of your identities, or grant membership if you’re the administrator of a circle.

Tooltips on each circle tree entry give information about:

• Circle ID: This allows you to disambiguate which circle you’re dealing with.
• Visibility: who can see this circle. A circle can indeed be restricted to another circle (see “self-restricted circles” below).
• Your role: you are either a “user”, or an “admin”. The later means you created the circle, which allows you to grant membership, and invite people to be a member.
• Distribution: unlike e.g. forums, circles spread automatically. Unless restricted to another circle, they are made visible to your neighbour nodes, so that people in this node can e.g. request  membership to that circle.
• Status: states whether you are a member or not.

Security of circle-restricted forums/channels/… is ensured by encrypting the data for the message IDs, and group Meta Data (e.g. forum IDs, etc) for the set of members, using envelop encryption. Doing so, only people which are true members of the circle are able to see and handle that data, and to request and send message content. With this system, circles can contain anonymous IDs as well as signed IDs.

Now, let’s complicate this thing a bit further: since circles are also “GXS groups”, they can be themselves restricted to other circles, including themselves. With this, we can create “self-restricted” circles, which will only be visible to people in the “invitee” list. As such, the administrator of the circle not only limits the membership of people but also who can be aware that this circle even exists. For obvious reasons self-restricted circles are propagated encrypted to the “invitee” list, instead of the list of full members.

Many (Probably non all tested 😦 ) options potentially exist in this system, including pairs of circles restricted to each other, the possibility to limit the distribution of pseudo anonymous identities to a particular circle, the possibility to limit circle distribution to a local group of nodes, etc. Not all of them are made accessible by the GUI, but can be used right away by plugins to implement a new types of media.

Groups of neighbor nodes

Groups of neighbor nodes are what we call “Local groups”. They have been used already for limiting the access of shared file lists. In v0.6.1, they can also be used to limit the distribution of forums/channels/posted as well.

Since node groups are only known by the owner of the Retroshare node (they are not shared with friends), they force the node to work as a hub for message distribution. All friends in the group receive posts and information about the media, and only forward information back to the “originator” of the media, which will then share them with other nodes in the group.

Use cases include sharing personal information with friend nodes only. This may apply to photos (yes,there is a “photo-album” plugin, currently unfinished…) and your holiday movies to share with e.g. your family members, etc.

Groups of neighbor nodes can be managed in the Network tab, from the right-click menu in the list of friends.

2 – Work on RTTs and packet slicing

We have identified two major problems causing unstable round-time-trip measurements (a.k.a. RTT) : many small packets would cause an overhead due to padding in SSL encryption, and seldom large packets would block a stream with a given friend for an arbitrary long time when the bandwidth is highly challenged. We fixed this in two ways:

• small packets (< 512 bytes) are grouped before being sent to SSL. This was easy since the data stream is anyway sliced into proper packets on the other end.
• large packets are sliced into 512 bytes chunks, in a backward compatible manner. Old peers will not accept sliced packets, which is detected on the other side and cause only entire packets to be sent. When both ends of the SSL tunnel agree, packet slicing happens.

This optimization has been done in order to be able to provide better VOIP in the future (See below), but it also drastically impacts the whole software.

3 – WEB Interface

The WEB Interface part has been improved. Here’s a non exhaustive list of changes:

• possibility to paste of Retroshare links
• improved responsiveness
• switched WEB API from React to Mithril
• chat lobbies are available now

4 – Identities

Since Identities represent users beyond friend nodes, they had to deserve special care so as to make them sufficiently SPAM-proof:

1. The diffusion of forum messages (and any GXS-based group message in general) can be limited to signed identities, or even identities signed by known nodes. If not, a strictly positive reputation of the message signer is needed for the message to spread.
2. The software now allows to automatically ban identities based on their node signature (“People->Person->Auto ban…”).

These two options together (handled by the forum’s administrator) allow to severely reduce SPAM, at the expanse of a bit less anonymity. As far as reputation is concerned, each user can also change the threshold below which identities are banned (Options->People).

Finally Retroshare now offers the opportunity to create a new signed identity when creating a new node/location, which should help newcomers to get ready to use internal forums/chat/messages right away.

5 – Various features/improvements

The full list of improvements since v0.6.0 can be seen in the change log. The most important ones are summarized below:

• New icon set. This is a matter of taste or course 😉
• ability to define which instance receives system URL calls when running multiple Retroshare on the same computer
• auto-removal of messages in unsubscribed forums/channels
• separation of public/private RSA keys in GXS
• per-neighbour node bandwidth limits, to be changed in “Network->peer details” options
• improved chat widget (added new functions)
• fixed annoying crash on quit, due to faulty memory management
• fixed unit tests. Can be run using “make tests”.
• cache for sqlite3 access of group meta data, improving forum speed.
• usage of banned IPs in LibBitDHT
• Several bug fixes 😉

6 – Future developments (as planned)

The next features to come will be the following, with “priority”:

• differential file list exchange and removal of the old cache system (high)
• end-to-end encryption for anonymous tunnels (high)
• variable bit rate in VOIP (high)
• better (yet backward compatible) serialization code. There’s a lot to do here (medium).
• usage of external circles (or simply an admin list) to cryptographically control the access to chat lobbies (and independently for read and write access)
• opening/documenting the API for plugin developpers.

As usual, many thanks to all the developers and testers who contributed to this milestone, with a special mention to the anonymous persons who spent a lot of energy helping us improving our forum SPAM-resistance strategies… More seriously, G10H4ck, Phenom, Jenster, Jolavillette, Beluga, Zener, Sehraf, AC, ASmith, etc. stand among the people to thank.

May the privacy be with you!

Links

Release files: https://github.com/RetroShare/RetroShare/releases/tag/0.6.1

Downloads: https://retroshare.github.io/downloads.html