Release notes for v0.6.5

Dear users, we’re proud to announce the release of RetroShare 0.6.5. This new version is coming rather late (it was originally planned for Sept.2018) but you’ll see below that it definitely makes up for the extra waiting time!

Distant GXS syncronization

The generic data distribution system that RetroShare uses for distributing forums, links, channels and emails had originally been written to work friend to friend, transmitting data between pairs of subscribed connected users. This makes it quite robust but still requires a full chain of subscribed friends to connect you to the source of some data in so that you get new posts. In version 0.6.5, we introduce an optional distant synchronization of GXS groups (e.g. a single Channel is a GXS group) that allows to sync subscribed groups using authenticated encrypted tunnels. With this technique, people can search, subscribe and synchronize groups that are not subscribed by immediate friend nodes.

This has been enabled in Channels only, as an experimental feature. If it proves useful enough we’ll extend it to forums and potentially all GXS services in the next release.

The new search at the bottom of the channel list sends a query across the network and only reports channels that *are not* already advertised by friends nodes. When a new channel is reported, right click on it and hit “request data” to retrieve the full channel group (which means encryption keys, mainly). If available, it will soon be moved into “Other channels”, from where you can subscribe to it. We may automate this a bit more in the future in order to make this 2-step process simpler, but the current setup helps us diagnose potential problems.

As a side effect, channels synchronize using tunnels only when necessary, which we figure out by looking at whether friend nodes already supply information about a particular channel or not.  This does not totally prevent “isolated islands”, and we may improve this heuristic a little bit in the future.

Forum moderation

In this release, forums can have moderators, who are allowed to edit anybody’s post. Moderators are set by the owner (meaning the creator) of the forum, as part of the forum group data that is signed by the admin key of the forum owner.

Adding/removing moderators to a forum.

Posts still cannot be deleted. The reason for this is that because posts are duplicated on all subscribers, it would give a false sense of security to let someone believe that he/she actually deleted a given post.

Post can also be pinned by the forum administrator, which makes them stay on top no matter which sorting method is chosen, with a colored background. Only the administrator has the right to do this, which allows forums without moderators to have pinned posts. It also simplifies a lot the security of it since the list of pinned posts is part of the forum group data that is signed by the administrator:

Pinned posts stay on the top no matter what.

Note: In order to edit a pinned post, you need to “un-pin” it first. We’ll fix that later, and it is a side effect of how post versioning is implemented below.

Forum model

We implemented a new QAbstractItemModel for forums, the beauty of which can only be seen by reading the code (sorry). Still, it makes the forum loading much faster and more memory efficient. Because this is new code and is rather complex, you may find errors. Please report them back to the dev team.

Tor only and clear-net versions merged

In version 0.6.4 we used to provide 2 different versions: one working on the clear-net and one working over Tor. Both versions are now merged in the same executable. When creating a new certificate/node the user can choose the node type as Standard node or Hidden node. A third option allows to manually configure Tor/I2P to allow all the combinations previously possible:

When a hidden node is created or started, RetroShare will look for Tor (which it should find if properly installed on your system) and automatically configure it to run a hidden service which will be used by your friends to connect to you. It will complain immediately if something’s not working in the configuration of Tor.

Of course hidden nodes can still talk to non-hidden nodes, but connections only happen from the non-hidden node which has Tor proxy configured. This is usually sufficient, and this way no Tor exit nodes are involved whatsoever. We also made sure that the discovery system *never* sends IP addresses to Tor nodes (they don’t need IP addresses but could potentially leak them between friends). The UI in Tor-only mode is overall much simpler, since UDP, Relays, DHT, Nat punching code, IPs filtering, etc. are irrelevant in this setup. As such, Tor nodes offer a much better level of connectivity.

Remember that Retroshare over Tor is a very powerful tool. Use it wisely!

Automated JSON API generation

The experience of rapidly developing a Retroshare based Android chat app with Qml plus the old libresapi convinced us that exposing a complete JSON API would be strategic for the growth of Retroshare ecosystem. Still we realized that libresapi wasn’t capable of supporting that growth because for every function of the Retroshare C++ API we wanted to expose trough it we had to manually write wrappers for it, which is a very boring and error prone job. This caused libresapi to be always severely behind libretroshare in terms of functionalities. This problem motivated us to investigate for a better approach, and led us to a radical change on how we expose the JSON API.

