# Why Gryt?

Source: https://docs.gryt.chat/docs/guide/why-gryt

Philosophy, trust boundaries, and a simple architecture overview

If you're evaluating Gryt and want a single page you can share, this is it.

Gryt is a self-hosted, open-source voice chat platform with text chat and file uploads. The goal is simple: make real-time communication that you can run yourself, understand, and verify.

## The short version

- **Self-host first**: run the server on your own infrastructure.
- **Open source**: the code is readable, auditable, and forkable.
- **Privacy is structural**: the architecture is designed to avoid unnecessary trust and data collection.
- **No paywalls**: features aren't gated behind subscriptions.
- **Identity stays with you**: no server can steal or impersonate your identity.

## Minimal identity, not a social graph

Gryt intentionally separates **identity** from **server data**:

- **Identity** is used to prove "this is the same user as last time".
- **Server data** is everything that belongs to a server: channels, roles, membership, messages, and uploads.

When you join a server, you prove your identity through a [challenge-response protocol](https://docs.gryt.chat/docs/guide/security) — the server never receives a reusable token it could replay. The server you join can still store and process the content you send to it (messages and uploads), because that's how server-hosted communication works.

## Trust boundaries (what you're trusting)

Here's the honest version of the trust model:

- **If you join someone else's server**, you are trusting that server operator with the data their server stores. You are **not** trusting them with your identity — they can't impersonate you.
- **If you self-host**, that operator is you.
- **Voice uses WebRTC encryption in transit (DTLS-SRTP)**, but media is routed through infrastructure operated by the server owner (the SFU).
- **By default, login uses the hosted auth provider** at `auth.gryt.chat` (Keycloak). A separate Identity Service at `id.gryt.chat` issues certificates that servers can verify cryptographically (JWKS). Your Keycloak token is only sent to the Identity Service, never to a community server.

If you use the hosted web client at `app.gryt.chat`, also see the [Privacy Policy](https://gryt.chat/privacy) on the site.

## Architecture (simple)

Most of Gryt fits into four boxes:

- **Client**: UI + audio processing + WebRTC
- **Server**: chat, rooms, permissions, uploads, coordination
- **SFU**: routes voice media to everyone in a channel
- **Storage**: database + object storage

```mermaid
graph TB
  user[User] --> client[Client]
  client -->|WSS_signaling| server[Signaling_server]
  client -->|UDP_media| sfu[SFU]
  server --> db[Database]
  server --> s3[Object_storage]
  client -->|OIDC_login| auth[Identity_provider]
  client -->|Certificate| identity[Identity_service]
  server -->|JWKS_verify| identity
```

If you want the deeper technical diagrams and data flow, see the full [Architecture](https://docs.gryt.chat/docs/guide/architecture) page.

## Skeptic FAQ

### Can a malicious server steal my login?

No. Gryt uses [challenge-response authentication](https://docs.gryt.chat/docs/guide/security). Your Keycloak token is never sent to a community server. You prove your identity by signing a one-time challenge with a private key that stays on your device. The signed proof is bound to that specific server and expires in 60 seconds — it's useless anywhere else.

### Can a server admin read my messages?

If the server stores messages, the server operator can access them. This is the same trade-off as any self-hosted chat system. Gryt's point is that you can run the server yourself, or choose a server operator you trust.

### Can the SFU listen to voice?

WebRTC encrypts voice in transit, but the SFU is part of the communication path and terminates WebRTC sessions to forward media. Practically: if you don't control the SFU, treat it as trusted infrastructure.

### What does self-hosting actually buy me?

If you run your own Gryt server, your community's server data (messages, uploads, membership, roles) is stored on infrastructure you control. That narrows the trust surface compared to a centralized platform where all data lives under a single provider.

### Do I need to register my server anywhere?

No. Servers verify identity certificates by fetching a public key from the Identity Service's JWKS endpoint. There is no central directory, no approval process, no "nobody knows my server exists" problem.

### Is Gryt written by AI?

AI is used, but nothing security-relevant merges without being read line by line. The SFU, the authentication and identity code, the client's key handling, the image worker and the data layer can only change through a pull request that Sivert reviews in full — no direct commits. Documentation, the website, the interface and tooling get normal review.

Every commit that had AI assistance keeps its `Co-Authored-By` trailer, and the review-required areas have PR history on top of that, so you can check this yourself rather than take it on trust. The [AI policy](https://docs.gryt.chat/docs/guide/ai) has the exact paths, and is honest about the limits of a one-person review process.

## Further reading

- [Security](https://docs.gryt.chat/docs/guide/security)
- [Architecture](https://docs.gryt.chat/docs/guide/architecture)
- [Quick Start](https://docs.gryt.chat/docs/guide/quick-start)
- [Docker Compose deployment](https://docs.gryt.chat/docs/deployment/docker-compose)
- [Configuration](https://docs.gryt.chat/docs/guide/configuration)
- [AI policy](https://docs.gryt.chat/docs/guide/ai)
- [Licensing](https://docs.gryt.chat/docs/guide/licensing)