Is Gryt pronounced as Grit?
So does Gryt ever leak the IP of a client to other clients connected to the same server? (Specifically this means that it never uses direct P2P between clients.)
Can, if I have a server, have it proxy my connections to other servers, so that my IP is only seen by my server, but my server's IP is seen only by the other servers?
Can clients be identified by public key? (Rather than user name and password.)
Is the audio and video end to end encrypted?
Does the Gryt desktop client support multiple windows?
Does the desktop client support making the window vertically narrow?
Does the video streaming support a mode that does not apply a blur to the video as Discord does in its Screenshare mode so that the pixels on a screen are shown on other screens exactly?
Do you have plans on replacing MinIO as it is no longer supported as open source?
To answer them briefly:
1. Yes! You can pronounce it as "Grit", although "Greet" would be more accurate in English :D I wrote a blog post specifically about the name, as I predicted it's not easy to pronounce for non-Scandinavians: https://gryt.chat/blog/the-story-of-gryt
2. No! Gryt uses an SFU (Selective Forwarding Unit) architecture, not peer-to-peer. All media flows client -> SFU -> other clients. Clients never establish direct WebRTC connections with each other. The SFU sits in between and forwards encrypted media packets. Other clients only ever see the SFU/server's IP, never another client's IP.
3. No. There is no mechanism today for Server A to proxy your traffic to Server B. Your IP would be visible to each server you connect to directly. Your best bet here would be to set up a VPN on your server and connect to other servers from there :)
4. Not currently... Gryt uses OIDC (OpenID Connect) with PKCE via Keycloak for authentication. Clients authenticate with Keycloak using a username and password, receive a signed JWT, and present that JWT to servers. Servers verify the JWT signature against Keycloak's JWKS public keys but never see user passwords. There is no public-key-based client identity mechanism -- the identity system is token-based (JWT), not key-pair-based.
5. It depends on what you mean by "end-to-end." All media is encrypted using DTLS-SRTP (mandatory in WebRTC). The encryption is negotiated between each client and the SFU. Media is always encrypted in transit, and the SFU is designed to forward without decrypting, but it could technically decrypt if modified. Self-hosting gives you full control over this trust boundary.
As I wrote in one of my blog posts: "The SFU forwards encrypted packets without decrypting them. It can route audio but can't listen to it. Privacy is architectural, not a policy promise."
6. Yes! But not multiple sign-ins/clients. The desktop client (Electron) has a single main window, but video streams and screen shares can be popped out into separate windows. These popout windows are resizable and can be pinned as "always on top" (Electron only). So you get the main application window plus any number of popout video windows.
7. Kinda. You can resize the window down to 800px wide, but it won't go narrower than that. There is mobile-responsive layout logic in the codebase, but it's still very early. The 800px minimum width is subject to change :) I'm looking to implement a "mini mode" with only the chat of a selected channel -- "pop out channel" essentially.
8. Yes! Bitrate is configurable per quality level, and in native mode there is no bitrate cap. So unlike Discord's free-tier screen share, Gryt does not downscale or blur the stream -- it's designed to show pixels as they are, especially in native mode.
9. To be honest, this is not something I had in mind when I chose that architecture years ago. We're still very early in the project and can change it. We could always switch to OpenSTRG (https://github.com/strg-com/openstrg), which is literally a fork of MinIO, or use Garage (https://garagehq.deuxfleurs.fr/) maybe :) SeaweedFS is also worth a look (https://seaweedfs.github.io/)
I hope I could satisfy your curiosity!
Each client generates an ECDSA P-256 keypair locally (IndexedDB, private key non-extractable, never leaves the device). The client authenticates with Keycloak once and sends their public key to the Gryt Identity Service, which issues an identity certificate: a CA-signed JWT binding the public key to the user's Gryt ID. This isn't a bearer token; it only proves key ownership.
When joining a server, the flow is challenge-response: the server sends a nonce, the client signs a short-lived assertion JWT (bound to that server + nonce, 60s TTL) with their private key, and sends it along with the certificate. The server verifies the certificate against the CA's JWKS, extracts the public key, and verifies the assertion signature.
So servers never see the Keycloak token or password. They only verify the CA-signed certificate and proof-of-possession via the signed assertion. The identity system is now fundamentally key-pair-based.
Do you have a public roadmap? If I ever was to introduce a new messaging app to my friend groups then I would need to ensure it matches all their standards, lol. Also good for keeping up-to-date with the project of course!
All the best with the project, hope it gets traction!
I am actually working on a roadmap as we speak! I am still working on expanding it, but you can view it here: https://docs.gryt.chat/docs/guide/roadmap
Cheers!