element-x-android VS coturn

Yep, a good example is the element X rewrite

They use Jetpack on Android

https://github.com/vector-im/element-x-android

And SwiftUI on iOS

https://github.com/vector-im/element-x-ios

But both use the same underlying Matrix Rust SDK

https://github.com/matrix-org/matrix-rust-sdk

So they share the core part of the app between platforms, but everything user facing is native

And the cake under the cherry is… Element X is open-source[1][2]!

I really can't wait for Beeper[3] to rebuild their fork on top of Element X (it's currently based on Element, formerly called Riot). If this happens this will be an absolute game-changer in the messaging ecosystem.

[1] https://github.com/vector-im/element-x-ios

[2] https://github.com/vector-im/element-x-android

[3] https://www.beeper.com/

You can get the latest build here: https://github.com/vector-im/element-x-android/actions/runs/4203105910

Element X is an entirely new client written in Rust + Swift UI/Jetpack Compose (https://github.com/vector-im/element-x-ios and https://github.com/vector-im/element-x-android) which will eventually replace the legacy Element apps (https://github.com/vector-im/element-ios and https://github.com/vector-im/element-android).

The features already exist serverside; we're just working on getting them out of beta.

Both TURN and STUN can be self hosted, the most popular project i have found is coturn

# TURN server name and realm realm=DOMAIN server-name=turnserver # Use fingerprint in TURN message fingerprint # IPs the TURN server listens to listening-ip=0.0.0.0 # External IP-Address of the TURN server external-ip=IP_ADDRESS # Main listening port listening-port=3478 # Further ports that are open for communication min-port=10000 max-port=20000 # Log file path log-file=/var/log/turnserver.log # Enable verbose logging verbose # Specify the user for the TURN authentification user=turnuser:turn456 # Enable long-term credential mechanism lt-cred-mech # If running coturn version older than 4.5.2, uncomment these rules and ensure # that you have listening-ip set to ipv4 addresses only. # Prevent Loopback bypass https://github.com/coturn/coturn/security/advisories/GHSA-6g6j-r9rf-cm7p #denied-peer-ip=0.0.0.0-0.255.255.255 #denied-peer-ip=127.0.0.0-127.255.255.255 #denied-peer-ip=::1

I am trying to deploy coturn server in the Kubernetes cluster.

That is an excellent use case for a webrtc server rather than an usual voice communication. If you decide to go that way, you don't need any sim card. You just need an internet access. You install a webrtc client (the usual one is coturn). I don't know if you also need to set up some kind of chat server in addition.

I've found this issue for you: https://github.com/coturn/coturn/issues/492

If you host yourself on a VPS you can hook in coturn (it's enabled by the linked playbook by default):

https://github.com/spantaleev/matrix-docker-ansible-deploy/b...

https://github.com/coturn/coturn

You're welcome! If this is for mission-critical or commercial use, you will want to invest in a good TURN server to ensure a reliable connection between peers. You can either self-host your own Coturn server or pay for a service like Twilio. But if this is just a hobby project, you can just use the free Open Relay Project.

schema.sql - coturn - GitHub

I tried http://turnserver.open-sys.org/ and cloning the GitHub repository, but I got the same results.

NetBird and Netmaker are similar in their capabilities and mesh offering, the same goes for Tailscale, but if we compare technical implementations, Netbird relies on the ICE and STUN protocols to discover the best path for p2p connectivity between peers. These are open WebRTC protocols with battle-tested software around them. Similarly, we use TURN for securely relaying traffic, when a p2p connection isn't possible (hard NAT). This protocol also comes from the WebRTC world and has stable and popular implementations like Coturn.