playnet · privacy notice · terms of use ← back to the dial

Privacy Notice

Version 1.0.0 · effective 2026-08-01 · for the gateway operated by [operator not configured — see docs/legal/README.md]

This notice is written to be true rather than reassuring. playnet's record is cryptographically append-only: that is what makes it auditable, and it is also why several things you may expect from a privacy notice — a delete button, a guarantee that a record has gone everywhere it went — do not exist here. §5 states plainly what we can and cannot do, and what is being built to narrow the gap.

1. Who is responsible for your data

playnet is federated: anyone can run a gateway, and the software's authors run none of them. The controller of your personal data is the operator of the gateway you use — here, [operator not configured]. The authors of the software are not a controller and hold none of your data.

Contact for anything in this notice, including any request under §5: [operator contact not configured]. Postal address, where the operator has one: [not configured].

Other gateways are separate controllers. When credentials are shared across the federation, the receiving gateway determines its own purposes for them and answers for them itself. Where two gateways jointly decide how shared credentials are used, they are likely joint controllers under Article 26 GDPR, and each should tell you the essence of that arrangement. Ask us and we will tell you which gateways we federate with.

2. What data exists, and where

2.1 On this gateway

Data	Where it comes from	Notes
Your AID and its key event log — creation, key rotations, signatures, registration time	Created in your browser when you sign up	Published — see §4.1. Contains no name or contact detail.
Display name and email	Only if you enter them in settings — both are optional and blank by default	Name aids discovery; email enables notifications. Neither is used for account recovery.
The index from your AID to your name	Derived, so the gateway can look you up	This is the single record that turns a pseudonym back into a person. Its removal is the core of any erasure request (§5).
Notification bindings — email address, Telegram chat id, Matrix room, Reticulum/LXMF address, browser push subscription	Only channels you connect	Keyed by your AID, which joins them all together.
Presence — your display name against a live session	While you are signed in	Broadcast to other connected members.
Server logs	Operation of the service	Currently include usernames and AIDs. See §7 — this is a known defect being fixed.

2.2 Credentials — the substantive record

Most of what the system knows about you is held as signed credentials, stored by the hash of their contents and anchored in the issuing scope's key event log:

work events — hours of labour, per person, per process. This is working-time data;
claim events — what you drew from the commons, how much, and when. Taken together this is a consumption profile;
skills — competences you hold, with a validity window;
personhood — an attestation that your AID is a distinct real person, and who sponsored you. Where an identity check was done, we store a hash of the evidence, never the evidence itself;
relationships — declared trust, colleagues, guardians and delegates: an explicit, signed social graph;
stances — how you voted on a proposal, and any delegation of your voice (§3);
contact points — where you choose to hold a channel as your own credential rather than leaving it in our member record.

2.3 On your own device

Your private keys are generated in your browser as non-extractable keys and kept in the browser's own key store. The private half never becomes readable bytes, so it cannot be copied out of the page — not by us, and not by an attacker who gets script into it.
Your passcode is never stored anywhere and never sent to us. It is the key.
A local sign-in hint holds your AID and, if you set them, your name and email in plain text in this browser's storage. It sits on your device only. Clearing site data removes it — and, since you will then need your AID and passcode to sign in again, do not clear it before you have saved them.

3. Political opinions — special category data

How you vote is recorded against your identity, in signed form. Under Article 9 GDPR that is special-category data and needs a specific condition to process at all. The condition relied on is Article 9(2)(d): processing by a not-for-profit body with a political or philosophical aim, in the course of its legitimate activities, concerning its own members, with no disclosure outside the body without your consent.

What that means in practice, and its limits:

a stance credential carries a high-entropy blinding value, so the hash that identifies it can no longer be brute-forced back to how you voted — a real leak, now closed;
this makes the ballot secret against a bystander holding the identifier. It is not secret against the tallying scope, which must read the stance to count it;
ballot snapshots record voting weight and the resolved delegation chain per member. Keeping these inside the tallying scope rather than distributing them across the federation is current work, not a finished property — treat your vote as visible to your own commune.

If you do not want a political opinion recorded against your identity, do not vote. Abstaining is the only complete protection we can honestly offer.

4. Who else receives it

4.1 Witnesses, and the public discovery endpoint

Every key event is broadcast to witnesses — independent machines run by other people, in jurisdictions we do not choose or know — which keep copies so that no single party, including us, can rewrite your key history. Your key event log is also served at this gateway's discovery endpoints, without authentication: anyone who knows your AID can fetch it. It contains your public keys, rotation history and timestamps; it does not contain your name or email.

Once a key event has been broadcast, it cannot be recalled. Verification of your signatures requires an unbroken sequence of key events, so events cannot be removed even locally without destroying the ability to check anything you signed afterwards. The timing and existence of your identity's events are therefore permanent. Requiring authentication on the discovery endpoint is planned and is anticipated by the KERI specification; it is not in place today.

4.2 Other gateways in the federation

Credentials are shared with federated gateways so that work, skills and personhood recognised in one commune are recognised in another. Those gateways are run by other people under their own notices and their own law.

4.3 Third-party services, only if you use them

Service	What reaches it	When
Web-push providers (Google, Mozilla, depending on your browser)	Your push subscription endpoint and notification content	Only if you enable browser notifications
Telegram	Your chat id and notification content	Only if you connect Telegram
Matrix homeserver	Your room id and notification content	Only if you connect Matrix
Email delivery	Your address and notification content	Only if you give an email address
Reticulum / LXMF mesh	An opaque cryptographic address	Only if you use the mesh. Preferred: it carries no identifying address.

We do not sell your data, do not use it for advertising, and run no analytics or advertising trackers. We may disclose data where a valid legal order compels it, and will tell you unless we are prohibited from doing so.

