MaidSafe Dev Update - November 1, 2016

Today we are releasing a WebRTC video chat demo along with a dev tutorial that shows how to establish a WebRTC connection using the SAFE Network :tada:

Instead of using a centralized video chat service, such as Skype or Google Hangouts – who can track your location, what you are saying, and to whom, you can use the SAFE Network as a secure channel to exchange connectivity information to establish direct peer-to-peer WebRTC connections.

The SAFE Signaling Demo lets you set up a room and share the room name with someone you want to talk with. You should be able to connect to one another with video, audio and a small instant messaging feature on the left. You can see yourself on the bottom right, your peer is visible in the center. Enjoy!

This could and should be extendable by any developer to group chats, screen sharing and more (home security, etc.).

For now, only the connection establishment is done using the SAFE Network. The actual connection is either peer-to-peer (STUN) or via a TURN server. At some point later, we will integrate this functionality directly in CRUST. When safe_core async is complete (hopefully today), Nikita will be focussing again on CRUST for further NAT traversal, STUN, TURN capabilities, fully encrypted communications and formalising the wire protocol.

SAFE Launcher v0.9.3

This new version of SAFE Launcher is compatible with TEST 11. The previous version of SAFE Launcher (v0.9.2) should continue to work fine, but we recommend using the new version (v0.9.3) instead.




  • Requires safe_core 0.22.1
  • Get User’s Sign Key API added
  • FilterType returned in AppendableData GET response
  • Dashboard bugs fixed
  • UI logger integrated
  • 404 validation added for low level APIs
  • Proxy code removed
  • Test suite integrated
  • Unused production dependencies removed

SAFE Browser v0.3.6-2

You need to use the latest version of SAFE Browser (v0.3.6-2) in order to use the SAFE Signaling Demo.



SAFE Signaling Demo v0.1.0

Learn how to establish a WebRTC connection using the SAFE Network!

If you are the first user to join a room (the person initiating the call), the app creates an offer and tries to store it inside a structured data with an ID based on the name of the room. This offer includes a session description in SDP format, and it needs to be delivered to the call recipient (the person receiving the call).

If you are joining a room where another user is waiting for you, the app needs to receive an offer from the caller (the person initiating the call). The app expects this offer to be stored inside a structured data with an ID based on the name of the room. The call recipient then responds with an answer message, which also contains an SDP description.

Live version

You can access the SAFE Signaling Demo at safe://mediawebrtc.ben using SAFE Browser v0.3.6-2.



  • Cannot reuse the same room (currently you need to use a different room name for every new chat)
  • Supports only one-on-one chat (group chat not currently supported)
  • Needs camera access or else it doesn’t work

Other apps and tutorials

To download SAFE Demo App, SAFE Comment Tutorial and SAFE Mail Tutorial, see this topic:


If you need help with anything related to SAFE Launcher or SAFE Demo App, please use the Support category on the forum.

If you need help with anything related to the Dev Tutorials, please use the #support category of the SAFE Dev Forum.

Where should I report issues?

If you know which component a bug is associated with, feel free to report it on GitHub in the corresponding repo.

If you’re not sure where to open an issue, you can simply create a new topic on this forum and add the bug tag. @lightyear and I are subscribed to the bug tag, so we will automatically receive a notification whenever someone adds the bug tag to any topic. We’ll take care of opening an issue on GitHub if necessary.

