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 Browser v0.3.6-2

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.

Other apps and tutorials

Today we are releasing a new/updated dev tutorial :tada: We now have enabled two comments plugins: one for permanent comments and the other for editable comments. Both plugins let people comment on content using their public name. They also enable the website owner to delete comments and block users.
The difference compared to the previous dev tutorial is that users now have the ability to update their own comments and to see the history of other comments when a website is using the Editable C…

Support

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 (safenetforum.org). Most users already have an account here

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 If some of them progress, they might turn into RFCs.

Let’s use this topic to discuss the future of SAFE Launcher :smiley: We need to consider how SAFE Launcher can be scaled to various platforms (e.g. mobile, embedded, etc.). For example, SAFE Launcher currently needs to run in the background and continuously proxy HTTP requests to the SAFE Network, but on some mobile platforms that wouldn't necessarily be possible. It would be preferable if SAFE apps could communicate directly with the SAFE Network. As for app permissions and app management,...

Reading time: 3 mins 🕑Likes: 5 ❤

SAFE Core

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 crates.io.

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.

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.

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.

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.

Or I can just log which IP addresses I connect to, when, and what the communication entailed, to use as evidence later.

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 conversationsSkype/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.

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.

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!