P2P Private Chats (No Servers)

[trymeouteh]

I understand Mumble uses centralised servers. I would like to see some decentralisation so I will not need to host a server to have a private chat when gaming with friends. I would like Mumble to add this since Mumble is the best free, open source, Windows and Linux app that has good encryption and respect users privacy unlike Discord which essentially spies on its users and Teamspeak is not open source.

UPnP, OpenDHT and TURN will be great things to look into. To allow anyone to have a P2P chat that can easily be found in the Mumble server search. If this is implemented, please make this possible and user friendly for gamers who use VPNs.

https://jami.net/why-is-jami-truly-distributed/

[Krzmbrzl]

I don't think P2P makes sense for a VoiP application like Mumble, where latency is essential. Now I'm by no means an expert on P2P, but as I understand it, it works by having each client re-transmitting received data to the next link n the transmission chain (at least in a very basic approach).

For stuff like filesharing and chat, this is just fine because it doesn't matter whether the data reaches the last node say a second later than it was sent. For realtime audio on the other hand this is a no-go.

Imagine you have 5 clients A to E and let's assume that it takes 10ms to transfer an audio packet from one client to another. If A sends an audio packet, B to E will experience a latency of 10ms, 20ms, 30ms, 40ms respectively. This will get worse quickly if one link in that chain doesn't have a great internet connection.

If we take the same example but introduce a centralized server with the same 10ms latency, then A sends its packet to the server (10ms) and the server then sends the packet to all clients (10ms) resulting in each client to have a consistent latency of 20ms. This really comes into play when you not only have 5 clients but 20 or 100.

Googling a bit turned up that there exist some VoiP programs, that use P2P but it doesn't seem to be the majority. I like to see that as some sort of validation of my theory...

If someone knows P2P better than I do, please verify/falsify my argument here.

[Krzmbrzl]

@mnemex wrote in https://github.com/mumble-voip/mumble/issues/4049#issuecomment-627005818 (I moved it to this issue because it was OT for the original one):

So, on the one hand, technically "not having a server" isn't actually an option at all. Absent broadcast (not practical on the wider Internet), the internet operates on servers (listening on ports for all traffic directed to an address) and clients. That's all there is, absent spies (man in the middle attacks); "Peer to Peer" services are just systems where every single client is also acting as a lightweight server as well.