If an issue is specifically related to the SAFE API, then it makes sense to use the SAFE Dev Forum. But for issues related to end-user applications (e.g. SAFE Launcher, SAFE Demo App, SAFE Browser, etc.), it’s fine to use this forum ( Most users already have an account here :smiley:

SAFE Launcher

The latest release of SAFE Launcher (v0.9.3) exposes all the low-level APIs from safe_core. The limitations mentioned in the previous release are addressed and the dashboard is now functional. We added a new API endpoint to get the signing key of the current user. When an appendable data with a whitelisted filter has to be created, the user needs to add the signing keys they want to allow. This API endpoint provides the ability to get the signing key of the current user and add it to the filter list of the appendable data so that the user can also append data.

We expect to release SAFE API v0.6 along with the next tutorial.

We finally started the discussion about the future of SAFE Launcher. The ideas presented in this topic are still open to debate by the community and we’d love to hear your thoughts and feedback :slight_smile: If some of them progress, they might turn into RFCs.


Async SAFE Core in dev branch is now complete as far as the API and interfaces are concerned. The frontend can use the new API via FFI to get a complete async (as opposed to blocking with a thread per invocation) notification based solution. We have used futures-rs and tokio-core liberally as both of them are Rust’s take on modern async APIs.

Along with that we also managed to complete file-versioning as discussed on the dev forum. Changes including StructuredData delete handling have also been ported as discussed in this dev forum topic.

Currently we are working on getting examples up and running so that the interfaces and behaviours are demoed and tested. This shouldn’t take much time and we are anticipating completion by tomorrow.

Once everything is thoroughly tested and confirmed to work with the available frontend and examples, we will soon be merging the dev branch to master, and then we’ll publish a new version on

Routing & Vault

Qi finished implementing the safe_vault part of disjoint groups, and we are finally updating and re-enabling all our tests again, one by one. The whole change took longer than we had anticipated, as it is a pivotal area touching almost all aspects of the system, but the team expansion is helping a lot and our new colleagues have already contributed a great deal to completing the code.

We’ve also started with the implementation of the new message routing and accumulation mechanism, which will utilise the node key’s web of trust as defined in RFC 37 to verify the authenticity of messages.

We also got first numbers out of the security simulation, which are encouraging. We will discuss those results in the coming days: whether to increase group size, how to do that without impacting performance, or whether to take other measures to improve security and how to extend the simulation to include those measures, but also further attack scenarios.


video chat :tada: awesome :boom:


I’m connected at safe://mediawebrtc.ben/#hundef+swikith. Feel free to join me!

Group chat is not currently supported, so only one person will be able to join :smiley:

EDIT: Thanks to @Melvin for joining :grinning:


Peer to peer is obviously a huge security issue. I can set up a honeypot to get you to contact me, find your IP address and if I’m a state actor, have your physical location in minutes. Or I can just log which IP addresses I connect to, when, and what the communication entailed, to use as evidence later.

It surprises me that the clearnet functionality was stripped from the browser proxy, because it was a security risk, and then a month or so later, this is introduced.

I do get that this is better then using Skype, since it makes a 3rd party (Microsoft, Google, etc) not able to be involved in the connection, and for people who can’t set up a WebRTC signaling server on their own, this is a win.


Weeee! Good stuff.



You can’t ‘find’ somebodies IP address on Safenet, I think that’s the whole point in it.


Just a step in the process, as the intro says. This is not final functionality, but is a good demo of how some functions can be set up.


Nothing really was introduced: we didn’t do anything on the network, browser or anywhere else that added this functionality – all this was possible all along. All we did is make an example that show cased how this storage pattern could be used to handle hand-shake information like this.

Of course, in a fully fletched App, I’d expect it to encrypt the payload with a public key of the other side to ensure identity, too (which the example does not at this moment). Making the described state-actor case you describe a lot harder to do.


If we use TURN coded into vaults then it’s a relayed IP so you will not know me. An easier honeypot would be to get me to say something to you (it’s all signed) and use that, i.e. emails or similar.

This shows you can get directly corrected for fast comms between people (or IOT devices) and also routed connections via vaults if you want to not leak your IP address to the participant.

What we want is devs to focus on applications and ignore the back end, we will there have the secured signalling (demo’d here) and encrypted communications as usual. We will also have relayed (single hop) connections to mask location etc.

However if application developers can take this and create
Group conversations
Skype/hangout functionality (even with recording and publishing where requested).
Screen sharing

And much more, than we can imagine, it means they can have applications that people really want, but delivered securely.

Hope that helps. If honeypots are a real worry then it’s possible to have multi hop routes, but we would need to confirm there was a security leak first. No big issue though, we just want to show we can secure the insecure parts of these current technologies and allow them, again without choosing publicly known servers etc.


This would be the goal, I hope. I get that such a relay may prohibit video due to added latency, but I would hate people thinking they are secure, when they’re not.

Once there is a huge app ecosystem, it will be interesting to see how we warn each other of apps that go around the safe network to save costs or latency, and thus introduce insecurity.


Great update!! Feel free to give me a visit. I’ll be online for some time.



Update: @Melvin was the first one to troll in.


Ruining all the public posted rooms here! :imp:


Integration with SAFE Browser

We could bundle an authenticator directly within SAFE Browser. That way users wouldn’t have to download two separate apps. They could simply download SAFE Browser and use it to create an account or log in to an existing account. The browser would also allow for authentication of local and remote apps.

I think this is a very great idea. Will reply on the dev-forum as well.


OMG this is awesome. WebRTC totally inside SAFE. This is the best!!!
Great work guys(and having STUN/TURN features integrated into CRUST will be epic!)


Thanks so much for all of the hard work!

I know I say the same thing every week, I hope it doesn’t get repetitive. But I truly feel grateful each and every week that all of you are working on this. If I think of something more clever to say I definitely will add it!


I’m at

Please try to connect :slight_smile:


I usually completely read these updates, but all I read was WebRTC video chat demo and it took me 30 minutes to return from the dimension that I was dragged in.

I’m still not fully functioning, but WOW this is amazing, Maidsafe team you guys are the best. These Lego blocks are slowly all connecting :stuck_out_tongue:


Tried but I get a PUT error, logged here

1 Like

@JPL, that’s probably because I was connected with @Southside.