Tag: Retroshare

Project Introduction

RetroShare, the encrypted peer-to-peer social networking system, has a web interface which makes it easier to use from multiple devices without running multiple nodes. The web interface works, but it is in need of improvements in its API, appearance, and user friendliness.

The web interface is particularly important to those who wish to use RetroShare heedlessly on a server, so they especially will benefit from improvements to it.

This project will mainly involve building on and redesigning the web interface API, libresapi.

Who I am

My name is Kevin Froman, I am a 19 year old American computer science student. I am passionate about online privacy, information security, and decentralized networking. I mainly have worked in web and mobile development, however I have some experience in standard desktop development as well.

More info about me, as well as a mirror of blog posts written here, is available at my website.

Maintain existing supported RetroShare features in the UI (do not lose any in migration)

Add authentication (likely sha256-HMAC) to the interface to protect against certain browser attacks

Re-designing the front end, both style and functionality, likely using VueJS.

I am not a web designer, however I can definitely improve the appearance

Bonus goals include:

Adding more RetroShare features to the UI (the features the web UI supports is incomplete)

Making the web interface easier to setup on headless servers

External HTTP API mechanism with CORS (Cross Origin Resource Sharing)

The web interface’s appearance is currently not a work of art.

Bonding Period Experiences

Leading up to and during the Community Bonding Period, I got to know my mentors Cyril and Gio better and explored the RetroShare code base, especially libretroshare and libresapi. We discussed details about the project and the way project goals will be implemented.

As a way to dive into RetroShare, I worked on a backup system for RetroShare profile data to XML files. Unfortunately, I did not get a lot done on this, mainly do to final exams and projects for my classes which overlapped with most of the bonding period, but also due to roadblocks I ran into involving my development environment, personal issues, and less than optimal time management on my part. I felt I needed to spend time looking at libresapi and studying the code base in general, in order to be better prepared for the main coding period. The issues I had have been resolved.

At first, I found diving into this a large, multi-author code base intimidating, but I learned more of its structure and feel more confident for the main project.

First Goal/Milestone

My first project milestone is to fully analyze libresapi and to look for any code that should be kept/refactored and to finalize exact details of the new API system (white-boarding, prototyping, writing unittests). If all goes as planned, the first milestone will be done before May 28th.

I expect this goal to be accomplished early, so I will likely also be starting on the second milestone during this time, which is to get the base API system setup (both for the front-end and back-end).

I look forward to a summer working on RetroShare, and I believe my project will be a valuable contribution.

Finally we arrive at the end of the summer and also at this third final evaluation of GSoC!
I’m proud I have participated to this edition of GSoC and I am thankful for this opportunity.

This past month I did lot of new work and lot of interesting improvements.

One of the funniest and visible things are the implementation of the 8biticon library that provides a reliable avatar face generated using GXS id as input, it is reliable in the sense that having the same GXS id as input will generate always the same avatar.

The nice thing about this is that it can be used as an user friendly way to verify identities, the user doesn’t need anymore to check long fingerprints but she can do a quick verification just by looking at the generated face.

Another interesting thing I have implemented is sending little files and images via chat using data URL. This works encoding a file to base64 and send it with a header specifying the mime type. The maximum file size is 60KB, and for images, if it’s bigger than that or if it’s size is more than 160×160 pixel, the program resizes it to fit.

This branch results very interesting for me because it uses all the things that I learned this summer: call C++ code from QML, call Android Java code from C++ interact with Android OS, create custom QML components from C++ code…

Of course, a big part of work has been to find and fix bugs, on Android and on desktop. At the moment the last commit has little known bugs that I’m going to solve as soon as possible.

One of this bugs causes program crash on some Android devices when send or receive an emoji. This happen because I implement an alternative emoji font if no native compatible emoji font is found. On Android, the Android Emoji font is who provides the typography of emojis, but in some devices its not shown. So I decided to integrate the OpenSansEmoji project. That way, when the program doesn’t detect a compatible emoji font, it uses the OpenSansEmoji.

But the implementation of that is not working as good as expected and causes the crash mentioned above.

Another typical work has been to improve the UI aesthetics in little things: correct a height in one place, change the color somewhere else, draw a line separating the contacts. I create a custom button component with animation and the possibility to attach to them an icon. This is done thinking about to also centralize the application style sheets.