Now, that said, yes, of course tecnically murmur/mumble could be made more decentralized via an enourmous amount of effort--for small rooms there would even be significant advantages to doing this in terms of latency (instead of routing through the server, packets could be sent to all the other clients' server ports). But as said, that's a huge undertaking and way out of scope for this ticket.

That said, trymeout's core request "I want to be able to talk with my friends without having to go through the effort of setting up a server -or- locate/connect to someone else's server" could be handled handily via two stories:

This one.

"As a casual user of mumble who wants to set up a simple private murmur server, I want a UI (maybe inside a window in mumble itself) that will let me set up some basic configurations and launch/manage a server without having to mess with a text configuration, doing basic stuff like setting latency/bandwidth preferences, admin password/channels, and enabling uPnP and leaving everything else default."

Just those two would give someone the "private user" experience--they could even have the option to either get their IP from the UX (which can pretty easily figure out the external IP via some probing and a helpful external site) or set it up to advertise the server via a normal meta-server (I don't remember what the murmur world calls it) and thus let friends connect to them by name.

I'd even argue that if one is willing to accept some hacks, this is like 1/3 to 1/2 the way to the P2P experience implied by trymeout's request. If all mumble clients have the ability to optionally set up and advertise local servers that they connect to, and which they set policy for, it's not -that- far from that to using those servers to set p2p voice data when both sides are willing. This is easier said than done (for one thing, unless one sets up a -very- stripped down server, authentication is an important issue, although if the client set up the authentication it could be random/temporary and sent via a higher level communication), but still much closer given ui based murmur configuration and uPnP.

[trymeouteh]

How I see P2P working is like Jami. Someone is the host and all the others in the chat are connected to the host.

I feel this will be a good way to have a private game chat with friends. And this can be done so VPNs will work with it to protect the host IP address and those who connect to a chat can use a VPN to protect their IP address. Jami works with VPNs to allow for a secure and private P2P voice communication with 2 or more people.

[etosan]

Just strolling nearby I noticed this issue.

Like @Krzmbrzl, I believe you are tying to dress up "I want to be able to talk with my friends without having to go through the effort of setting up a server -or- locate/connect to someone else's server" as P2P issue. There are already easy to use solutions for that, like already mentioned Discord.

Besides, you can already host mumble server behind VPN quite comfortably. If your friends are using VPNs to connect to it as well, all your user's IP addresses are naturally protected too. I imagine mumble is easily hostable on both Tor and I2P.

The sad state of privacy on the internet is direct result of eternal search for "ultimate convenience" and "lack of will to learn". You cannot have privacy and have it convenient at the same time. Those are in fact direct opposites. You get either one or other.

Torrent is (P2P) distributed but not private, neither is Bitcoin. (P2P)distributed =|= private. You can build "private" on top of (P2P)distribution, but later does not imply former.

Mumble excels at what it is, and it can be privatised "simply" already. I believe it should concentrate on that.

If you are willing to have true P2P private voice solution you have to design it yourself, You will get results much faster if you start from scratch, than if you tried to bend mumble into what you want. Believe me.

If you lack the skill to do so, find people who like similar idea and work together. Mumble is not your target platform.

[namibj]

@trymeouteh I'd be someone interested in collaborating on a system for essentially server-less (only using something like IRC or so to exchange keys and IPs/ports) low-latency VoIP. My target is 20ms latency and transparent audio. It won't like wifi, and if you're more than ~100 miles apart, it's not as nice. Hit me up via email or Keybase.

[Krzmbrzl]

I think the consensus is that it's not suited for Mumble to go this route. If there are arguments that change that, I'll reopen the issue...

[chayleaf]

I'd just like to jump in, in my case I use mobile internet so I have to host everything on a VPS, my VPS is in another country (and even if it wasn't, it would've been like 500km away from me) so ping is sub-optimal, when there isn't a lot of people in the channel it would've been far more efficient to use p2p (client-server is clearly superior when there's like 10 ppl in the channel, but with 2-3 people p2p is just better). Obviously UPnP solves that too by allowing me to host murmur via UPnP.

Edit: I'll use ZeroTier instead.

[RokeJulianLockhart]

https://github.com/mumble-voip/mumble/issues/4159#issuecomment-627133778

I don't think P2P makes sense for a VoiP application like Mumble, where latency is essential.

@Krzmbrzl, for those with poor connections to the InterNet, but perfectly fine LANs, latency is superior when retransmitted via P2P.

[Krzmbrzl]

In that case my suggestion would be to simply host the server on LAN

[RokeJulianLockhart]

https://github.com/mumble-voip/mumble/issues/4159#issuecomment-1826395608

How is that “simple”, @Krzmbrzl? Certainly, how is it simpler for the end user than P2P?

[Krzmbrzl]

Easy: P2P would require end users to implement it themselves, whereas a Mumble server can be installed from a pre-built binary.

Jokes aside, my answer was pointing out that your use case does not justify the immense implementation work that would be required to make Mumble P2P compatible. It can equally well be served by the current architecture.

[RokeJulianLockhart]

https://github.com/mumble-voip/mumble/issues/4159#issuecomment-1826729490

P2P would require end users to implement it themselves

@Krzmbrzl, are you referring to code contributions to this project? P2P generally requires for the end user no more than a hostname or non-randomized MAC address (since that can be resolved to an IP address on a LAN, so not even an IP address is necessary).

It can equally well be served by the current architecture.

Not if the users don't possess a server. That is most people. Or can it be feasibly run from a desktop PC without concern for constant shutdown like a personal computer normally encounters? Perhaps I'm thinking of the server software as someone would Plex or NextCloud rather than what it is.

[Krzmbrzl]

Yes I was referring to Mumble to being capable of this and therefore anyone who wants it, would have to contribute the necessary code changes themselves.