RetroShare is a Open Source cross-platform, private and secure decentralised communication platform. It lets you to securely chat and share files with your friends and family, using a web-of-trust to authenticate peers and OpenSSL to encrypt all communication. RetroShare provides filesharing, chat, messages, forums and channels.

Features

  • Serverless, encrypted Chat & Filetransfer
  • Multiple simultaneous downloads / uploads
  • Search Friends
  • Messages
  • Forums
  • UPnP / NAT-PMP port forwarding support
  • GnuPG Authentication
  • OpenSSL Encryption
  • Plugins support
  • Graphical User Interface written with Qt4 toolkit
  • System tray integration

Notice: Under Windows you must install GPG4Win v1.1.4; RetroShare requires it without you can't create your RetroShare Key. The win32 installer automatically installs it, but you will need to first remove any more recent version of gpg4win.

What's New

This release took even more time than the previous ones. This is for one simple reason: we changed lots of core features of the software (e.g. token system, notifications, etc), which had us re-implement some GUI parts taking the opportunity to make them more efficient or re-designed to a better layout (e.g. channels, boards). In the end, lots of bugs have been introduced in the process and it took some time to reach a perfectly stable product again. While we decided to stop developing new features in November 2020, it took us 4 months to fix all the bugs, mostly thanks to a really good user-feedback. As you will see, it was totally worth it. Completer release notes here.

1 - New channel and board layouts

Channels benefit from a new layout that is more suitable to their usage. Two different visualization modes are possible (top right blue button, left to the search field): grid or list. Use the double image below to compare both views:

Both in channels or boards, the new visualization system is now based on an abstract item model (instead of manually inserted items as it was in v0.6.5) making it much faster to load and offering a lot more possibilities for how to display the information.

2 - Short certificates

Up to v0.6.5, Retroshare used certificates containing the SSL id, the PGP public key and naming information. It appears that we can afford to only send the PGP fingerprint instead of the full key, without losing any security. Here's why ("<=" means validated by) :

  • Full certificate (old method, a.k.a. type-1):
  • SSL handshake <= certificate PGP signature <= profile being listed as friend.
  • Short certificate (new method, a.k.a. type-2):
  • SSL handshake <= SSL Id listed as friend

In both cases the handshake is eventually validated by information provided by your friend using a supposedly secure transmission (hand-to-hand, encrypted email, etc). This part of the security model is still up to the user.

Once a node is connected, it will supply its own PGP key using discovery (as before), which will be checked to match the fingerprint in the certificate and then be marked to be used in type-1 handshake later on for future connections. The new handshake type is indeed only used at the first connection. Whatever happens wrong in the process (mismatch profile keys fingerprint, mismatched SSL id) will prevent further connections.

The security model of Retroshare connections is based on the fact that the original certificate you get comes from the right person. It can be the SSL id (new type) or the profile public key (old type): the security level is the same. If you trust the SSL id, then any information received after connecting to this Id can be trusted as well, which includes the profile public key. Once the profile key is received, all connections (including to other nodes of the same profile) will be validated by the same profile key.

The new home page therefore displays a much shorter certificate, which happens to be small enough to e.g. fit into a QR-code, since it only contains the node and profile names, the SSL Id and profile fingerprint, and the contact local/external IPs and ports (for clear nodes):

With Tor nodes, the certificate may be a bit longer since the Tor v3 onion address is rather longer (56 bytes) than the PGP fingerprint (20 bytes).

3 - Compatibility with Tor v3

Retroshare v0.6.6 supports Tor v3 keys. The change is backward compatible: new Tor v3 nodes will connect to 0.6.5 nodes without any change, provided that the 0.6.5 node you're connected to uses a version of Tor that supports v3 keys too, which means posterior to v0.3.2.9.

Tor nodes have never been easier to setup: at the node creation time, select "Hidden node over Tor" instead of "Standard node", and fill your profile name and password. Retroshare will automatically create a hidden service for you and configure itself to use it (as soon as Tor is installed in the system - retroshare only looks for a Tor executable). Using Tor has many advantages:

  • Connections through firewalls are extremely reliable and fast since Tor is very hard to filter. A Tor node may therefore be a good way to keep Retroshare working in a heavily filtered network;
  • your IP is hidden to everyone including friend nodes;
  • a lot of features related to clear nodes are not needed (IP Filters, Relay, DHT, UDP, etc) which makes the software lighter and certainly more stable.

Tor v2 keys will automatically deprecate after July 2021. This is not our decision: it depends on Tor stopping to support these keys. Consequently, it is recommended to upgrade your existing Tor v2 node to Tor v3. Fortunately, this is rather easy: just delete (or move away) the directory ~/.retroshare/HID06_[your SSL Id]/hidden_service/. Then start retroshare. It will automatically create a new (v3) service address. Your friends will still accept you when you connect to them (your profile key hasn't changed). They will however not be able to locate you themselves (your Tor address has changed), until they receive your new Tor address either by discovery, or by yourself sending your certificate. This mostly happens to clear nodes for which the only direction of connection is from the clear node to the Tor node. In summary:

  • delete the hidden_service directory and re-launch Retroshare
  • send again your Retroshare certificate (See Home Page) to friend clear nodes

More information: Tor v2 deprecation timeline

4 - Auto-cleaning of unsubscribed channels, forums, boards and circles

All GXS groups (understand e.g. a forum, a channel or even a circle or an identity) now record the last time they are advertised by friends. It is therefore possible, when a group is not subscribed, to safely delete it. The rules are the following:

  • unsubscribed forums, channels, boards are auto-deleted after 60 days if not seen at friend nodes either (meaning friends are not subscribed)
  • subscribing to a group resets the counter

Some services however have specific rules:

  • Identities record the last usage time that depends on how they are used by other services. The People tab comes with a list of usages, which timings correspond to regular sweeps of the databases for signature and consistency checks.
  • Circles have specific auto-subscribe rules to consistently benefit from this auto-cleaning strategy:
  • reminder: circle membership for an identity is based on two necessary conditions: (1) the identity is "invited" by the circle administrator (which is part of the group data), and (2) the identity requests membership (requests are group messages);
  • a circle is only subscribed (meaning propagated to friends) if a membership request from one of your identities is posted to it, which includes also when actively "leaving" a circle after previously being a member, or if you are the administrator of that circle.
  • circle membership requests (or leaving requests) are kept for 1 year. A membership request therefore needs to be renewed after one year.

In the early days of circles (previous releases) it was possible to create huge circles inviting all possible identities, which would automatically propagate everywhere. Thanks to the above rules, this is not possible anymore. Such circles that may already be here will be unsubscribed and disappear from your circle list after 60 days provided that none of your friend nodes request membership (The remaining time is visible in the tooltip over unsubscribed circles as "last seen: XX days ago").

5 - Better notifications in Circles/Channels/Forums/Boards

The previously named "Log" tab is now called "Activity". It still shows a configurable summary of events in the software (new forum messages, connection attempts, etc). We added a few of them especially for Circles:

  • Peer requesting membership or leaving a circle;
  • peer owned by your node being invited or rejected from a circle by the circle admin.

...and Forums: moderators added/removed

These notifications are now available because we added a more accurate description of the changes in group and message data in the GXS internal event handler.

6 - Various GUI tweaks

The list of small changes/improvements in the Qt interface is rather large. You will certainly notice the following incomplete subset:

  • A new tab for identities has been added in Statistics;
  • home page has been improved for more readability and a better compatibility with short certificates;
  • forum pinned posts behavior and look has been improved;
  • messages layout have been improved with spam box filter, attachments box filter and colored tags folders