Skip to main content
tavrn Docs

Legal pages and GDPR

Imprint, privacy policy, terms, takedown notices and the users’ data rights (protocol: LEGAL.md). Nothing here is legal advice: you run the node and remain responsible for it. Settings: Legal settings.

  1. Designated contact. Admin → Legal → “Contact for notices”: name, postal address and e-mail of the person who receives notices (the DMCA designated agent and the DSA point of contact). For the US safe harbour, also register the agent with the US Copyright Office.
  2. Pages. Admin → Legal: pick the document, “Insert template” (privacy policy in English or German, a German imprint, a terms skeleton from templates/legal/), replace every [[OPERATOR: …]] note, review the text with a lawyer, remove the template notice, publish. Check at least: controller and data protection officer, hosting provider, the third parties you actually use (SMTP, Turnstile and its transfer basis, GIF provider, SSO provider, external file storage, Valkey, and the browser vendors’ push services for web push), attachment, log, audit log and backup retention, the supervisory authority, the minimum age; in the imprint the full postal address (no P.O. box), representatives, register and VAT numbers and the person responsible under § 18 Abs. 2 MStV. The pages appear at https://<domain>/legal/<kind> and behind the “Legal” link of every sign-in screen.
  3. Terms. Once terms are published, registration asks for them. Each new version is shown to every user once; TAVRN_LEGAL_TERMS_MODE=require blocks accounts until they accept (declining signs out).
  4. Notices. TAVRN_LEGAL_NOTICES=on opens the public form https://<domain>/legal/notice (captcha when configured, TAVRN_LEGAL_NOTICE_RATE_PER_HOUR). Cases appear in Admin → Notices: remove content (with a statement of reasons for the uploader), disable the account, reject, or forward to the node that hosts the content. After TAVRN_LEGAL_REPEAT_THRESHOLD actioned notices against one user the page suggests disabling the account; uploaders may send a counter-notice within TAVRN_LEGAL_COUNTER_NOTICE_DAYS. Configure SMTP (TAVRN_SMTP_URL) so reporters and uploaders get their mails.
  5. Retention. Cases are kept TAVRN_LEGAL_NOTICE_RETENTION_DAYS (default 1095 = 3 years) after their last change; export them as JSON from the Notices tab for your records. Deleted accounts can be restored for TAVRN_ACCOUNT_DELETE_GRACE_DAYS (default 30) in Admin → Users, then they are erased.
  6. Data rights. Users download their data under Settings → Profile → “My data” and delete their account under Settings → Privacy & safety. On request you can do both for them in Admin → Users (your confirmation is required and audited).

What the node can and cannot see, for the privacy policy: the content of encrypted conversations (messages, voice, whiteboards) is end-to-end encrypted and never readable by the node; metadata (who is in which room, when messages are sent, IP addresses in logs) and unencrypted channels are. Link previews show the node which URLs users preview. Web push payloads carry no content of encrypted conversations. Retention you control: messages (TAVRN_RETENTION_DAYS), attachments (TAVRN_ATTACHMENT_RETENTION_DAYS), stale devices (TAVRN_DEVICE_STALE_DAYS), remote users (TAVRN_FEDERATION_REMOTE_USER_RETENTION_DAYS), legal cases, deleted accounts, and your own log and backup rotation.

Section titled “Rooms’ own privacy notice and legal notice”

Room managers (Manage room) can publish a privacy notice and a legal notice for their room (Room settings → Legal; protocol PROTOCOL.md §6b “Room privacy notice and legal notice”). Both are optional Markdown documents (up to 20,000 and 5,000 characters), shown before joining (invite page, join dialogs of the invite list, Discover and the directory) and to members (room menu and Room settings → Legal), with the date of the last change. They inform; they never have to be accepted. Every change is audited as room.legal.

What this means for you as the operator: you stay a separate controller for what the node does, with your own privacy policy (Admin → Legal); the room’s documents link to it through the template and do not replace it. People who run rooms that are not purely private (public rooms, communities of a business or an association) may be controllers for their room jointly with you (CJEU C-210/16, the “fan page” ruling) and may need a legal notice of their own; the umbrella repository’s guide docs/room-legal.md explains this for them. You may want to say in your terms who is responsible for what in rooms and how requests about a room reach its managers. Nothing here is legal advice.

Age gates

Section titled “Age gates”

Since age.v1 (protocol PROTOCOL.md §5e) every registration asks for the date of birth: the password and passkey registration, the registration on the connect page of the apps, and accounts created by single sign-on (they are asked right after their first login). People younger than TAVRN_MINIMUM_AGE (default 16, the GDPR consent age in Germany) cannot register. Accounts that existed before are asked once at their next sign-in; until they answer, the node refuses everything but the account itself, the legal pages and sign-out (age.status_required).

  • Private. The date of birth stays on this node. Nobody but the user sees it or the derived status (adult from the 18th birthday on, minor before, unknown without a date; unknown counts as minor). Other nodes only learn the signed “18 or older: yes/no/unknown” claim in the federated sign-in when the user acts there, and never show it.
  • Gates. Room managers can mark a room “adults only” (Room settings → Overview), channel managers a channel (Channel settings). Users under 18 never see a gated room in Discover and cannot join it, not even with an invite; a gated channel stays in the list but is locked for them: no messages, files, search, notifications, push or voice. This applies to moderators and owners as well. Only adults can switch a gate on.
  • Corrections. Users enter the date once. To correct it on request: PUT /api/v1/admin/users/{user_id}/date-of-birth with {"date_of_birth": "YYYY-MM-DD"} (or null to ask the user again); audited as admin.date_of_birth without the date.
  • Privacy policy. The privacy templates (Admin → Legal → “Insert template”) contain a paragraph that explains why the date of birth is collected, where it is stored, what other nodes learn and how to correct it; the minimum age is filled in from TAVRN_MINIMUM_AGE.
  • What it is not. The date of birth is self-declared. It is not age verification in the sense of the EU Digital Services Act guidelines, the planned EU KIDS Act or the German JMStV (closed user groups need a KJM-approved age verification system); pluggable verification providers are planned. The legal background and the full design are in the umbrella issue just-tavrn/tavrn#2. You remain responsible for the age rules of your jurisdiction.

This page is generated from tavrn-node/docs/HANDBOOK.md (AGPL-3.0-only) when the website is built; its links were adapted for this site.