Privacy should be understandable.

Who operates Dibbit

Future Enterprises Corporation operates Dibbit. Privacy questions and rights requests can be sent to privacy@dibbit.ai.

Information Dibbit handles

• Public address data: your @name, agent name, Dibbit ID, profile, and public address URL.
• Account data: email address, authentication records, account identifiers, and recovery events.
• Messages: sender name, purpose, subject, timing, message content, replies, state, and timestamps.
• Live Slates: the current fields, proposed one-field changes, confirmations, cancellation or expiry state, and version history.
• Memory: short facts and categories that the verified owner deliberately adds or confirms, together with owner-edit provenance, confirmation time, revision number, and timestamps. Memory v1 does not scrape accounts, infer facts, or create facts in the background.
• Private images: a JPEG, PNG, or WebP original held in a private quarantine area while it is checked, a re-encoded sanitized image, file type and size, dimensions, processing state, rejection reason, timestamps, and—only when the owner requests it—an AI-generated visual summary.
• Billing data: Stripe customer, Checkout, subscription, and price identifiers; subscription status; paid-period and cancellation state; and limited webhook or cancellation records. Stripe collects payment details. Dibbit does not store a complete payment-card number.
• Identity-check data: a Stripe Identity verification-session identifier, the check's status, relevant bounded error code, checked date, expiry date, and event timestamps. Stripe collects and processes the ID document and live-face image in its hosted flow. Dibbit's application does not request or store the document image, selfie, document number, birth date, or street address returned by that check.
• Trust and contact data: your inbox contact policy and, on each message, whether the sender had a current Dibbit identity credential when it was sent. The recipient sees that bounded credential status and check date, not the sender's identity document.
• Protected Alias data: the requested alias, its Dibbit owner and agent, Checkout and payment identifiers, license status, and license dates. A paid alias is a namespace license, not an identity, affiliation, or trademark credential.
• Specific-ID interest: the five-character ID requested, whether the request is personal or business-related, an optional reason, a maximum amount the requester says they might consider, request status, and timestamps. This records interest only; it is not a bid, reservation, allocation, purchase, or promise to offer the ID, and no payment is taken.
• Security and delivery data: request metadata, one-way keyed hashes used for capability lookup, replay control, rate limiting, and abuse prevention, plus content-free notification status and provider receipt IDs.
• Growth attribution data: keyed hashes of expiring address-share links and temporary internal links between a share, a resulting first message, and a later claimed address. Raw share tokens are not stored in the Dibbit database.
• Connected-agent data: the identity of an approved OAuth client, the standard account-identity scopes it requested, the time access was granted, and the authorization grant needed to let the connected agent use Dibbit's fixed tools.
• Aggregate usage data: privacy-redacted page routes, coarse browser, device, and regional information, a referring site or page when supplied, and content-free events such as address claimed, a share action signal, or message delivered. A browser share signal is directional and does not prove that another person received or opened the link.

A sender's private return link contains a random secret after the URL hash sign. Browsers do not send that fragment with the initial page request. Dibbit stores only a one-way keyed digest of the secret.

How the information is used

Dibbit uses this information to create and recover accounts, route messages, show private conversation history, operate Live Slates, notify an address owner of new inbound messages, prevent duplicate writes, enforce limits, investigate abuse, maintain service security, comply with law, improve reliability, and generate the named agent's bounded acknowledgement or one clarifying question for a new message. Dibbit also uses identity-check outcomes to display literal trust facts and enforce an owner's chosen contact policy; uses Protected Alias records to operate the paid namespace license; and aggregates specific-ID interest to understand demand without creating an auction or sale. When an owner deliberately connects a compatible outside agent, Dibbit also uses the approved authorization to provide only the fixed tools shown on the consent screen. Owner-confirmed Memory records are used only to display and manage that owner's saved facts. Dibbit does not use Memory v1 to browse, infer new facts, or send messages on its own.

Dibbit does not sell personal information or share it for cross-site behavioral advertising.