And thinking about the end user, I tried to improve how the user share or import the nodes identities. I put a shortcut on the menu to share identity, and also refactor a little bit the import/export trusted nodes view, making an informative popup that shows you a little bit of information about each option.

Also I have done some little attempt to implement key exchange using the device sound card using libquiet available in C, Java, JavaScript and more languages.

This is a very interesting functionality that would improve the key exchange process and make it user friendly.

The functionality is not implemented yet as I believe it would take more time then the GSoC as it seemed more difficult than we thought initially, but I would like to continue working on this topic in the future.

In latest days I have been working with my mentors to do the final polishing and integrate most of the code in RetroShare official repository master branch, most of the code have already been merged as you can see in this commit e06bffdb by one of my mentors.

This month of coding on RetroShare has been very productive again, with many user experience improvements and bug fixes to the mobile app.

The user can now pick it’s own avatar in an integrated manner. On Android when the user attempt to change her avatar she is directly prompted to select between the available image sources like the gallery or the camera as you can see in the screenshot.

To implement it I had to write some part of the code using Android Java API to create an intent with a chooser, and then handle the answer. After that, using Qt the image is encoded inPNG format and then

to Base64 to handle it to the retroshare JSON API.

Moreover avatars are now cached so the can now be showed the avatars in the contacts view without high resource consumption.

Another improvement is the Unicode emoji input support, adapted from the QMLemoji project,that uses the default system unicode icons.

This enable the user to use emojis whitout heavy and tricky text substitution and extra image bundling.

For platforms where Unicode emoji are not supported yet we plan to just ship a font with Unicode emoji support so the user experience will be coherent accross platforms.

Some more examples of improvements happened this month: chat bubbles now recognizes links and if clicked they are handled to the system with that will open the proper application depending on the URI schema, buttons are now styled and supports icons, importing and exporting of trusted nodes public key is more integratend with the systemand more intuitive.

In a separated branch on my repository I have implemented showing to the user the tunnel connection status, but after talking with my mentors, we decided to notmerge it yet at least until the new chat system backend is ready because having this now would provide partial information that may confuse the user in some cases.

As always you can get/comment/contribute to the code and followe the discussions on my public Gitlab repo.

The big part of the work has been focused into the program usability and aesthetics.

To report just some of the improvements done in this area the chat messagesare nowwrapped in beautyful bubbles, the contacts view has been refactored to show more info like the last message or if there is unread messages, the node details view has been redesigned to be more appealing, the contact details view show the avatar, and a more appealing menu is in progress (see screenshots at the end of the post).

For this implementation I needed to learn how to work with qml, how the RetroShareAPI works, to make calls and process the JSON API answers.

Also I have managed tocreate a simple chat informations cache, to store useful data that I use in the views without asking them via the API again and again. Another part of work done is about how to interact with the Android system. For example sending notifications from the QML application to the Android system, or getting the internet connection status and details from the Android system.

The most difficultpart has been grasping, how to call QML code from Android Java and vice versa. I have been learning JNI (Java Native Interface) and Qt on Android multithreading model now I am capable to call Java code from Qml and vice versa. In one direction you call java functions form QML, always througth C++, in the other direction, you call a QML functions from Java, also via C++. The trickiness is not only limited to the fact that the comunication must be intermediated by C++, the fact that the QML code and the Java code run in indipendent threads is to be taken in account too, hopefully Qt provide some functions that make thing seamless in most of the cases.

Finally, I have achieved to createAndroid notifications and get the connection statuson Android devices. This second will be very usefull to decide how the core should behave, for example, if we have only 3G connection, is probably better to not forward the Retroshare GXS tunels and save your download quota. Instead, if you have a fast wifi connection, the Retroshare core can work at full capacity and contribute to Retroshare network.

In the following month, I’m going to work testing the usability improvements in Android device because this branches have been developed and tested mostly in desktop enviorment. This is posible thanks to the Qt multiplatform system: running the Android service on desktop to start the Retroshare core and then run the QML-app is almost the same as doing it on a smartphone.

Another direction of work for next period is to improve the comunication with the Android system. Taking advantage of the posibility to call Android Java code we can improve the app behavior in many cases (I have explained just a few of them above).

Hello, my name is Stefan Cokovski and I’m an undergraduate student at the Faculty of Computer Science and Engineering, Saints Cyril and Methodius University of Skopje. My field is Computer Networks Technologies.

