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
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.
- 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.
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.
- Report issues with SAFE Launcher
- Report issues with SAFE Demo App, SAFE Signaling Demo, SAFE Comment Tutorial or SAFE Mail Tutorial
- Report issues with SAFE Browser
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
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.
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.
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.