Release notes for final 0.6.0

Dear users,

v0.6.0 is now considered final. This post summarizes the main lines of work since the release of 0.6.0-RC2 (last june).

We’ve been working on improving the existing back-end of 0.6.0 and giving the user interface some cool new features. Here’s a summary:

Authenticated tunnel system

It is now possible to open authenticated/encrypted tunnels between GXS identities (the ones displayed in the “People” tab. The service—named p3GxsTunnels—totally abstracts the transport layer and offers the following features:

• tunnel maintenance for a given client, that gets notified when the tunnel is ready to be used or when it gets closed or killed;
• authentication based on the RSA key that each GXS identity represents;
• PFS encryption based on a DH key exchange using a 2048 bit safe-prime group, renewed each time the tunnel is re-created;
• transport security. Items are notified using ACK packets and re-sent when a ACK is not received. Duplicates are filtered out.

The Distant Chat system has been switched to using this new service. As such, it is not backward compatible  with 0.6.0-RC2 (sorry for that), but is now much more stable and reliable (e.g. distant chat messages always get delivered, provided that a tunnel can be openned).

Review of GXS

We performed a complete review of the GXS network service, that is responsible for the exchange of posts in forums/posted/channels. It is now much more efficient and the code has also been simplified a little bit (which is always good). Some important changes include:

• better synchronisation of messages saving a lot of bandwidth;
• new system for gathering the number of posts in un-subscribed GXS groups, which doesn’t require sending the message list any more. This saves some bandwidth as well.
• debug output system that allows to display the activity of a particular forum from a particular friend.

Special thanks to “Jolavilette” for his endless testing of GXS network system.

Messaging system

The distant messaging system of Retroshare relies on two methods to help messages find their way: tunnel which allow instant delivery at a distant peer but need both the source and destination to be online at the same time, and the routing matrix that allows slower but non synchronised delivery. We have improved the later significantly, which results in distant messaging being much more reliable.

GUI improvements

A “contact list” can now be managed by the user, in which identities can be grouped together. This allows to rapidly find a distant address to send a message to or to chat to without the need to scroll the entire list in People (which tends to grow large). It is also possible to limit the reception of distant chat and distant messages to the contact list only, in order to avoid spamming.

The GUI layout has generally been improved. We added plenty of tooltips, especially in the crypto-related parts. We also tried to make it compatible with high DPI screens. Some icons still remain too small, but it’s already improved a lot as compared to previous releases. We also added some useful features such as the possibility to export/import the list of friends.

The statistics widget has also been improved. This is mainly cosmetic changes but this widget helps users to isolate the source issues and report to us.

Reputation and anti-spam systems

A lot  of effort has been dedicated to helping users fight trolls. This includes two important features that have both proved very effective:

A reputation system allows to rate the identities in People (using a simple Positive/Neutral/Negative scale represented by numbers -1,0,1 respectively). It has been designed so that:

• it should be easy to rule someone out of your own Retroshare node by a simple click;
• a single user should not be able to drastically change the visibility of someone’s identity on nodes others than its own Retroshare node;
• friends should be able to team up so as to remove an unwanted person from their local network

Your own opinion about some particular identity is shared with your friends (using a differential system which only shares non neutral opinions). A final reputation score (which is a floating point number between -1 and 1) is computed according to the following rules:

• if your own opinion is neutral, the reputation score is the average opinion from your friends
• if not, the reputation score is equal to your own opinion.

The reputation score is then used by the different services using their own rules. For most of them, when the score is below -0.6, the identity is “Banned” and services just don’t accept to use it. Forums for instance mask existing messages from these identities and refuse to forward nor download them either.

Identities that are banned are not time-stamped either, which ensures that they will be removed from your node after 30 days of inactivity.

Forums also have been equipped with anti-spam flags which are:

• “Favor PGP-signed ids”. This raises the acceptance reputation score from 0.0 to 0.4 for unsigned identities, causing anonymous posts to be discarded unless the identity already has a good reputation. As such, forums with this flag ON will not allow anonymous users to create new identities at every post they create.
• “Keep track of posts”. This sounds scary, but this feature only displays in the GUI (using a tooltip for 10 days) the name of the Retroshare friend node that forwarded each particular post to you. This information is useless for every single user (and is could have otherwise been printed out by modifying the code!) but it allows a group of friends to easily team up in order to find out where annoying posts come from and cut the line.

Both flags are OFF by default, and can be changed by the creator of the forum.

I2P proxy support

Users can now create Hidden nodes that use I2P as a proxy. These nodes work exactly like Tor nodes. See the 0.6.0-RC2 release notes for more information.

Security review by Elttam

Retroshare being listed in the EFF secure messaging score board, it has raised the interest of Elttam, an australian team working on software security. They already have sent us a short list of potential security issues which we fixed right away. This is an ongoing process, so we can expect to fix more within the next weeks.

The main bug fixes concern potential buffer overflows, failure of malloc checks, and attacks using the Qt resource system. All the details are listed in the following Elttam blog post.

Special thanks to Elttam for putting some effort in fixing up Retroshare!

Various back-end improvements

SQlite performance has been improved using the GXS datastore for message data and metadata. We added packet grouping in pqistreamer. This apparently reduces the bandwidth caused by OpenSSL to first pad and encrypt many small packets.

The network back-end has been improved. The goal is to support IPv6 in the next future (This is the work of an external contributor “G10H4ck”. Special thx to him)

Conclusion

We provide builds for windows, MacOS (that now work with plugins!), and Ubuntu (on the ppa. See here), in the GitHub repository.

This version of Retroshare 0.6.0 is quite stable, so we finally decided to make it an official 0.6.0 version instead of a RC3 (Hence avoiding a potential RC4 which would bring bad luck ;-)). The next piece of work (really, and I’m not jocking) is to finally fix circles (i.e. groups of Identities and right management that come with it)  and include them in a 0.6.1 version. So you can expect that quite soon.

As usual, I’m just the writer of this post, and all this work should be attributed to the entire dev team, and to many external contributors who pushed important changes using the pull request system of GitHub, and also to the many testers who provided detailed reports of what needed to be changed.