Download, Host, Play

When I was a kid, playing Minecraft with friends meant one of us hosting. You opened the game, clicked a button, and it was a server. Then came the part that never worked: getting anyone else in. Port forwarding meant a router page none of us understood on a connection none of us controlled, so we used Hamachi, a virtual LAN that pretended we were all in the same room. It broke constantly. We did it anyway, because the alternative was not playing together.

What I still think about is that hosting was normal, not the tunnelling. You didn't sign up for a service or rent anything. The game you downloaded was also the server, and whoever had the best computer ran it that evening.

Almost nothing works like that now. You make an account, you join somebody else's infrastructure, and the machine under your desk does nothing.

What changed

This release does two things, and they come from the same problem.

Gryt no longer asks you to make an account. You download it and you have an identity: a keypair on your own machine that signs for you. No sign-up, no email address, no way for us to connect it to a person. It isn't a trial mode. A guest identity signs the same challenge as an account, gets the same roles, and can own a server. The only difference is who vouches for the key. An account is vouched for by our identity service. A guest identity vouches for itself.

The app you downloaded is a server. It runs the same signalling server, media server and image worker a Docker deployment runs, bundled into the client. Name it, take the port it offers, press Create. It starts and you're in it. Anyone else on your network sees it appear on its own.

Why an account is still worth having

I want to be careful here, because "no account required" is the kind of claim that quietly means "and everything is worse now."

An account does three things a guest identity can't. It's the same you on every Gryt server, so people recognise you when you turn up somewhere new. It survives losing your laptop, because you sign in and you're yourself again. And it's something a ban can hold on to.

That last one is the real trade, and server admins should know it before they switch guests on. A guest can make a new keypair in about two seconds, so a ban on a guest identity lasts until they bother to. Servers that accept guests lean on the door instead — invites, approval, LAN-only — rather than on bans. That's a perfectly good way to run a server. It just isn't the only way, which is why the setting exists.

So: guest for a LAN party, a game night, a weekend server, anything you would rather not attach your name to. An account for the servers you mean to stay on, or when you use more than one machine. And if you start as a guest and make an account later, the membership you already had comes with you, along with your roles and history aren't stranded on the old identity.

Running more than one server

You can host several servers from one client, which is the part I didn't expect to be interesting until I had it.

They share a media server. Voice rooms are namespaced per server, so one SFU process serves all of them, the same arrangement gryt.chat itself runs, where three servers sit behind one. What a second server actually costs you is a server process and an image worker. Not another stack.

So one machine can host the one that stays up, plus a throwaway for tonight, plus the one you're testing something on. They're genuinely separate: own messages, own members, own invites, own database.

There's a delete button, and it asks you to type the server's name first, because it removes the only copy of that server's database and the key it identifies itself with. Everyone who joined pinned that key. A replacement with the same name and port is a different server to them.

What hasn't changed

Your machine still has to be reachable. Gryt doesn't run a relay you fall back on, because that would mean your conversations going through hardware you don't own, which is the thing this project exists to avoid.

On a LAN that's free, and this is the Hamachi part solved properly. Servers announce themselves and turn up in a Discovery list without anyone typing an address.

From outside, you need a route in, and this is the part I can't pretend is solved. A Cloudflare Tunnel handles the HTTPS and WebSocket side without exposing anything, which is most of the setup. It can't carry the voice. WebRTC media is UDP and tunnels aren't, so the SFU still needs a UDP port reachable from outside. One port rather than a range: 3478 unless you change it.

So the Hamachi-shaped problem is smaller than it was, not gone. You open one port instead of understanding a router page.

And if a server should stay up when the laptop closes, run it with Docker Compose instead. Same server, pointed at a disk that isn't your laptop.

---

The full list of what changed is in the 1.5.0 release notes. If you want the reasoning about identity rather than the summary, that's in the docs.