No shared-model training at launch: Dibbit does not use private message, Live Slate, Memory, or private-image content to train a model shared across users or a general-purpose AI model. If that practice changes, Dibbit will update this notice before the change and request consent where the law requires it.

Optional private-image summary: if the owner requests a summary for a particular image, Dibbit may send the sanitized image through Vercel AI Gateway to an OpenAI model hosted on Microsoft Azure. Dibbit requests zero data retention and disallows prompt training for that call. A summary can be incomplete or wrong and is not identity, safety, legal, medical, or authenticity verification. If the owner does not request a summary, Dibbit does not send that image for this AI use.

Initial agent reply: when a visitor sends the first message in a thread, Dibbit may send its purpose, subject, timing, and content through Vercel AI Gateway to an OpenAI model hosted on Microsoft Azure. The model may select only from Dibbit's reviewed question templates. Dibbit requests zero data retention and disallows prompt training for that call. The surrounding acknowledgement is generated by Dibbit's fixed rules, the result is labelled as AI, and the model is not permitted to approve, promise, negotiate, book, pay, or speak for the address owner. If that route is unavailable, Dibbit uses a fixed fallback instead.

Public discovery and launch analytics use Vercel Web Analytics. Before an event is sent, Dibbit redacts its own reported dynamic URLs, removes query strings and URL fragments, and excludes shared-link redirects, private thread, Group Answer, owner-inbox, and authentication routes. Vercel Web Analytics may still receive and store the referring site or page associated with an initial visit or custom event. Custom events never include message content, email addresses, capability secrets, or Dibbit IDs.

Recognized campaign links may record only a fixed source, medium, and campaign label from Dibbit's published launch vocabulary. Unknown or free-form campaign values are discarded, and the full query string is removed from the reported page URL.

Legal bases for processing

Where applicable law requires a legal basis, Dibbit processes information for the following reasons:

• Contract: to create and recover an account, claim an address, route a message, provide a private reply thread, operate a Live Slate, and deliver requested account features.
• Legitimate interests: to secure the service, prevent fraud and abuse, troubleshoot failures, measure whether address shares lead to messages or claims, improve reliability, and establish or defend legal claims. Dibbit considers the effect on users before relying on this basis.
• Consent: when Dibbit asks permission for an optional use or when local law requires consent. Consent can be withdrawn for future processing.
• Legal obligation or protection: to comply with enforceable legal duties and to protect people, rights, and the service from a serious security or safety threat.

Who can see it

Public address data is visible to anyone. Account and owner-inbox data is available to the verified account owner. Anyone with a complete private return link can read and reply in that one thread. Participants in a Live Slate can see its current fields, proposed changes, and confirmation state.

An outside agent that an owner approves can use Dibbit's fixed tools to see that owner's public address, read that owner's Dibbit inbox, and send a reviewed reply. The tools do not expose Dibbit's structured return-contact field or the sender's private return-link capability. They do expose the sender's name, subject, details, and message text, which can include an email address, phone number, or other information the sender chose to type there. The connected service receives the owner's Dibbit account user ID and email address in its OAuth sign-in credential. Supabase also requires a phone claim; it is empty in Dibbit's current email-only sign-in. Dibbit removes optional profile, application-metadata, and authentication-method claims from delegated credentials. Any additional standard identity scopes requested by the service are listed on the consent screen. The outside agent provider processes this information and the authorized Dibbit tool results under its own privacy terms as well as the owner's instructions.

Dibbit uses infrastructure providers, including Vercel for hosting, analytics, and AI Gateway routing, Microsoft Azure for the bounded initial agent question and an owner-requested private-image summary using an OpenAI model, Supabase for database, private object storage, and authentication, Resend for generic owner notification email, Cloudflare for security, Stripe for Checkout, subscriptions, billing management, and the optional hosted government-ID and live-face identity check, and monitoring vendors, only as needed to operate the service. Information may also be disclosed when required by law or necessary to protect users, the public, or the service.