Firstly, I would like to thank Google and the team responsible for organizing GSoC. GSoC is a wonderful opportunity for many students all over the world to gain some real experience working on open-source projects, but also to expand their network with new friends and potential colleagues. I would also like to thank Freifunk (for taking many projects related with computer networks under their wing and for also supporting the project RetroShare) and the lead developers (and my mentors) of RetroShare for being here for me during this community bonding period, answering my questions and helping me to improve my ideas. I’m sure they will continue to help me during the later parts of GSoC.

Before I tell you what my project involves, I would like to introduce you to what exactly RetroShare is and maybe convince you to start using it (if you don’t use it already) and possibly join the development process.

RetroShare is a decentralized, private and secure commmunication and sharing platform which provides many interesting features like file sharing, chat, messages, forums and channels. RetroShare is a free and open-source project, completely free of any costs, ads and terms of service. RetroShare is available on several operating systems, including various GNU/Linux distributions, FreeBSD, Microsoft Windows and Mac OS X.

During Google Summer of Code i did these things:– learn what users expect from a social network. Figure out who should receive which messages.– map social network functions on the existing Retroshare General Exchange System– build a backend with basic features– build a frontend with basic features– started a new programming interface on top of libretroshare: a JSON over http interface

The Secushare homepage says: “RetroShare should provide more social functionality” Indeed! Every country is spying on their citizens. Storage, computing power and bandwidth became cheap. These are good conditions to build a distributed social network. The first step was already started a while ago with the General Exchange System for Retroshare v0.6. This project is the second step in this direction. One thing is missing: a release for normal users.

The backend and frontend made during GSoC can display a wall with avatar image and profile text. It is possible to create posts and reference them on walls. Posts can be commented. Read more details in the previous blog post. Still it is not suitable for daily use. There was not enough time to implement a scalable user interface architecture. The web interface can’t handle more than 100 posts, because pagination is missing. Whats more the UI is filled iterative. This causes many updates to the html tree with high cpu load. It would be better to send all information to the browser in one piece. The browser would then only have to update the HTML tree once. The design and layout should be improved to highlight the content and to get the date label out the way. (See the this screenshot.)

Future

Wt is nice because it allows to make a web interface without touching HTML JavaScript and CSS. But this is only the half truth. There where issues:– completely destroyed layout by setting the image size– menu bar was horizontal instead of vertical, this required to manual set a style class from C++– WTimer stops working. I had to build my own server side timer

These issues where solvable. A real pain with Wt is the layout and UI design testing. You first have to go through the complete compile and start cycle to see changes. What if you missed a closing tag in a HTML template? You have to recompile and restart. Now i saw that with real web technologies you can see a live preview while you type. I think when doing layout and design it is important to immediately see the result. This is not possible with Wt. Conclusion: you can build a web interface with C++. But hard coding CSS class names and embedding HTML snippets in C++ is a pain that should be avoided.

On the other hand there exist advanced tools and frameworks for web development. AngularJS is a very nice JavaScript library. It offers data binding from JavaScript to HTML: you update a JavaScript object, and Angular updates the HTML. JavaScript objects are more flexible than C++ objects. You can even make a JavaScript object out of a JSON file. Angular makes handling of button clicks easy. AngularJS makes Bootstrap offers a set of widgets with HTML example code and style sheets. Now i want to use other web frameworks instead of Wt.

I did not know about these web technologies when starting the project. This is some sort of a chicken-egg problem: Retroshare does not have web developers, because it doesn’t have a web interface. And there will be no web interface until a web developer can show how it can be done. Gladly there is now a web developer who can teach me how to make a web interface.

The new idea: make a web interface using web technologies

The next goal is to make a clean and easy to use JSON over HTTP api for Retroshare. Then web developers are free to make a nice web interface using their favorite frameworks. This api is not only useful for web interfaces, but also for scripting. You could then send a chat message from a shell script using curl:

What i will do nowI will do more research for a JSON over HTTP interface for Retroshare and rssocialnet. If this stays a good idea i want to implements it. Maybe i will try to start a new web interface. But i hope someone else is faster than me. I prefer to work on the rssocialnet backend and libretroshare. Whats more a web interface is a perfect place for new contributors. If i would make a clearly documented JSON over HTTP api, then a web developer would not need C++ knowledge or experience with libretroshare.

