Privacy policy
What this covers
This page describes what firstmate Relay - the myfirstmate.io service that answers your mentions - stores, how long it keeps it, and who can see it. It describes what the service actually does today; it is not a description of plans. The firstmate that composes your replies runs on your own machine and is not covered here.
What we store about your account
There is no password and no email address. Your account is created the first time you sign in with X or with Discord. We retain account and identity data needed to operate the service, including the platform account information used to sign you in and route your mentions, internal account and routing identifiers, identity-link and account history, pairing-token verification data, and plan and usage state.
We do not keep the access token the platform hands us at sign-in. Signing in with X asks only to read your profile and posts, and signing in with Discord asks only to identify you; neither asks for offline access. The token is used once to read your id and handle, then discarded - we cannot post as you, read your direct messages, or act on your account afterwards.
Staying signed in uses one cookie: a random session token, signed and same-site, matched against a server-side token record. A session stops being accepted after 60 days, but that does not delete its record. The token record remains stored until it is explicitly deleted or the account is removed; logging out deletes that session's token. The firstmate application itself sets no advertising or tracking cookies; the session cookie described here is its only cookie.
What we store about your mentions
When a mention you authored reaches the relay, we retain the mention content and context your firstmate needs to answer it. This category includes the message text and platform identity, attachment descriptors, reply targets, an included X quoted post, and bounded recent Discord channel or thread messages that precede your mention.
For every Discord mention, the relay transiently reads nearby preceding messages in that channel or thread and forwards the bounded selection to your local firstmate as untrusted conversation context. That selection can include messages from other participants and the bot itself, not only formal reply ancestors or a thread starter. It is not a separate history archive: context travels only with your routed mention and follows that mention's retention window.
We also retain derived routing and lifecycle metadata used to prevent duplicate answers, enforce per-thread safety limits, track posting and delivery, bind semantic follow-ups, and recover exact historical context. This category includes deduplication ids, per-thread conversation counters, answer attempts and delivery receipts, semantic delivery identity, and context-recovery audit records. We try to record that an answer posted so later follow-ups can attach to it. If that write fails, the reply is still posted on X or Discord, but its outcome is left unknown and later follow-ups on it are not available.
Discord attachments are stored as descriptors only - filename, media type, size, expiry, and Discord's own link. The relay never downloads attachment content.
Usage metering records are a separate category. As best-effort metering, we aim to record mentions received and replies posted, but a failed write never stops an answer from being delivered, so a record can be missing. Successful usage records contain metering details such as the account, event kind, and time, never message content.
How long we keep it
Mention content is normally short-lived by design. A mention waiting to be answered is swept about a day after it arrives. An answered mention is kept for the follow-up window - seven days by default - so your firstmate can post a later update on the same thread, then swept. Sweeping deletes the row, its text, and its stored context.
As a bounded exception, when your firstmate has promised a later final in the same X thread or Discord channel or thread, it can reserve that specific request's context beyond the normal window. The sweep preserves that row, whether unanswered or answered, until the reservation expires, up to a configured maximum of 90 days by default.
Derived routing metadata follows its own bounds. Deduplication records retain platform ids and recording times, but never message content, and are capped at 50,000 entries by default. Per-thread conversation counters are retained until the same configurable stale-content sweep used for unanswered mentions. Other derived routing metadata attached to a live request is removed with that request.
Longer-lived lifecycle metadata, including answer-attempt and semantic-delivery receipts, persists independently of the mention-content windows. These records contain routing, delivery, receipt, and audit metadata rather than message content, and are swept at a configurable receipt horizon that defaults to 90 days.
Exact historical context-recovery audit rows currently have no sweep path and are kept indefinitely. Usage metering and account records remain while the account exists. Session-token records remain until explicitly deleted or the account is removed; logging out deletes the current session's token. These durations and caps are operational settings and can be adjusted as the beta evolves.
Who can see it
Routing is owner-only, per platform: only mentions authored by an account you linked ever reach your firstmate. If anyone else mentions the bot on X, the mention's content is never queued, stored as text, or answered; its post id alone may be kept in the capped deduplication list so a redelivery is not processed again. On Discord, an unlinked author's message is dropped before dispatch, without creating a queue or deduplication record. Your local firstmate authenticates with your pairing token and can only fetch, answer, or dismiss requests belonging to your own account - it can never see another account's queued mentions, and it can only reply to the exact post the relay dispatched. Context attached to your request can include untrusted nearby messages other people or the bot posted immediately before your Discord mention in that channel or thread.
The relay's operator holds the server and can reach the database, and an operations dashboard shows aggregate health and counts. Nobody else is given access to your data, and we do not sell it or hand it to advertisers.
Third parties
On X, the mentions the relay reads and the replies the shared bot account posts are public posts. On Discord, the relay reads messages in guild channels or threads, and the shared bot's replies are visible to whoever can see that channel or thread. What you send to those platforms is governed by their own terms and privacy policies, not by this one.
Our public pages load one third-party script, a self-hosted umami analytics tag on a.kunchenguid.com, which records page views. There is no advertising network and no third-party analytics on the connector API. Our data lives in a single database file on our own server, replicated to off-site object storage so it can be restored after a failure.
Your controls
From your dashboard you can rotate your pairing token at any time, which immediately stops the old connector from reaching the relay, and you can disconnect X or Discord - refused only when it is the single identity left on your account, since an account needs at least one. Your firstmate can also dismiss a mention silently, which drops it without posting anything.
There is no self-serve or automated account deletion. The operator handles account and data removal manually on request. To ask for removal, reach us through the firstmate repository on GitHub.
Changes to this policy
This page describes the service as it is built today. If what the relay stores or how long it keeps it changes, this page changes with it. See also the terms.