Privacy Policy
What the XTech Venue System stores about you, why we store it, how long we keep it, and how to get a copy or have it deleted. Written in plain English on purpose — if anything here is unclear, ask and we will explain it.
Effective 9 August 2026. This policy covers the XTech web dashboard at
control.xtech.dev, its API at api.xtech.dev, this documentation
site, and the XTech objects and bots that run inside Second Life.
Who we are
XTech ("we", "us") builds and operates the XTech Venue System. We are based in the United Kingdom and our servers are in the United Kingdom, so UK GDPR is the law that applies to how we handle your data. For most of what is described below we are the data controller. Where a venue owner configures the system for their own venue — their staff records, their greet log, their visitor history — the venue owner is a controller too; see If you run a venue.
What we hold
Your identity
An avatar name is not anonymous — it is a persistent handle that identifies a person, so we treat it as personal data even though we never learn your real-world name.
| Avatar identity | Your Second Life UUID, your account name, your display name and the UUID of your profile picture. This is the core record. Note that it can be created without you signing up — tipping a jar is enough; see If you tip or donate. |
|---|---|
| Web login | A username you choose and a hashed password — we never store or see the password itself. Plus short-lived one-time login tokens. |
| No email address | We do not ask for one and we do not have one. That is why a forgotten-password link is sent to you as an in-world instant message rather than by email. |
Your work at a venue
| Jar sessions | When you log in and out of a tip jar, at which venue, in which job. |
|---|---|
| Tips and donations | The amount, the venue, the time, which staff member it went to, and who paid it. See If you tip or donate — that record is about the payer as much as the recipient. |
| Roles and scheduling | Which venues you have access to, your jobs and rank, events you are booked for, shift acknowledgements, and cover requests. |
| Your settings | Your stream URL, jar preferences, notice templates and similar configuration. |
If you tip or donate
Tipping a jar is the most common way people end up in our records without ever having signed up for anything, so it gets its own section.
| The payment record | When you tip a jar or donate to a fundraiser we store your avatar identity alongside the amount, the venue, the time, and which staff member received it. Venue owners and managers can see this on their tips page, and the staff member can see who tipped them. |
|---|---|
| An account record for you | The same moment also creates a basic record of you — your UUID, your avatar name, your display name and when you were last seen — so that your name can be shown instead of a UUID. You get this record by tipping, not by signing up. It carries no password and no login until you create one. |
| How long | Payment records are kept indefinitely — they are the venue's books, and venues need their history. If you would rather not be in them, ask us and we will strip your identity out of them; see Your rights. |
If you visit a venue that runs XTech
Tipping is not the only way. If a venue you visit runs the system, some or all of the following may also be recorded, again without you needing an account:
| Visits | If the venue's server is running: your avatar name, when you arrived, when you left, and how long you stayed. This is an attendance record, per person, per venue. |
|---|---|
| Greetings | If the venue runs a notice bot with auto-greet: that you were greeted, and when — so the bot does not greet you again five minutes later. |
| Instant messages | If you IM a venue's notice bot, the text of your message is stored, along with the bot's reply, so venue staff can read and answer it. Do not send a bot anything you would not want the venue's staff to read. |
| Group invites and inventory | Group invites sent to you or received from you, and inventory offers made to a bot — sender name and any attached message. |
| Quiz answers | If you play a pub quiz at a venue: your answers and your score. |
Technical and operational
| Failed logins | Your IP address and the username tried, for a short window, so we can rate-limit brute-force attempts. An IP address is personal data. |
|---|---|
| Web server logs | Standard access logs on our server: IP address, the page requested, the time. |
| Audit trail | Administrative actions taken in the dashboard — who changed what, and when — so that changes to a venue can be accounted for. |
| Backups | Database backups necessarily contain copies of the above until they age out. |
Why we hold it, and on what legal basis
| To run the service you asked for | Contract. You cannot be paid your share of a tip, be rostered for an event, or log into the dashboard without us storing who you are and what you did. |
|---|---|
| To let venues run their venue | Legitimate interests — the venue's, in operating a business, balanced against yours. This covers visit records, greet logs, bot IMs, and the record of a tip or donation where you are the payer rather than the recipient (a venue needs to know what came in, and from whom, to run its books and spot a chargeback or a mistake). If you object to being recorded by a specific venue, see Your rights. |
| To keep accounts secure | Legitimate interests. Login rate-limiting, audit logs, server logs. |
| To keep venue accounts straight | Legitimate interests. Aggregate tip and visitor totals are retained in a form that no longer identifies anyone. |
How long we keep it
These are enforced automatically by scheduled jobs in the database, not by anyone remembering to run something. Anything not listed is kept for as long as your account exists, and goes when your account goes.
| Failed login records (with IP) | 1 day |
|---|---|
| Abandoned uploads and pending registrations | 1 day |
| Live instant-message relay sessions | 7 days |
| Linked Discord event records | 30 days |
| Bot instant messages, in and out | 90 days |
| Group invites sent and received; inventory offers | 90 days |
| Venue digest and notice logs | 90 days |
| Greet log | 90 days by default — each venue may set its own, between 7 and 365 days |
| Shift acknowledgements | 180 days |
| Login and authentication audit entries | 90 days |
| All other audit entries | 12 months |
| Visit records (per person) | 400 days |
| Quiz answers | 400 days |
| Tips and donations — including who paid | Indefinitely. These are the venue's books and are not pruned on a schedule. On an erasure request the rows survive with the identity stripped out: the venue's totals stay correct, but the row is no longer about anyone. |
| Jar sessions and event history | Kept for the venue's records, on the same basis and with the same treatment on erasure. |
Daily visitor counts per venue are kept indefinitely. They contain no avatar identities — the per-person rows behind them expire at 400 days as above.
Backups: deleted data persists in backups until they rotate out, normally within 30 days. Web server access logs are rotated on a similar cycle.
Who else sees it
| Your venue's owner and managers | They can see their staff's records and sessions, every tip and donation at their venue including who paid it, and their venue's visit, greet and IM logs. That is the point of the dashboard. Staff can see who tipped them. |
|---|---|
| Our UK hosting provider | A processor, under contract. They hold the servers the data sits on. |
| Linden Lab | Instant messages, group notices and L$ payments travel over Second Life's own infrastructure. Anything sent in-world passes through Linden Lab (US). |
| Discord | Only if your venue links a Discord server. Event details, cover calls and relayed questions are then sent to Discord Inc. (US) under their own terms. |
| Your own notice bot | Venue owners run their own bot on their own hosting. Data handled by that bot is on infrastructure they chose, not ours. |
| Content delivery networks | The dashboard and these docs load fonts, icons and JavaScript libraries from Google Fonts, jsDelivr, cdnjs (Cloudflare) and code.jquery.com, and Second Life map images from Linden Lab's CDN. Loading a file from those hosts reveals your IP address and browser to them. They receive nothing else, and set no cookies for us. |
| Us, when we have to | A global administrator can open a support ticket by viewing the dashboard as you — the only reliable way to see a problem you are reporting. It is strictly read-only: nothing can be changed, sent or deleted while doing it, and both starting and stopping are recorded in the audit log against the real administrator, never against you. We do this to fix things, not to browse. |
| Nobody else | We share data with no one else, unless we are legally required to. |
Some of the above are outside the UK. Transfers rely on the UK's adequacy arrangements or the International Data Transfer Addendum, as applicable to each.
Where your name can appear publicly
Most of the system is behind a login. Three things are not, and if you are on a venue's roster they can carry your name onto the open web:
| Event boards | A venue can publish a schedule board at a link like
/board/<token>. Anyone holding that link can read it — there is
no login. Events the venue has marked public are shown, with the name of the DJ or
host booked for each one. |
|---|---|
| Calendar feeds | The same link serves a subscribable .ics calendar. Once someone
subscribes, the line-up lands in their own calendar app and is outside our control
and the venue's. |
| Venue info pages | A venue's public information page can list its staff and its schedule. |
A venue can revoke a board link at any time, which darkens the board and the calendar feed together. Copies already taken — a cached page, a calendar someone subscribed to — cannot be recalled.
Cookies
The dashboard sets one cookie: a session cookie that remembers you are
logged in. It is marked Secure, HttpOnly and
SameSite=Lax, scoped to .xtech.dev, and it expires when you close
your browser. It is strictly necessary to log in at all, which is why there is no cookie
banner — there is nothing to consent to or refuse.
There are no analytics cookies, no advertising cookies, and no third-party trackers. This documentation site sets no cookies whatsoever. If we ever add analytics, this section changes first and you will get a real choice.
How it is protected
- Everything is served over HTTPS. Passwords are stored only as hashes.
- In-world objects never talk to the web directly — only your venue's XTech Server does, and every message it sends is cryptographically signed. A tip jar holds no credentials worth stealing.
- Repeated failed logins are rate-limited by IP.
- Access to a venue's data is checked on every request, per person and per role.
No system is perfect. If you find a security problem, please tell us rather than publishing it — see Contact.
Your rights
Under UK GDPR you can ask us to:
| Tell you what we hold | A copy of your data, free of charge. |
|---|---|
| Give it to you in a portable form | Your records exported as a machine-readable file, so you can keep them or take them elsewhere. Venue owners don't need to ask — Manage Venue → Export Your Records downloads the venue's tips, payouts, shifts, staff, events and visitor counts on the spot. Everything else is on request. |
| Correct it | Most of it you can fix yourself in the dashboard; ask us for the rest. |
| Delete it | We remove your identity everywhere. Venue accounting rows survive with your identity stripped out, which is permitted because you can no longer be identified from them. |
| Object or restrict | Including objecting to a specific venue's greet log, visit record or bot IM history. You do not need an XTech account to ask. |
| Complain | To us first, please — but you can go straight to the Information Commissioner's Office if you prefer. |
There is no automated decision-making and no profiling here. Nothing about your access, your pay, your bookings or your standing at a venue is decided by an algorithm — a person at the venue decides, using the system as a record.
We answer within one month. There is no self-service delete button on purpose — deletion is irreversible and takes tips, sessions and event history with it, so a human confirms it with you first. Ask and it gets done.
We will check you control the avatar in question before acting — usually by replying to an in-world IM from that avatar. We are not going to delete someone's history because a stranger emailed us their name.
If you run a venue
When you set up a venue, you decide what the system records about your staff and your visitors. That makes you a controller for that data, alongside us, and it comes with obligations you should know about:
- Tell people. If you run auto-greet, visitor tracking or a bot that logs IMs, say so — a line in your venue's profile or a notice at the landing point is enough. Linking to this page covers the detail.
- Keep it proportionate. Set the greet-log retention to what you actually need. Don't switch on visitor tracking to keep tabs on one particular person.
- Don't mass-invite or mass-IM people who never asked. Beyond being unwelcome, unsolicited bulk messaging breaches Second Life's own rules and will get your bot banned. Invite people who opted in.
- Your staff's data is your responsibility too. Only give dashboard access to people who need it, and remove it when they leave.
- Pass requests on. If a visitor asks you what you hold about them, or asks to be forgotten, tell us and we will action it across the system.
The same applies if you run your own notice bot: it is your hosting, your bot account, and the data it caches is in your hands.
Children
Second Life is for adults. We do not knowingly hold data on anyone under 18, and the service is not directed at children. If you believe we hold a child's data, tell us and we will delete it.
Changes to this policy
If we change anything that matters — a new recipient of your data, a materially longer retention period, analytics — we will update the effective date at the top and announce it in the dashboard. Minor clarifications will just be edited in.
Contact
For anything in this policy — a copy of your data, a deletion, an objection, or a security report:
| privacy@xtech.dev | |
| In-world | IM Xevian Wake in Second Life
(5c0970c2-5b77-400c-9328-1ca1995ec565 — check the UUID if you are not
sure you have the right avatar). This is usually the quickest route, and it proves
you control your own avatar in one step. |
You can also complain to the Information Commissioner's Office, the UK's data protection regulator, at ico.org.uk.