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.

Forum moderator list

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:

Forum post pinning example.

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.

 

About Cyril

I'm sharing the lead of the RetroShare project with G10H4CK. I've been working on RetroShare for four years now.
This entry was posted in release notes. Bookmark the permalink.

9 Responses to Release notes for v0.6.5

  1. Congratulations on the Retroshare 0.6.5 release, I’m looking forward to the inclusion of Retroshare in the global Tails Debian based plugin run included software applications. A upper connectivity layer that allows 1) Optional Manual Network Interface selection from a drop down menu of those available, example tun0. 2) Optional IP Address to bind to from a drop down menu of those you can chose or a custom entered IP Address, example 10.9.10.1 should be added to Retroshare to further open connectivity on LANS via different local IP’s, CJDNS, VPN’s etc. quickly and easily just for the Retroshare application.

  2. hblast says:

    Hello Cyril, I’m not good in english so I’ll be short. I am really grateful for your (and all team of course) time, work, ideas about RS.
    I would like to contribute with following thinks on my mind:

    1. – all above is based on ver 0.6.4, and I am exciting to try 0.6.5
    2. – when you got an complete alternative communication system, its very disturb to continue using centralized system to serve some basic tasks. I mean on email or similar way to exchange RS key to establish connection. This shall be provided to use some RS addressing like ‘alias(crc32)@retroshare’ something what is light and easy to write on paper or tell over voice call, visit card etc., so when new user get this information and download RS its got all needed what is necessary to connect.
    3. – I’ll tests RS mail in uncommon condition – the message was written when no other user is connected, and then send to distant user (outboxed). After that goes few months of no connection with friend, and finally is connection establish – RS got big problem to send this items, mostly not send at all or send only some of this after “trying and trying”.
    4. – like I say in point “2”, it is great that you have an RS address where you can receive feedback or bug – some of us really have no conventional email to receive key. Your feedback address or field may be incorporated in help tab or so.
    5. – I am very concerned about world migration on 64 bit programs, putting 32 bit in history. Like all on this world, all new things tends to be more and more controlled, or dismissed like “old and bad”. Most of some people have old computer because it is sufficient and fill all his needs, and directly confront to ideologies of hardware/software/trade company to have to be “all up to date” with buying new stuff. I like to recognize this crucial aspect in future our work. Computer have enough power to run absolutely everything with end of about 2010. years, and new and new capitalistic products must (on some way) compensate that facts.
    When you have a rigid ‘end point of your creation’ that meets defined basic, there is no space for developer, only improver over and over.
    6. – I’ll think that be very useful to add some tab, plug-in or place where people can organize exchange (or gift, ask, offer) of his item, goods, or other value, say “exchange area”, nothing complex and easy to use. This is one of basic things of individual needs and so closely attached to base of direct communication. This is not to be conventional trade, because it is on private range of friend to friends.

    Is this have sense to you, I can explained if is somewhat not enough clearly written. This is from me, thank you for your time again.

  3. Is there a version for older MacOs?
    I have Os X 10.11 …
    Thanx!

  4. Alex says:

    What is the latest version of RS that works in Windows XP?

    • hblast says:

      Hello Alex, I test 0.6.5 version on WinXP, and she prompt error about CancelIoEx in kernel32.dll and program end.
      Ver 0.6.5 work good on Win7.

      I guess that develop team should consider “back way develop”: product is better and better if he coverage larger and larger area, compatibilitiy with all past and future version to bring maximum connectivity and funcionality in basic comunication, and less need for resource like less RAM, disk, processor, OS, dependency… so it tend to be faster and robust. I have not seen this type of develop yet, and it might to be challenge and brake-point in this “consumer-needed” world. It il be very nice to work in WinXP, however, this product is step-forward in today “freedom”.

    • hblast says:

      Alex, I test now version 0.6.4 qt4 setup, installed like portable, and it seems to work on WinXP (laptop 256MB RAM, 1.7GHz), or not display any error during (offline) install. Version 0.6.4 qt5 display error CancelIoEx, so it may be from that QT5 reason.
      Win7 require 1GB RAM minimum, huge HDD space 20GB minimum, so old collection of working computer and most famous IBM laptops is with QT5 unfortunately unfunctional.

  5. Al says:

    Congratulations Cyril & Gio. I think you forgot to link API documentation in the post. Maybe you want to edit it. Thanks.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s