Dibbit limits access to nonpublic content to authorized personnel and contractors who need it for a specific support, security, abuse-review, reliability, or legal task. Their access is limited to the information needed for that task and is subject to confidentiality and access-control requirements. Dibbit does not routinely read private threads.

Cookies and browser storage

Dibbit uses essential first-party cookies to maintain sign-in, protect authenticated actions, remember an account or private response capability, prevent replay, and apply security limits. Authentication cookies follow the account session. A private Group Answer response cookie, where that feature is available, lasts up to 48 hours, and a local-only preview management cookie lasts up to 30 days.

When someone follows a Dibbit address-share link, Dibbit may set a signed first-party attribution cookie for up to 24 hours. After a first message, a second signed cookie can connect that message to a later address claim for up to seven days. These cookies contain internal IDs and expiry times, not raw message content. Basic messaging still works if this attribution is unavailable.

Dibbit uses sessionStorage to keep a sender's recent request submission, receipt, and private return capability available in the same browser tab. Where Group Answer is available, it also keeps that organizer's management capability and invite URL in sessionStorage. This storage ordinarily ends when the tab's browsing session ends.

Dibbit uses localStorage only for device preferences, such as pausing hero motion or hiding a Group Answer card. Those choices remain until they are changed or browser storage is cleared. Dibbit does not use advertising cookies at launch.

Retention and deletion

Message content, the current Live Slate snapshot, and its version snapshots are scheduled for bounded redaction after their stated retention period, currently 90 days, unless a shorter period is shown or law requires preservation. Minimal non-content state, security, and audit records may remain longer.

Public address and account records remain while the account is active. When account retirement is prepared, Dibbit disables the profile and address ownership link, redacts message and Live Slate content, revokes private reply capabilities, and removes address-share attribution linked to the account. A blocked thread's capability is permanently revoked even if minimal event metadata remains.

An owner-confirmed Memory fact remains until the owner edits it, uses Forget, or deletes the account. Forget hard-deletes the active Memory record rather than retaining a hidden fact-revision history. Where a restricted disaster-recovery backup exists, a deleted record may remain temporarily until that backup ages out and is not available through the product during that period.

A private image original is kept in a nonpublic quarantine area only for processing and is removed after successful processing or a handled rejection. Upload reservations expire after 30 minutes, and scheduled cleanup removes abandoned quarantine objects after expiry and processing jobs that remain unfinished. The sanitized image and any owner-requested summary remain until the owner deletes that image or the account. Deletion removes the private storage objects before Dibbit finalizes removal of the image metadata; if storage cleanup fails, the deletion remains retryable. Short-lived signed delivery URLs and delivery caches may expire after the underlying object is removed.

Stripe and Dibbit retain subscription, cancellation, transaction, and related billing records for service administration, disputes, fraud prevention, tax, accounting, and other legal obligations. Account deletion revokes Dibbit Plus access and queues cancellation of an active Stripe subscription, but does not require Stripe or Dibbit to erase a record that must be retained for one of those purposes.

Dibbit keeps the bounded result and audit state of an identity check while the credential is current and as needed for fraud prevention, disputes, legal obligations, or account security. Credential status can expire or be revoked. Stripe retains identity-verification data under its own terms and configured retention controls. Protected Alias payment and license records, and specific-ID interest records, are retained while needed to operate the request, license, accounting, rights-dispute, abuse, and legal processes. Account deletion ends public credential and alias display; legally required transaction or audit records may remain.

Unused address-share hashes are deleted after they expire through the retention process. Attribution attached to a real message is removed when that source request is purged, or immediately when the linked account is retired.

A signed-in owner can delete their account from the account page. Deletion disables sign-in, the public profile, inbox access, and private reply capabilities; removes owner-confirmed Memory records and private image objects and metadata; and revokes paid feature access while any Stripe cancellation is processed. The @name and Dibbit ID retire rather than being assigned to somebody else. Preparing deletion immediately redacts message content, the current Live Slate snapshot, and its version snapshots. Minimal non-content state-machine, tombstone, security, audit, and legally required records may remain longer.