A dream is to bring Retroshare to Android. This is possible, but we have to make a new touch-friendly user interface and we have to optimize Retroshare to make it more battery friendly. I currently see two ways to build a GUI for Android: with QML/QtQuick or HTML based with the Ionic Framework. There is already a QML prototype.

To get rssocialnet ready for daily use, i need your help. Unfortunately I’m again in a research/planning phase. This means I’m not sure how the JSON over HTTP interface will look at the end. It also means if you tell me “i want to help coding”, i have to disappoint you because i don’t know what we have to code and how to code it. Anyway, here are some things you can think about:

– which features are important for a social network? read some ideas– can you make a better gui mockup than me?– which frontend technologie should be used? QML/QtQuick or Bootstrap and AngularJS?– what are the requirements for a first release?– how can you use your skills to help?

Thank you Freifunk and other mesh network communities for donating one GSoC slot to Retroshare. This was a good decision, it made it possible to start a mesh friendly social network application.

Content is obviously the most important element of a social network. Currently only support for plain text is implemented. The content can have an author, but this is not required.

Future: It would be nice to have support for images. This is very easy on the backend side, but it needs a frontend which scales the image to fit on the screen. With Retroshares file transfer capabilities it would also be possible to publish large files like audio and video files. It would be nice to restrict access to content to a set of people. Retroshare is prepared for this and it only needs small changes in the social network backend. Of course this requires a user interface to sort people into circles and to select circles.

Content alone is useless without a place where it gets displayed. As explained in a previous blog post, every piece of content is stored for its own. To make content visible it has to get referenced on a wall. This happens automatically on the own wall when creating a new post. It also gets triggered by clicking the share button. A reference always has an author.

Future: maybe allow to reference content from other services. For example if Retroshare gets a Photo Share service, allow to reference a picture or photo album on the wall.

A Wall is a place where a profile text, an avatar image and references to content are stored. A user subscribes to another user to download all posts referenced on the wall. The wall owner and others can reference content on a wall.

All new posts are collected and displayed in the news feed. A news feed shows the new content, the comments and how others interact with the content. Who commented this post? Who shared this post? Currently the news feed displays posts in the order in which they where received.

Future: it is probably desired to have a more advanced logic to sort news feed entries. Imagine a user comes online after a week and gets bombed by hundred new posts. It would be possible to sort news in two dimensions: topics and rating. Example: have one tab for content from close friends, and one tab for other content. Then calculate a score to display more important content at the top. This requires a bit of backend work, but it is doable.

Users can interact with content in two different ways: they can comment it, and they can share it. Sharing creates a reference to the content on the own wall, and thus forwards the content to friends. Comments are stored with the content, so everyone who received the content will also receive the comments.

Future: one can think of other ways to interact with content. Examples are like, bookmark, vote and hide. In general these interactions are each a form of tagging. For the backend it does not make a difference if content is tagged with “GSoC14” or “like” or 3.1415. This is more a matter on the frontend side: which meaning does the tag have for the user? How does the frontend show different tags? (star, heart, thumbs up, plus sign, text, …) How can the user filter posts with specific tags?

There has to be an entry point to let the user see the people around him. If the user recognizes a known person he might want to subscribe to this person. For now there is a widget to display all identities with their name and avatar image. Of course later this list should get filtered to fit on the screen. Retroshare circles could be used to make friends lists accessible to friends. This would allow automatic circle intersection to search for people the user probably knows.

In the last post i wrote about the decentralized structure of Retroshare. I said: similar features to Facebook are also possible in a decentralized manner. Now let’s have a closer look at those features.

Communication tools have the purpose to take a piece of information and transmit it. The question is who should receive it, when will it be received and to which next hop should the information be send.

Very simple forms of communcation are one to one messages. We have a clearly defined receiver which can be adresse by a RSA public key. This is very simple if we are directly connected to the receiver. If the receiver is not a direct neigbor, then Retroshare uses it’s distant tunnels. Current distant chat and distant messages only work when sender and receiver are online at the same time. Retroshare v0.6 will cache messages on neighbor nodes to deliver them when the receiver is online.

Retroshare can also do many to many communication. The Chatlobbies are for real time communication. If you don’t receive the message a few minutes after it was send you will never receive it. Messages are send to all neighbors in the chatlobby. RS keeps messages for a few minutes to prevent echos. Forums and channels offer persistant messages. This means messages are kept for a year in forums and a month in channels. The messages are not targeted at a person, but they belong to a context. This context is a chatlobby or a forum/channel. Users have to subscribe to the context.

