 Hello everyone. I'm really happy to see you here this morning. I'll talk about RetroShade. It's a decentralized platform. In RetroShade we have many things implemented, but this is decentralized in censorship and spam resistant in a way that still guarantee plurality. It's both anonymous and authenticated when you need one thing or the other. It's full of crypto inside, so probably later you'll have a lot of questions for which service what kind of encryption it uses. It keeps working even if the internet breaks. For example, if you are in an isolated part of Amazonia, you could use RetroShade to communicate between different tribes, not that far away one from the other, but you could. RetroShade is a friend-to-friend network, so basically this is the local view that are not as of the network. It's basically him, his friends, and if his friends give access to the friends of friends. Still it can communicate also with people that doesn't know where they are located in the network, so you can reach any participant of the network. That's done through different mechanisms. One of them is start-to-routing, so when you try to establish communication with someone that is far away from you, the information gets opened from node to node up to the destination node. The node in the middle doesn't know who is the origin of the message and doesn't know who is the actual destination and doesn't know the content of the destination. They just know the last op before them and the first op after them. It's suitable to transfer any kind of content, being it lightweight, like text messages, or EVAs file, or whatever. Another system to expand the communication beyond the trusted friends circle is the general exchange system. It's an asynchronous information propagation system, so you can propagate information toward nodes that are not connected at the same time with you in the network, benefiting from the friend-to-friend network. If there is just one friend of you online, that information will be propagated to that friend, and then you, for example, go offline because your electricity is finished, and that friend will propagate that information to the next one, and so on. And as this mechanism is redundant and provides storage, it's not very suitable for every payload. So, for example, if you would transfer a time series of sensor data for gigabyte, GXS is not the right tool, this is the turtle routing, but you could use this system to inform the other that data is available at your node, for example. Another thing that we recently added is deep search, that through taking advantage of SAPI and Search Engine, every RetroShare node index is metadata content, so when you search on the RetroShare network, the search men can investigate inside the content. Of course, it's anonymous, it's address-centralized, and so on. So, we have this long-standing QT GUI, you probably saw this some time ago, if you already used. RetroShare is an example of file search. There is no server who indexed the file. It's every node indexes own files, and when a search request is made, every node answers with the result if they have some, otherwise they don't. And this is a service that we call Channels. It's used to publish organized content through a generalized change system. So, for example, you can see those videos are Creative Commons, and they are sorted because they are a series. So, you can access the whole series of those videos with the description, a preview, and then you can download them or stream them through the turtle routing. So, from the software architecture point of views, RetroShare is cross-platform as independent core and user interface. It's extensible through C++, and they offer an API. It's extensible through JSON API, extensible with runtime loadable plugins. So, for example, you can prepare your .so plugin and load it at runtime if you need to extend even more RetroShare. And that's zero cost automatic serialization and the serialization framework. It means that when you define a new data type, it's very easy to make the data type transmittable over network or storeable or visible to the JSON API. And this is the architecture of the JSON API. So, from one side, you have RetroShare service or also the RetroShare GUI SuperTit, but let's use RetroShare service. Inside it, it has a use LibretroShare and Restbed, and the C++ API is exposed to HTTP to, for example, another app that want to use the decentralization and cryptographic features of RetroShare that are already implemented to expose a new kind of service. So, the C++ and the JSON API are always coherent because the JSON API is generated from, starting from the C++ API. So, you will never, the C++ API and JSON API will be always feature pair. You will not be penalized to be using JSON API instead of C++. And also the types of data you see in C++ are the same in JSON because of our automatic serialization system. They are directly converted to JSON objects. And the other advantage is that we write just one documentation and it's valid for the C++ API, JSON API, or whatever language you want to use. So, what happened? This is a method from the C++ API in the class Login Helper. We have these methods getLocation. This is a method to return all your available profile on the nodes. As you can see, the return type is void, but it takes as a parameter a vector of locations. And in the documentation of the method, there is a description. It's flagged as exported on JSON API. And also you can see there is the param location is flagged as be as an output parameter. So, you don't need to provide that parameter when you call that method, but that parameter will be used to give you the output. And that is a pointer to the global instance of that class as Login Helper. So, as you can see that the type of the parameter is a vector of locations. Okay? So, let's explore this type. The type location is defined like that. The struct location is it inherits from a RAS serializable and inside of those members as location ID, as PGP ID, location name and PGP name. And then in this method that's called serial process, those members are registered for serialization. It means that those members will be 100% accessible from JSON and also from binary and so on and are sendable over network and so on. So, what happens if we want to access that method from the JSON API? For example, from the shell. So, there is the API where the API is listening that is on our machine. And then with a plain call, we just call the method. It's a RAS Login Helper and get location. And what JQ is just to pretty print the JSON output but you can avoid that if you want. And this is the output. As you can see, we get the array of locations. And inside the array, there is a location that has an ID, a PGP ID, a location name and a PGP name. So, your experience using the JSON API is completely coherent with the experience of a developer using the C++ API. So, the API, of course, is authenticated otherwise any program running on your computer or your phone that is more easy to have fishy things installed could access the API and store your private data. So, most of the calls of the API are authenticated and as you see, you have an API token to access it. And again, you can pass parameter through again with car. You just pass the parameter formatted in JSON. You are passing, for example, we are asking to the API to get an invite for a friend, to invite a friend. And we are passing the ID of the location of the invite through the JSON string. And then just call the method, RAS peers, get retro-shared invite. And this is the output. We just get this big string that is just a base of 64 invitation. So, as you know, JSON and HTTP are pretty well supported on almost any decent language nowadays. So, you can do very similar thing from Python. You can do it from JavaScript on a web page. That's an extract from our experimental web interface for retro-shared. As you can see here, this is the call to the JSON API. It's just a JSON API request. You're the part of the method. And here we are passing the JSON for the parameter we are passing to the method. And so, you can do almost with same easiness from any language. This is always HTTP and JSON. And it's well documented. It is very important. So, this is an example of a chat application, an experimental chat application developed of using retro-shared JSON API for Android. Those little faces are a very easy way to have an approximative way of verifying the fingerprint of the user. Very user-friendly also for people that have no idea of cryptographic signature and so on. They can just tell to themselves the color they see in their face and they almost verified their fingerprint. This is a new app that's called El Repoio, El Repo.io, that uses JSON API to create a service to share culture and curate and store and preserve culture. It's mainly used in places where there is not very good internet connection so it takes advantage of community networks. When it's possible, retro-shared always use the local connection instead of using internet. By local, I don't mean just your Wi-Fi and your own. If you participate in a community network like Freyfunk or GiffyNet or whatever, all the nodes reachable inside the community network that may be all the nodes of your city and so on keep being reachable inside retro-shared. It doesn't need DNS and so on. If someone took a picture of the lunar eclipse in January and shared it on the Repoio and someone also had this picture of this spider and this is another example usage of El Repoio that is an app that uses retro-shared JSON API. So, retro-shared is a free software for a free society. You are welcome to contribute even on your spare time or you can apply for some grants to work on it. For example, through NLNET like we did on Summer of Code and we will be happy to review your pull request and accept it or suggest modification if they are needed. And thanks. If you have questions, you're welcome. Of course, retro-shared may be used also through Tor and E2P and other anonymized networks. Siri lives from retro-shared project too. Welcome. I kindly ask everyone to remain seated during the questions that would be super kind of you. The gentleman over there has the mic for the questions. Hi. The question is how do you manage to make two nodes to talk to each other when they are netted? I mean, when the two machines are behind a nut, how do you do that? Okay. The question was how do you manage to have a connection to a person that is behind a nut? So, retro-shared implement various nut hole punching strategies. So, it's always trying to punch a hole through the nuts. So, you may even have a direct connection to someone behind a nut. But if it's not the case, it uses the friend-to-friend network to route through to get to the other person that is behind a nut. So, fully, you always get some trusted node that is not behind a nut and that will be instant connection or otherwise you will have this nut hole punching process. And also, retro-shared support connection through Tor that has very good mechanism to punch through nuts. And also, it supports IPv6 that doesn't have all those problem with nuts because it usually doesn't, it's not provided through nut but through public IPs. So, is the JSON API available for androids or does it use C++ and JNI or other interfaces? So, the JSON API is available on Android. So, those applications that you sold were screenshot of Android phones and there is the retro-shared service running on Android and the app running on Android too. So, the service is C++ but it's compiled to native code and there is an Android package that you install and then you can, whatever app that is token authorized on the retro-shared service can use the JSON API. Okay, this is me again. The question is how do you manage if, no, do you have the possibilities to have a multi-device? Can you repeat? I didn't understand. Do you have the abilities to have a multi-device? Do you understand what you're saying? Is it possible to have multiple devices? Yeah, you can have multiple devices. They can share usually the PGP key so your friend can recognize you but they have different SSL key. So, they are actually different nodes but they are capable of authenticated at the same profile. So, you keep your friends? Yeah, you keep your friends actually, yeah, across devices. Even if you lost a device, you can rebuild all the content and the network if you add a new device after losing one. Well, if you lose the device, you're... Repeat the question. Ah, sorry. So, they said if you lose your device, you can rebuild your network. Of course, you can do it. We suggest to keep back up of your profile but in case, well, the PGP is protected with a password so you can use a good password but in case you are concerned and if you are a bit paranoid we suggest to create... If you lose your device, someone may try to brute force your PGP key and take it. So, in that case, depending on your security needs you could decide to restore it from a backup or create a new profile and tell to your friend that your profile changed. And you have your content back? No. If you do the backup, yes. If not, you don't have your content back. Well, you can subscribe to forums and the things that you were participating before and your friends will pass you again the content but it depends on the service. For your file, probably you have to look for them again and so on. Any more questions? Can you just speak up because otherwise... Yeah. In the case that you lose your key, how can you... Is there any way to make sure that you revoke the key so that it cannot be used maliciously? Repeat the question. Okay, so in case you lose your key there is some way to ensure that your key is not used maliciously. Well, it's a PGP key so you can revoke it so you could publish the revocation but then it's up to your friend to update the PGP key database and know that key is revocated. Otherwise, it's like any cryptographic key could continue to be used. Yeah, you can publish. It's a file, actually. Sorry? In a way that it's automatic to the client. No, it's not implemented. But it's a good integration. Yeah, it could be implemented, yes. Another question? Do we have time? What more over there? If you have multiple devices, is it possible to sync them? For example, if someone steals one of your devices can you sync the data from that device to your... It would be possible. Question? Could you repeat the question? Sorry, so if you have multiple devices it's possible to synchronize the data between them. It's possible. Actually, some services like Forum, if you are subscribed from two devices, you see the most the same. It's possible but it's not implemented yet. In fact, we have a proposal for, if you want to apply for the sum of code or some other grants to implement synchronization across devices. So we wait for our pull request and we'll be happy to review it. If there is no more question. Yeah, of course, you can install... Ah, okay, do you have some mechanism? So you can install the RetroShare code on a VPS and then have your device running just the graphical interface. The answer is yes. You could just install the RetroShare service on any machine and then access it through the JSON API. Thank you very much. If you have more questions, feel free. Feel free to contact him. And also please, for every talk you will attend in FOSDEM. If you could leave a constructive feedback on the website for speakers and for room organizers, it would be really great. Thank you.