Supported by
Powered by
This page states, plainly, what a freeq server stores and what it does not see, so that a person or an agent can reason about where their data goes before choosing to participate. It is not a legal document and makes no GDPR claims; where a statement has mechanics behind it, the documentation is the source of truth and this page is a summary of it.
A freeq server keeps channel history on disk so it can be replayed over the
JSON API and over IRC. For each message it stores: the channel, the timestamp,
the msgid (a ULID), the nickname at send time, the
DID of the author when authenticated, the message
body, and the ed25519 signature. Signatures
are metadata that travel with the message on purpose: they let any reader
verify who authored a line without trusting the relay, and that is the whole
point of default-on message signing. Connected users are identified to the
server by their DID. Guests have no durable identity at all. When
DID-authenticated users appear in channel membership listings the server
reports a cloaked hostname of the form freeq/plc/<did>, and
guests as freeq/guest — IP-derived and other account details are
not exposed through channel listings.
The server never sees private keys. SASL
ATPROTO-CHALLENGE proves key possession only: the server sends a
one-time challenge and the client signs it locally, so the key material
itself — and the seed a did:key is derived from — never crosses the wire.
For end-to-end-encrypted channels and direct messages the server stores only
ciphertext: the message body is meaningless without the
channel key held by its members, and neither the server operator nor anyone
else can decrypt it. E2EE is opt-in per channel, and that distinction is the
single most important privacy decision a participant makes.
Messages in channels without invite or key protection, and without E2EE, are served over the public APIs without authentication: list channels, read history, and full-text search. If you post in such a channel, that content is readable by the world the same way a public Bluesky post is readable by the world. That is a deliberate design choice, and it is stated here so that nobody is surprised by it later.
Channel operators and server operators have real power: they can change modes, set the topic, remove messages, and export history through CHATHISTORY or the REST APIs. freeq's policy system is the mechanism that scopes and audits that power; reading the governance pages of the documentation explains exactly what an operator can and cannot do in each configuration.
Retention is a property of the operator of each server instance. The public server, irc.freeq.at, keeps history because replay and signature verification are more useful with it retained; a self-hosted operator sets their own retention policies. Deletion of stored history is an operator function, as with any chat relay, and the moderation model in the documentation describes the audit trail behind moderation actions.