5. Your rights — and exactly where they stop

You have the rights of access, rectification, erasure, restriction, portability and objection, and the right to withdraw consent. Exercise any of them by writing to [operator contact not configured]. We answer within one month.

5.1 What we can do

Access and portability. We can give you the member record, notification bindings and credentials we hold for your AID, in a structured machine-readable form.
Rectification. You can change your display name and email yourself in settings; a credential cannot be edited, so correcting one means revoking it and issuing a corrected replacement.
Erasure of the link between your AID and you. This is the meaningful erasure available here. Removing the member record and the AID-to-name index leaves behind a pseudonym that nobody can resolve to a person. Combined with dropping your notification bindings, presence entry and push subscription, it removes essentially all the directly identifying data we hold.
Objection and restriction for our own processing on this gateway.

5.2 What we cannot do

These are architectural limits, not policy choices, and we will not pretend otherwise.

Key events cannot be erased. They are held by independent witnesses and, locally, holes in the sequence would break verification of everything you ever signed.
The fact and timing of every credential issuance is permanent, because it is anchored in a key event log. Removing a credential's contents can never remove the record that something was issued at that moment.
Copies at other gateways are beyond our control. We will pass on your erasure request to gateways we know received your data, but we cannot compel them.
Automated deletion is not implemented today. Every store in the reference implementation is append-only; revoking a credential flips its status and leaves the body on disk. Erasure requests are carried out manually by the operator, within these limits.

5.3 What is being built

Stated so you can judge the gap rather than take a promise on trust:

a forget operation that drops the member record, index, notification bindings, presence and push subscription in one step, and best-effort notifies the gateways that received your data;
encryption of credential bodies at rest under a per-person key, so that destroying that key makes the contents unrecoverable while the signatures, links and anchors stay verifiable — the erasure route the KERI specification itself sanctions ("only copies of the digest or signature of the data need to be kept");
blinding values on every credential carrying personal data, so a destroyed body cannot be reconstructed by guessing at its identifier;
moving contact points into credentials you hold and disclose revocably, rather than records we keep — after which withdrawing your email is something you do, not something you ask us for. The credential layer for this exists; the interface for it does not yet.

5.4 Complaints

If you are in the EU or EEA you may complain to your national data protection authority (directory); the authority for this operator is [not configured]. Elsewhere, to your equivalent regulator. Please raise it with us first if you are willing.

6. Why we are allowed to process it

Data	Purpose	Legal basis
AID, key event log, authentication	Providing the service at all	Contract — Art 6(1)(b)
Display name, notification bindings	Discovery and notifying you	Consent — Art 6(1)(a); both are optional and withdrawable
Work, claim and skill credentials	Computing the plan; recording contribution and entitlement within the commune	Contract — Art 6(1)(b), and the legitimate interest of the association in an auditable record — Art 6(1)(f)
Personhood and relationship credentials	Keeping out spam and vote-stuffing; resolving delegation	Legitimate interest — Art 6(1)(f)
Stances and ballot snapshots	Counting votes and resolving delegated voice	Art 6(1)(a) together with Art 9(2)(d) — see §3
Server logs	Security and debugging	Legitimate interest — Art 6(1)(f)

Where we rely on consent you may withdraw it at any time, and where we rely on legitimate interest you may object; in both cases write to the contact in §1.

7. Retention

Stated honestly: no retention period is enforced today. Credential validity windows — a personhood credential's expiry, a skill's valid-until — govern whether a credential still counts, not whether it is still stored; a lapsed credential remains readable on disk. Server logs currently contain identifiers and have no rotation policy. Both are known defects. The intended position, and the one we are implementing, is: a retention sweep for all non-key-event stores, log rotation with identifiers stripped, and member data kept only while you participate.

8. Automated decisions

The planner computes allocations automatically — by convex optimization over recorded needs, capacities, limits and contributed labour — and those allocations affect what you can claim from the commons. We consider this not to be a decision "based solely on automated processing" within Article 22 GDPR, because the output is a proposal that the federation adopts, amends or rejects through its governance, in which you have a voice and a vote. Either way, you can ask a person to look at any allocation that affects you, express your point of view and contest it — through the governance process, or by writing to the contact in §1.

9. Security

Private keys are generated non-extractable and never leave your device; the gateway has no key custody by design.
Every event and credential is signed, so tampering is detectable rather than merely forbidden.
Traffic is encrypted in transit; the gateway is also reachable as an onion service.
Known gaps, being fixed: server logs contain usernames and AIDs with no rotation policy; the discovery endpoint is unauthenticated; credential bodies are stored unencrypted.

No system is perfectly secure. If a breach is likely to put your rights at risk we will notify the supervisory authority and, where the risk is high, you.

10. International transfers

Witnesses and federated gateways are run by independent people in places we do not choose, and mesh transport routes wherever the mesh routes. Publishing to them is inherent to how the system resists tampering, and by participating you are asking for your key events to be witnessed in exactly this way. No standard contractual clauses or other transfer mechanism are in place for these flows. If that is unacceptable to you, this system is not suitable for you — we would rather say so than bury it.

11. Children

This service is not intended for children below the age given in §8 of the terms. If you believe a child has created an identity here, write to [operator contact not configured] and we will remove the member record — subject to the limits in §5.2.

12. Cookies

No advertising, analytics or third-party tracking cookies are used. The page keeps a small amount of data in your browser's own storage — your sign-in hint, your keys, and your interface preferences — all of which stays on your device.

13. Changes to this notice

Material changes are published here with a new version number and effective date, and you will be asked to acknowledge them the next time you sign in.

playnet — free software under AGPL-3.0 with additional terms. Privacy Notice v1.0.0, effective 2026-08-01. See also the terms of use. Engineering detail behind this notice: docs/planning/gdpr-analysis.md.