ircv3-ideas VS coturn

> "At least as standard" how?

There are 8 people who vote on changes to the Matrix spec (the Spec Core Team), 7 of which are Element employees (including Matthew, Element's CEO). Element also controls the development of clients and servers used by the large majority of users in the public federation.

> A substantial portion of the IRC comunity is actively hostile to the IRCv3 extensions, and in some cases prefer incompatible implementations of the same functionality; Matrix has nothing like that going on.

But any IRC client will work fine on any IRC server, and they can connect to various servers with different implementations.

On Matrix, clients (generally) can only connect to one homeserver at a time; which forces them to converge on following exactly the same spec. And if your server differs ever so slightly from the other ones in how it implements some parts of the spec (room consensus), then it can be split-brained from the rest of the federation. Instead, changes to the room consensus are done by pushing new room versions, and each server implementation needs to explicitly support it or they can't join it. This means Synapse devs (which are a majority of Element employees) get to decide what room versions can get traction.

It is not uncommon for people in the Matrix community to complain about this and Element keeping specs in limbo, and PRs to the flagship clients being stuck in "design review tar".

> And there seem to be more visibly independent implementations of Matrix than IRCv3.

Clients, maybe, at least in the number of implementation. It's hard to find stats of this, but I feel that >95% of people in the public federation use Element even in tech-y rooms; IRC has a healthier mix of major clients (weechat, irssi, IRCCloud, Hexchat, KiwiIRC, The Lounge each have >5% of desktop/web users). But I admit that's just my very subjective point of view.

In terms of servers, Matrix has three open source ones as far as I know: Synapse (controlled by Element), Dendrite (controlled by Element, and almost on par with Synapse according to https://arewep2pyet.com/ ), and Conduit. Based on https://gitlab.com/famedly/conduit/-/milestones/3 , Conduit seems to be far from implementing the spec yet (eg. it doesn't seem to support leaving rooms or respecting history visibility).

> things like: server-side history extensions tended to mess up my client's history implementation (I'd end up with multiple copies of the same messages in my local logs, often with the wrong timestamps)

You can use https://ircv3.net/specs/extensions/message-ids to deduplicate them.

> And if you're in a conversation where people are using embedded gifs, then fundamentally you'll always be a second-class citizen if you're trying to participate in that with a client that can't display embedded gifs.

A conversation where people where people are using embedded gifs will exclude me regardless of client, because they are too distracting. At least on IRC I can expect people not to do it too much, and use words or emojis instead of reaction gifs.

> SSO access control; you just can't do that in a nice way if the client doesn't support it

That's a fair point; IRC is made by hobbyists more than companies, so that's not surprising. There is some discussion around it though: https://github.com/ircv3/ircv3-ideas/issues/74 and Sourcehut is sponsoring implementation (https://emersion.fr/blog/2022/irc-and-oauth2/).

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.