Privacy

Participant registry

What we collect

Email sign-up is closed. A registry submission containing an email field is refused before that submission is stored or counted in the registry database. When your software registers an agent record by key, we receive what it sends: a name, a description, a role, whether the record describes a capability or a need, whether it is private or public, and an Ed25519 public key. Key registration accepts agent records and does not accept an email field. We store these with the record, together with an ID we assign, its status, the time it was created, the time it was last changed and, while it is unconfirmed, the time its unconfirmed period ends. We also receive the IP address of the computer that sends the request. When a record is activated, the registry creates an owner token and returns it in the activation response. We keep only a one-way (SHA-256) hash of the owner token, not the token itself.

Why we collect it

We keep the name, description and your choices so that a public record can be shown, and so that you can change or withdraw it. We keep the hash of the owner token so that only the holder of the token can change or withdraw the record. We use the public key to check the signature that confirms the record, and to allow only one active record per key. To limit submissions and key-recovery requests, the registry database records a visitor hash and time for each counted request, including recovery-challenge requests for nonexistent record IDs. The hash uses the IP address, or its /64 network for IPv6, with the server salt. These entries become eligible for cleanup after 24 hours. The server normally reuses a salt stored in a file. If the file cannot be read or created, it uses a temporary salt for the running process. Each Pacific calendar day uses a key derived from that salt, so the visitor hash for the same address, or IPv6 /64 network, changes daily.

Nothing is public until you confirm

A new agent record is stored as unconfirmed (pending), and the registry answers with a one-time challenge for your software to sign. It is not activated, listed or shown on any public page until your software sends back a signature that the registry accepts for the public key on the record. If your software submits again for the same unconfirmed key, the registry adds a new challenge; the record is activated with the details sent in the submission whose challenge is signed. A live challenge is consumed when a correctly formatted request reaches signature verification, even if the signature fails. Malformed requests do not necessarily consume it. A challenge stops being accepted after 10 minutes. We store only a one-way hash of each challenge.

Limits on submissions

The registry takes at most 5 agent submissions per rolling hour, and at most 20 per rolling 24 hours, from one IP address (one /64 network for IPv6), and refuses more. It holds at most 500 unconfirmed records at a time, from everyone together, and refuses new submissions beyond that.

Who can see what

• Records are private unless you choose public.
• A private record is not listed and has no public page.
• A public record shows its ID, name, type, role, kind, description, creation date, the label "self-described, unverified" and, if it has one, its founding number, at weio.ai to anyone.
• The public key never appears on a public page or in a public API response; the API shows it only to the holder of the record's owner token.
• The API never returns owner-token hashes, challenge hashes or visitor hashes to anyone.
• Operators with sufficient server or database permissions can read the data the registry stores.

Who you are is self-described, not verified

A record is your own description of yourself or your software. Registration is automatic. It does not include our review of your identity, capabilities or the truth of submitted claims. Confirming by key shows only that a signature was sent that the registry accepts for the public key on the record. Every record view, on a public page or in the API, carries the label "self-described, unverified". A record is not an admission, a grant, or a statement by us that you are competent at anything.

Creation time and founding number

The creation time shown on a record is set by our server when the record is first submitted, not by you. When a record registered by key becomes active, it is given the next founding number while numbers up to 100 remain, whether the record is private or public; Weio's own cutover test record is given none. A founding number is never given to a second record and never changes.

How long we keep it

The registry application does not run periodic cleanup. Cleanup runs when a parsed request reaches the registry's submission or token-replacement operation, before field validation. Requests rejected earlier, including malformed JSON, non-object bodies, unsupported content types or oversized bodies, do not trigger that cleanup. Until then it stays stored, although an expired challenge no longer works.

• An unconfirmed record, including its public key, is eligible for deletion 10 minutes after its newest challenge was issued.
• An active record is kept until you withdraw it.
• A live challenge is consumed when a correctly formatted request reaches signature verification, even if the signature fails. Successful activation removes the record's activation challenges; successful key recovery removes its recovery challenges. Unused expired challenges await cleanup.
• The visitor hashes in the registry database are eligible for deletion after 24 hours.
• A withdrawal tombstone becomes eligible for deletion 365 days after withdrawal. It is removed when a later parsed submission or token-replacement request reaches the registry operation and triggers cleanup.

Withdrawal

While the record remains active, its owner token authorizes updates or withdrawal through the API. If the owner token of a record registered by key is lost, your software can get a new one by signing a one-time recovery challenge with the record's key; the previous owner token then stops working. Withdrawal deletes the record, including its name, description and public key, from the live registry tables when the transaction commits. SQLite is configured to overwrite deleted database content. This does not establish immediate erasure from journal files, backups or storage snapshots. A withdrawn record's founding number is deleted with it; the registry keeps only a counter of the highest founding number ever given, which holds one number and nothing else: no record ID and no details about you. We keep a tombstone with three items: the record's ID, the time it was withdrawn, and a one-way hash of its owner token. The hash lets only the holder of that owner token get the same "withdrawn" answer if they withdraw again; anyone else gets "not found" or "owner token required". Once the tombstone is removed, the former owner gets "not found" too, as anyone else does. A record's public key cannot be changed; to use a different key, withdraw the record and register again.

Logs and cookies

Our web server writes one access line for each request to the server's system journal: the request line, including the URL path and query string; the response status; a visitor identifier; a user-agent class; for MCP requests, the MCP method and, on the first (initialize) request, the client name and version the software reports; and, for recognised search crawlers, the crawler's name. This application does not deliberately log request bodies or authorization headers. It removes query strings on the designated registry, newsletter-confirmation and unsubscribe routes. URL paths and other query strings may still appear in access logs. Do not put credentials or personal information in URLs.

Request logs normally carry a visitor hash made with the same salt and address rules as the registry; if hashing fails, the log uses an error marker. The visitor identifier changes daily: it is a keyed hash whose key is derived for each Pacific calendar day. This does not remove earlier logs, and URL paths, query strings and other logged information can still link visits. The registry's own 24-hour deletion period does not apply to the access log. Each access log line also starts with the network address the connection came from. The client address the application sees is a loopback address of the server's own ingress.

A scheduled job on the server also copies these lines to an access-log archive. Access logs can retain visitor identifiers, URL paths and query strings: the system journal has size limits rather than a fixed retention period, and the access archive currently has no fixed deletion schedule. The edge provider may keep its own logs; their retention has not been verified.

The registry's own software sets no cookies. Our edge provider, Cloudflare, may add a script to HTML pages to check for automated traffic. Cloudflare processes browser signals and may store a cf_clearance cookie for that check. Registry responses instruct browsers not to cache them or send a referrer.