The new approach uses restbed as a HTTP framework and automatically generates JSON API stubs directly from Retroshare C++ API code and documentation, with the help of doxygen capability to parse the code and outputting XML description of it integrated with the inline documentation. This way any properly documented method from Retroshare C++ is now available without extra work trough the JSON API. Another benefit is that if we change a method or add a new one the change apply to JSON API too without need of extra work.

This is very important for developers who would like to develop decentralized applications without being a distributed networks or a C++ god. Now any JavaScript, or python or Lua or whatever programming language script kiddie can harness the power of RetroShare to develop it’s own custom decentralized app (and some are already doing it). We also started upgrading the existing Web interface with the new API, and hope for Google Summer of Code to make finish it during 2019.

We’re also presenting the JSON API this year at FOSDEM’2019.

IPv6 support

The long time efforts to bring IPv6 support to RetroShare have finally brought their fruits. The IPv6 support is finally stable and merged in the official version which we even managed to do without a code refactor chain reaction, and without breaking retro-compatibility with Retroshare 0.6.4.

Most connection problems in F2F networks are due to NAT being practically omnipresent in the IPv4 Internet because of address space exhaustion, punching a connection trough a NAT is a time consuming and not always a reliable task, as result developers and user experience are not always as smooth as one would desire. IPv6 instead offers plenty of addresses so every device cat get at least a public address without a NAT interfering with your connections, so connecting to your friend nodes is almost instantaneous and very reliable when IPv6 is available. If your Internet provider is IPv6 ready you will benefit of seamless direct connection to all your IPv6 enabled friends nodes, otherwise we suggest to look for an IPv6 enabled internet provider to improve your Internet participation.

Direct node-to-node chat+mail is now an option

As we’re planning to re-design the chat system entirely, we need to get rid of the double chat system (between nodes and between identities in People) that is currently very confusing to new users. We added an option to allow to hide the interactions between nodes (chat and messages) and the broadcast system between nodes (compile with CONFIG=no_direct_chat), which leaves only chat and messages between identities.

However, in order to help some users with this abrupt transition, two new features improve a lot the distribution and visibility of your non anonymous identities:

1.  Your own signed identities are automatically advertised to friend nodes using discovery. When friend nodes do not “know” them they will request them;
2. RetroShare allows you to automatically add identities owned by friend nodes to your contact list.

The combination of these two features makes Mail and Chat much easier for newcomers as they can immediately reach identities hosted at neighbor nodes.

Various bugs fixed

As usual, we spent days fixing lots of bugs (and probably introducing new ones as well), among which:

• we fixed the display of single chunk transfers was wrong;
• the display of updates in forums and circles was also fixed;
• files are not anymore hashed while being modified (e.g. written). This is quite easy to achieve by looking at last modification time stamp and prevents files to get the wrong hash;
• file transfer now aggressively re-requests pending chunks at the end of transfers, which prevents slow sources that have been set to a given chunk to slow down the termination of the transfer. Now the last chunks may be received twice, but they come much faster.
• we fixed the nefarious crash in UDP connection with OpenSSL 1.1+

What’s next?

Now that we have a API to talk to libretroshare, it is time to get into serious business. There’s a bunch of very interesting possibilities of what to do with it, including a social network that would run in a browser while talking to the RetroShare background application. 

2019 will also be the year where RetroShare gets into Debian which is a condition to get in Tails as well. This is the next task we’ll work on after this release is published.

Summary

A nice release, which we hope will bring you security, privacy and more usability.  The JSON API and IPv6 integration are the work of G10h4ck.  We also would like to thanks all contributors to this year’s huge set of pull requests (Phenom, Sehraf, hubernd, RetroPooh, Chelovechisko, Zapek, San-Josep) and tests and feedback (Ghibli, ASmith, Jolavillette).

We provide builds for MacOS, Windows and most Linux distributions. More information about this on our Downloads page!

Cyril & Gio.

 

Advertisement