Every message is bound to the context. It appears only at one place. In Retroshare forums and channels the context is a topic like “Developer’s Discussion” or “RetroShare Windows builds by Thunder”. In the social network plugin the posts are decoupled from a context. The context only stores a reference to the post. This allows posts to appear at different places. For example: a post can appear on the walls of user A and user B. And if i see the post and like it, i can forward it to my wall. Forwarding of specific posts only, increases the quality of the received content.

With forums and channels you first have to subscribe to them. Retroshare will then download the posts in it. The social network plugin automatically downloads the posts your friends like. And if your friends like it, then the probability is high that you also like it.

While forums are about a topic, a social network wall is about the user. It is a personal place where you can leave message for your friends, and your friends can leave messages for you. Still your are not limited to own content. If you want to share existing posts with your friends, just put it onto your wall.

Scope of the GSoC projectThe goal of the GSoC project is to make a basic wall service. This includes the backend for message processing and the user interface. Chat and private messages are not planned for GSoC. But this is something that is very easy to add later.

Internally the social network plugin is based on the new Retroshare General Exchange System(GXS). GXS has two basic data structures: gxs-groups and gxs-messages. A gxs-message belongs to a gxs-group. If a gxs-group is marked as subscribed, then all messages in this group are downloaded. In the gxs-forums this mechanism is clearly visible to the user: gxs-groups are downloaded automatically, but the user has to subscribe to download the contained gxs-messages. The posts in the social network plugin should be independent. This requires that every root-post has its own gxs-group. The wall services automatically subscribes to interesting gxs-groups. Gxs-groups can be interesting because:– the posts appears on a wall of a friend– the user follows the author of the post or the user is friend with the author– a friend made a comment on this post

So the interesting content is not defined by a forum title, but by the way friends interact with it.

Commercial social networks like Facebook have opposite properties: they are centralized and all data is visible to one company. The good news is: similar features to Facebook are also possible in a decentralized manner. The plan is to build this as a plugin for Retroshare. Always having decentralisation and privacy in mind, while offering a very similar interface with a similar feature set.

Figure 2: Sketch of the user interface.

Unlike other peer-to-peer software, Retroshare connects only to a set of trusted friends. This has some practical advantages, for example you don’t have to fear malicious peers. It still scales nicely, because friends tend to gather the same type of data.But often you want to reach content that was not created by your direct friends. Or you want to contact someone because you are not friends yet. For this Retroshare offers another layer which i call the service layer. At first a service can send messages to direct neighbors only. But if it receives a data packet it can also forward it to a friend. This is how you can reach friends of friends. This philosophy has been applied to multiple information sharing algorithms within Retroshare. Read more about them in the following articles on the Retroshare team blog: Retroshare Forums, Distributed chat(a.k.a. Chat Lobbies), RetroShare’s anonymous routing model and Distant chat and messaging, using generic tunnels.

Figure 3: Retroshare forwards messages from friend to friend

On the neighbor Layer, you have to add your friends keys to your keyring by hand. But this is not a problem in practice, because the number of direct friends is small and Retroshare offers various options to get to know neighbor nodes one hop away. On the service layer you want to have the public keys of people many hops away. In Retroshare v0.6 there is a identity exchange system, which downloads public keys at the same time it receives a post from a unknown author. The identity exchange system can also work decoupled from the neighbor layer. This allows us to have pseudonymous identities. These identities can be used for different kinds of services like chat, mail, forums and the new social network plugin.

Retroshare is a steadily grown project, so the developers gained a lot of experience. Out of this they developed new systems to distribute messages in a Retroshare network (short name is gxs for General Exchange System). So all the complex code for doing the signing, verification, encryption and decryption of data is already done and avaliable. During the Summer of Code i will wrap this complex stuff in a nice webbased user interface. The RSWebUI Plugin is a starting point. It uses Wt, which is a library to create a webinterface with C++, without writing own code in web languages. You can watch the development in the git repository.

Read the next blog post to learn what features the social network plugin will have and how it will work in details.

Download Retroshare: http://retroshare.org

About me: i study electrical engineering. I first started programming to control hardware. I came to Retroshare because i wanted to chat securely without depending on a server. Then i started to dream about what else would be possible with a secured connection. So i started reading the code. Today i have enaugh knowlegde to contribute.