Yeah it will be a challenge to compete. In particular in gaming latency in voice defeats the purpose of having voice Comms in the first place. You also need push-to-talk, voice activation for people with good mics, noise cancellation and - ideally - the ability to set the region for the voice server. EU gamers on discord are unlikely to set a US voice server for Comms and vice versa. For my community we've decided to go with a nip-29 relay for chat, images, videos etc and until good voice solutions evolve around nostr we'll probably setup a TeamSpeak or Ventrilio Server. But will definitely test Flotilla as well.

Hm, yeah I'm not thinking of gamers specifically. But reading about Discord's tech makes it clear that it's very difficult to do well. I self-host a teamspeak server for my gaming friends and it works well enough. It would be nice to have better chat integrated in (like Discord) but other than that we are pretty happy with it.

Sweet, I will definitely ping you when I have something to test!

Thanks! Another vote for LiveKit. Seems like that's the way to go. I haven't tried to self-host flotilla yet but I plan to. Hopefully I can smooth out the docs for that. If you want to give the app part another try I'll DM you an invite to the "meta" server.

i would perhaps look into MOQ.

Why not WebRTC with Opus + NIP-29? I debated the idea with my agent and here's the summary. Care to hear your thoughts on this. For a NIP-29 group chat app, the cleanest “voice chat” implementation is: 1) Transport: WebRTC (real-time, NAT traversal, battle-tested) Why: you get P2P audio with congestion control, jitter buffers, echo cancellation, device access, and NAT traversal (ICE/STUN/TURN) out of the box. Codec: Opus (use this unless you have a very specific reason not to). It’s effectively the WebRTC audio codec and is designed for low-latency interactive audio like VoIP / in-game chat. https://developer.mozilla.org/en-US/docs/Web/Media/Guides… 2) Signalling: use Nostr for session setup (offers/answers/ICE candidates) Nostr is great as the signalling plane (exchange SDP + ICE candidates), while WebRTC carries the media. A common approach: When a user taps “Join voice” in a NIP-29 room, you publish encrypted signalling messages (offer/answer/candidates) to the other participant(s) (or to a coordinator) via Nostr. There’s already discussion/precedent for doing WebRTC signalling over Nostr DMs. https://github.com/nostr-protocol/nips/issues/771 3) Topology decision (this is the real product choice) A) Small groups (2–6 people): Mesh P2P Everyone connects to everyone (N×(N−1) streams). Pros: simplest infra (no media server), very “sovereign”. Cons: scales poorly; uplink dies fast as people join. B) Anything beyond small groups: SFU (Selective Forwarding Unit) Each client sends one upstream audio stream to the SFU; SFU forwards to others. Pros: scales to larger rooms; better UX on mobile/weak uplinks. Cons: you run infra (but it can be self-hosted; still fits the Nostr ethos if you keep it modular). If you want “Discord-like” rooms, you want an SFU. 4) Practical codec settings (sane defaults) With Opus in WebRTC you typically ship: 48 kHz Opus, variable bitrate, 20 ms frames (WebRTC defaults are usually fine) Enable DTX (silence suppression) for bandwidth savings in speech rooms For “music mode” rooms, allow toggling off aggressive noise suppression/AGC (WebRTC defaults are voice-optimised) 5) Encryption & identity WebRTC media is encrypted (DTLS-SRTP). Nostr keys can authenticate who is allowed into the voice room (tie it to NIP-29 membership/moderation rules). NIP-29 is explicitly about relay-managed closed groups. https://github.com/nostr-protocol/nips/blob/master/29.md TL;DR implementation pick WebRTC + Opus for audio Nostr for signalling (offers/answers/candidates), encrypted Mesh for tiny rooms, SFU for real rooms

i would perhaps look into MOQ.

Why not WebRTC with Opus + NIP-29? I debated the idea with my agent and here's the summary. Care to hear your thoughts on this. For a NIP-29 group chat app, the cleanest “voice chat” implementation is: 1) Transport: WebRTC (real-time, NAT traversal, battle-tested) Why: you get P2P audio with congestion control, jitter buffers, echo cancellation, device access, and NAT traversal (ICE/STUN/TURN) out of the box. Codec: Opus (use this unless you have a very specific reason not to). It’s effectively the WebRTC audio codec and is designed for low-latency interactive audio like VoIP / in-game chat. https://developer.mozilla.org/en-US/docs/Web/Media/Guides… 2) Signalling: use Nostr for session setup (offers/answers/ICE candidates) Nostr is great as the signalling plane (exchange SDP + ICE candidates), while WebRTC carries the media. A common approach: When a user taps “Join voice” in a NIP-29 room, you publish encrypted signalling messages (offer/answer/candidates) to the other participant(s) (or to a coordinator) via Nostr. There’s already discussion/precedent for doing WebRTC signalling over Nostr DMs. https://github.com/nostr-protocol/nips/issues/771 3) Topology decision (this is the real product choice) A) Small groups (2–6 people): Mesh P2P Everyone connects to everyone (N×(N−1) streams). Pros: simplest infra (no media server), very “sovereign”. Cons: scales poorly; uplink dies fast as people join. B) Anything beyond small groups: SFU (Selective Forwarding Unit) Each client sends one upstream audio stream to the SFU; SFU forwards to others. Pros: scales to larger rooms; better UX on mobile/weak uplinks. Cons: you run infra (but it can be self-hosted; still fits the Nostr ethos if you keep it modular). If you want “Discord-like” rooms, you want an SFU. 4) Practical codec settings (sane defaults) With Opus in WebRTC you typically ship: 48 kHz Opus, variable bitrate, 20 ms frames (WebRTC defaults are usually fine) Enable DTX (silence suppression) for bandwidth savings in speech rooms For “music mode” rooms, allow toggling off aggressive noise suppression/AGC (WebRTC defaults are voice-optimised) 5) Encryption & identity WebRTC media is encrypted (DTLS-SRTP). Nostr keys can authenticate who is allowed into the voice room (tie it to NIP-29 membership/moderation rules). NIP-29 is explicitly about relay-managed closed groups. https://github.com/nostr-protocol/nips/blob/master/29.md TL;DR implementation pick WebRTC + Opus for audio Nostr for signalling (offers/answers/candidates), encrypted Mesh for tiny rooms, SFU for real rooms

the gaming normies brought to my attention that discord is available for example on nintendo fukin switch.. so.. yah we have a lot of ground to make up

LiveKit is basically a set of open source code to do exactly this! That's the direction we are heading, there is a PR going here: https://github.com/nostr-protocol/nips/pull/2238

LiveKit is basically a set of open source code to do exactly this! That's the direction we are heading, there is a PR going here: https://github.com/nostr-protocol/nips/pull/2238