But HATEOAS does not require an LLM. It only requires that the client be programmed against an interface and not an implementation. The interface is the resource types and the method names. The implementation is the specific URLs for resources and methods.
The week of 02-23 to 03-01 had 5033 story posts that aren't dead or deleted from 3298 different users. Of these 1146 users have 500 or more karma. Of these 1548 were created over 5 years ago. Of these 966 users have both 500 or more karma and have created their account over 5 years ago.
Your filter would reduce the number of posts to 2141 posts by 966 users from 5033 posts by 3298 users.
Thanks for sharing that. I hadn’t heard of Zest before and it mirrors some of the user interface designs I’ve been working on.
Did you use Zest? What aspects of it worked well or failed in practice? It’s cool that some of the work ended up in Google Wave. I always thought that was an amazing product, I was so sure it was going to replace email and then it ended so abruptly.
Thanks for sharing this! POTSHARDS is a fascinating approach to long-term survivability through secret sharing and distribution. While they focus on avoiding encryption keys via data sharding across multiple archives, I’m trying to tackle the problem from the human side — using a memory-derived recursive cascade as the key. It's interesting to see how different architectures address the 'forgotten master key' dilemma.
I have a list of questions that I wrote up earlier.
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?
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/)
Actually, to give a more accurate answer to 4: we just shipped a public-key identity system, so yes, clients can now be identified by keypair.
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.
reply