Residual records are kept only while a stated reason applies: preventing reuse of a one-of-one identifier, maintaining non-content state and replay protection, investigating an active security incident, resolving an active dispute, or meeting a specific legal duty. Dibbit deletes or de-identifies other residual records when that reason ends. A legal hold lasts only until the hold is released. The anti-reuse record for a retired @name or Dibbit ID is retained indefinitely because Dibbit promises not to reassign it; that tombstone does not retain account or message content.

Security and important limits

Dibbit uses access controls, keyed hashes, rate limits, and restricted server functions. Private-image processing checks the declared type, decodes the image, limits size and dimensions, strips metadata through re-encoding, and serves only the sanitized derivative. Those controls reduce risk, but no screening process detects every threat and Dibbit does not certify an uploaded file as lawful, authentic, or harmless. No system is perfectly secure. Current Dibbit Requests, Inbox replies, guest return threads, and Live Slates are stored server-side and are not end-to-end encrypted. Do not send passwords, financial account data, government identifiers, medical records, or other highly sensitive information through those features.

Sealed Chats are separate and release-gated. They remain unavailable unless Dibbit identifies the deployed Matrix operator, completes signed cross-platform device testing, and explicitly enables the native feature. If enabled, Sealed Chat message content would be encrypted and decrypted on participant devices. End-to-end encryption does not hide service metadata such as pseudonymous account and device identifiers, room membership, IP and access logs, timing, delivery activity, or ciphertext and media sizes from every system involved in providing the service.

Sealed Chat device verification would establish trust between the same account owner's Matrix devices; it would not establish legal identity, age, business status, reputation, or safety, and Dibbit does not present it as peer identity verification. Local logout and device wipe would remove native session and key material from that device, but would not remotely erase messages from another participant's device or guarantee revocation of an unreachable server session.

Cloud GoGo and connected outside agents cannot process Sealed Chat plaintext while it remains only inside the encrypted conversation. If a participant deliberately selects content to share with an AI or another service, that selected content leaves the Sealed Chat boundary and is processed under the disclosures for that service. A bridge to email, WhatsApp, iMessage, Telegram, WeChat, or another service does not preserve Sealed Chat protection by default.

Your choices and rights

Depending on where you live, you may request access, correction, deletion, portability, restriction, or objection. You may also appeal a denied request or complain to your local regulator. Contact privacy@dibbit.ai. Dibbit may verify your identity before completing a request.

Signed-in owners can also download a resumable, multi-part NDJSON export of the current address, operational inbox history, Live Slates, owner-confirmed Memory records, and private-image metadata and any retained optional summary available to their account before deletion. Private image files are not included in the NDJSON export; an owner can view or save an available image separately while the account is active.

A signed-in owner can review and revoke outside-agent authorizations from My messages. Revocation prevents that OAuth grant from making new Dibbit tool calls; it cannot erase information the outside provider already received while the connection was authorized.

Browsers may send Do Not Track or Global Privacy Control signals. Dibbit does not sell personal information or share it for cross-site behavioral advertising, so there is no sale or advertising-sharing activity for those signals to opt out of at launch. Dibbit does not otherwise change the service in response to Do Not Track, which has no uniform standard. If Dibbit's practices change, it will honor legally required opt-out signals.

Age limit

Dibbit is for people 18 or older. A parent or guardian cannot approve use by someone younger. If Dibbit learns that it received personal information from someone under 18, it will take reasonable steps to delete or restrict it. Report a concern to privacy@dibbit.ai.

International transfers

Information may be processed in the United States and other countries where Dibbit and its service providers operate. Those countries may have different privacy laws. When applicable law restricts a transfer, Dibbit uses a recognized safeguard available for that transfer, such as an adequacy decision or approved contractual clauses, and applies additional protections when required. Contact privacy@dibbit.ai for information about the safeguard relevant to a request.

Changes

Material changes will be posted here with a new effective date and, when required, an additional notice. This version is effective August 28, 2026.