Privacy should be understandable.

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 a one-way keyed digest of the secret. If the sender asks for reply alerts, Dibbit also keeps an encrypted copy of the secret so it can put the link in each alert, and erases that copy when alerts stop, the confirmation window passes, or the Request is blocked, expires, or is purged.

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, send reply alerts a visitor confirmed, 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. Email sent to a Dibbit address is reduced to a Request so the address owner can review it in the same inbox, with its email source and server-visible status shown. Authenticated first-party messages are routed from one active Dibbit @name to another on the same Request substrate so the recipient can respond and the sender can continue the conversation from Sent. Optional connected-source snapshots and explicit communication imports are used to provide the owner's bounded search and reading view; protected email replies use owner approval to authorize only the exact derived sender, recipient, content, and thread. Huddle information is used to admit participants, deliver and organize room items, build a deterministic source-linked catch-up, record RSVPs, enforce the host's controls and expiry, and investigate a reported problem. Huddle catch-up uses the room's structured item types, dates, state, and RSVP totals; it does not claim to determine a participant's tone, intent, truthfulness, or safety. Dibbit also uses identity-check outcomes to display literal trust facts and enforce an owner's chosen contact policy. The optional check is used only as an account-trust and sender-routing input and, if Dibbit offers the number ladder's identity check bonus and the owner separately agrees, counted once as 5 ladder credits; it is not used to verify a business, ownership of an @name or Protected Alias, reputation, conduct, qualifications, or safety. Dibbit 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 uses the base OAuth authorization to provide the four fixed address and inbox tools shown on that consent screen, including the tool that prepares an exact Dibbit-thread reply for the owner's review. Dibbit uses a separate, revocable communications grant only when the owner later selects the exact outside client and authorizes Requests, Sent, Protocol Mail, or individually selected Sealed Chat text. Outside-agent access to Connected copies is not offered in this release: no outside agent can list, search, or read Dibbit's saved Gmail copy, and Connected wake-up callbacks, Connected first-response drafting and automatic work on a connected Gmail account are not offered either. An outside agent's saved Requests, Sent, or Protocol Mail reply goes out without the owner's review of that reply only under an automatic-reply permission the owner separately turns on for that client. 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 uses number ladder data to record who invited whom, decide whether an invite qualifies, count each person and each contact only once, find invite fraud such as alternate accounts and invite rings, reserve stock when a rung is reached, show members their own progress, and let reviewers approve or deny a credit or rung. A keyed copy of the network hash from a qualifying Request helps reviewers notice many invites answered from one network. Ladder data is never used to route, deliver, list, rank, or prioritize messages, and a ladder number changes nothing about how an address is treated. Dibbit does not read your contacts or location for the ladder.

Name-rights review: Dibbit uses a submitted case to let an authorized human review an asserted relationship to a person, business, or organization name; decide whether to place, maintain, or release a hold on future or recycled claims; preserve an accountable review record; and, only after a review is admitted, show a neutral name-rights status on an affected public profile. A case does not prove identity, affiliation, endorsement, trademark rights, or legal ownership, and it does not transfer or suspend an existing @name.

Optional Gmail connection: Dibbit uses Google user data to let the connected owner retrieve and view the bounded recent or explicitly consented complete-history projection, load a supported file attachment on demand, and send a bounded live-search query to Google to view Google's matching results inside Dibbit. Live search does not add those results to the saved projection. When that owner selects one copied Gmail message, presses Translate, and explicitly accepts the in-product disclosure, Dibbit sends that selected copy and target language through Vercel AI Gateway to an OpenAI model hosted on Microsoft Azure. For that Translate call, Dibbit requests zero data retention and disallows prompt training. When included-agent assistance is available, the owner may separately request it for an exact reviewed Connected copy or a selected live Gmail result, sending bounded recent thread text, any files the owner selects for that request, the reviewed agent brief, and any included writing preferences through Vercel AI Gateway to an OpenAI model hosted on Microsoft Azure, requesting zero data retention and no prompt training. Automatic attention suggestions and reply drafts for a connected Gmail account are not offered in this release. These permissions are separate from the Google connection; they do not let an agent send, delete, mark read, or change Gmail mail. This assistance uses server-visible text and is not end-to-end encrypted. If the owner separately includes connected Gmail in Ask your inbox or Brief me, bounded copied Gmail text is sent to cloud AI only to answer that owner's question or write that owner's brief, as described below, and no answer or brief content derived from Gmail is stored. Outside-agent access to Connected copies is not offered in this release: no outside agent can list, search, or read Dibbit's saved Gmail copy, and Connected wake-up callbacks, Connected first-response drafting and automatic work on a connected Gmail account are not offered either. Revoking Google access and deleting Dibbit's saved Gmail copy are separate controls. Dibbit does not use Gmail data for advertising, shared-model training, credit decisions, surveillance, or sale. Dibbit's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Optional Gmail writing and organization: A read-only Gmail connection does not authorize writing to Google mail. Where these features are available, the owner must separately grant the relevant Google permission. Saving a draft happens when the owner chooses Create or Update Gmail draft; every send and mailbox or label change needs a separate review and confirmation. With Google's gmail.compose permission the owner can save and edit Gmail drafts, send a saved draft, and send a new message, a reply, a reply to all, or a forward. A message can have up to 20 recipients across To, CC and BCC and up to 10 attached files totaling 25,000,000 bytes. A forward includes the original message's sender, date, subject, visible To and Cc headers, and text; original Bcc recipients are not copied into the forward. It can include up to 10 original attachments the owner selects, and goes to the new recipients the owner enters. Dibbit shows the complete message, recipients and attachments for review and sends only after the owner confirms. With Google's gmail.modify permission the owner can archive or unarchive, mark read or unread, star or unstar, move to Trash or restore, mark spam or not spam, and apply or remove a custom label, for one message, up to 25 selected messages, or a whole conversation of up to 500 messages. The owner can also permanently delete a saved Gmail draft and create, rename, or delete a Gmail label. These actions change mail or labels in Gmail, not just Dibbit's saved copy. Each review binds the account and exact action to a digest and a short-lived confirmation. Changes to existing mail or labels also bind the reviewed state and targets; creating a label checks that its name is available. Sending and every mailbox or label change require recent owner sign-in; saving a draft does not. Google's gmail.compose permission itself allows an app to manage all drafts and send mail as the owner, and gmail.modify also includes reading and sending; Dibbit uses them only for the owner actions above. Dibbit keeps bounded operation records, including selected targets, action, review and outcome, to prevent a blind repeat when Google's response is uncertain. An included agent or an outside agent cannot grant the permission or confirm the action.

No shared-model training at launch: Dibbit does not use private message, Huddle, 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.

Live agent conversation: when the live agent is enabled for an address, a visitor at that public address can talk with the owner's named agent before sending a request. Each visitor turn uses up to two calls through Vercel AI Gateway to an OpenAI model hosted on Microsoft Azure, and Dibbit requests zero data retention and disallows prompt training for both. In the first call, Dibbit sends the agent name, the @name, the owner's chosen tone, the owner's written brief, any facts the owner allowed the agent to quote in chat, and the conversation from that browser session: the visitor's messages, any name the visitor gave, and the agent's earlier replies. That model only chooses the next step from fixed options and selects eligible facts by number. When the reply is in English, a second call writes the agent's short reply from the same conversation, the @name, the tone, and the step Dibbit chose. That call does not receive the owner's brief, those facts, or the agent name. In other languages, and when the request is ready for the visitor to review, the agent shows reviewed wording and the model at most suggests a request title. Before a written reply or title is shown, Dibbit checks it with fixed rules and shows reviewed wording instead if it fails, for example if it states a price, number, date, or availability for the owner, says what the owner thinks or will do, includes a contact route, link, payment app, or request for a credential or personal details, claims a booking, approval, payment, delivery, or other commitment, claims to be the owner, a human, or someone's staff, disparages anyone, or claims to verify identity. Facts the owner allowed the agent to quote are shown only as separate, exact quotes during chat. That choice does not list facts on the public door. These checks reduce mistakes but cannot rule them out: the agent is labelled as AI and may be incomplete or wrong. It is not permitted to approve, promise, negotiate a price, book, pay, verify identity, or reveal the owner's contact details, and Dibbit does not permit the model to reveal another contact route even if the owner's brief asks it to. The conversation ends in a request draft that the visitor reviews and sends through the ordinary request path, or in no request at all. Dibbit does not write the conversation to its database. A short-lived, Dibbit-signed copy of the conversation remains in the visitor's browser so the next turn can be verified. Dibbit stores durably only a request the visitor confirms, built from their attributed words, a fixed note that no commitment has been made, and a title the visitor can edit, which the model may suggest. If the first call or the route is unavailable, or the provider refuses either call, Dibbit shows the ordinary request form instead; if only the reply call fails, Dibbit shows reviewed wording for that turn. GoGo, Dibbit's official agent at /gogo, uses the same provider route when its AI replies are switched on: Dibbit sends only the visitor's current GoGo message with Dibbit's published product facts, with the same retention and training requests. The model only picks which of those facts to show; Dibbit quotes them exactly with a fixed follow-up, shows fixed product answers when the route is unavailable or no fact applies, and does not save GoGo messages. Where these features are not enabled, none of this data is sent.

Native recipient-agent conversation: where enabled, a signed-in owner can choose another person's configured agent and explicitly allow cloud processing before talking to it in the app. The same live-agent provider and review boundaries apply. Dibbit also supplies the sender's active @name and returns a short-lived signed conversation to the app, bound to that sender and the recipient's current agent brief. This does not read either person's private mailbox or Sealed Chats. A prepared Request remains unsent until the sender reviews it and uses the ordinary sending controls. If the agent is unavailable, the sender can review their unsent text instead.

Optional owner AI helper: when available, the native Agent tab can summarize, translate, explain, or draft from text you choose to type, paste, or share. Before a cloud conversation begins, you must allow cloud processing for that chat. Dibbit sends that text and a bounded recent conversation history through Vercel AI Gateway to an OpenAI model hosted on Microsoft Azure. Dibbit requests zero data retention and disallows prompt training for those calls. This is not end-to-end encrypted. This open-ended helper chat does not automatically read your Inbox, connected apps, or Sealed Chats, fetch pasted links, or send messages or perform external actions for you. Its suggestions may be wrong and require your review. This feature does not save a transcript in Dibbit's database. Clear chat removes the app's in-memory conversation and resets its cloud permission; it does not recall requests already processed by service providers. Content-free usage limits and operational or security metadata may still be retained as described in this notice. When cloud AI is disabled or you have not allowed it, product help does not invoke a model.

On-device agent memory: in native builds that include this feature, you can deliberately save short notes in GoGo and search them on that phone. This is separate from server-backed Memory. Notes, original wording, revisions, timestamps, time zone, and any derived date are kept in protected device storage, separated by Dibbit account. Saving or searching these notes does not send their contents to Dibbit servers, an AI model, or another device. Relative dates are interpreted from the recorded note context; the feature may not understand an expression and does not establish that an appointment actually exists. An explicit calendar action opens your device's event editor for review. Saving there is handled by your calendar app and its configured account.

Phone-only notes remain after ordinary sign-out but are unavailable in another Dibbit account. You can delete them in GoGo or export them using the device's share controls. Exporting can disclose the notes to the destination you choose. Account deletion on this device removes its local notes before retiring the account; local cleanup can finish even if the server request later fails. Dibbit cannot remotely erase offline devices or exported copies. Phone-only notes are not included in server account exports and have no Dibbit cloud backup or cross-device recovery. Removing device storage can lose them, and uninstalling alone is not a reliable deletion method on every platform. Use the in-app delete controls before giving up a device.

Optional Request translation: when a visitor or owner presses Translate for a particular Request message, Dibbit may send that one message and the selected target language through Vercel AI Gateway to an OpenAI model hosted on Microsoft Azure. Dibbit requests zero data retention and disallows prompt training for that call. The translation is labelled, may be incomplete or wrong, and never replaces the stored original or creates authority to approve, promise, pay, book, disclose, or take another action. Dibbit does not send a Request message for this purpose unless the translation control is used.

Native message actions: when the accepted native build offers them, a message tap can expose translation, calendar, labelling, and drafting controls. Only after the user selects Translate and accepts its in-product disclosure, cloud translation sends the one selected server-visible Request or Connected message and target language through Vercel AI Gateway to an OpenAI model hosted on Microsoft Azure; a Connected message may be a copied Gmail message. The stored original remains authoritative. The calendar action copies the selected message into an editable operating-system calendar surface only after the owner taps it. Dibbit does not read the calendar and does not claim that an event was saved. A suggested label or event is an organizational aid, not a factual conclusion, commitment, booking, or external action.

Search: Request and Connected copy-search terms leave the device in an authenticated request so Dibbit can match the owner's server-visible records. Dibbit's application source does not write the plaintext query to the product database or analytics and binds the copy-search continuation to a keyed digest of that query. Optional live Gmail search additionally forwards the query to Google and brings matching text back through Dibbit. Its encrypted continuation includes a query digest, provider page token, and account/connection bindings, rather than the plaintext query. Dibbit does not add live-search results to the saved projection. The query is intended to remain in server memory no longer than needed to service the search. Hosting and security providers still process the request; Dibbit must treat the search as retained if production request-body or provider logging stores it. Google's own processing and retention are separate from Dibbit's product-database behavior. Search is not end-to-end encrypted.

Included-agent message assistance: for a manual request, the owner first reviews the exact source label, bounded message text, current saved agent brief, optional instruction, and writing preferences that Dibbit will send to the fixed Azure-hosted model through Vercel AI Gateway. The authenticated server resolves the current owner-bound Request, Sent, Connected, or selected live Gmail source; the app does not supply authoritative source text or receive a provider credential. Manual assistance may include up to two explicitly selected TXT, PDF, JPEG, PNG, or WebP attachments totaling at most 2 MB. Dibbit prepares them for the review: images are sanitized, TXT content is bounded, and PDF text is extracted from at most twelve pages with a bounded text limit. The reviewed context identifies the selected files and any truncation. Only after the owner confirms that exact review does the cloud AI receive the selected text or sanitized images. For a selected MP4 file, only its name, size and digest are included. Raw PDFs, MP4 video, and unselected attachment contents are not sent to cloud AI. Where optional speech-to-text is enabled, the owner may also select an MP3 or M4A audio file. Only after the owner confirms the review does Dibbit send that audio file through Vercel AI Gateway to a cloud speech-to-text model, requesting Microsoft Azure routing, zero data retention and no prompt training, and then add the transcript, limited to 3,000 bytes, to the context sent to the agent model. The owner sees the transcript with the result, not before the transfer. While speech-to-text is off, audio files are not offered. Preparing a Gmail attachment for review requires retrieving that selected file from Google; it does not add it to the saved projection. For automatic assistance, the owner must separately choose Requests, Sent, or specific Connected accounts and allow future incoming text from those sources. Automatic work on a connected Gmail account is not offered in this release. A changed agent brief requires a new permission. Automatic assistance excludes attachment contents and live Gmail results. Neither mode includes Sealed Chats. Results can be incomplete or wrong, remain reviewable suggestions or editable drafts, and never send or change a message automatically.

Ask your inbox and Brief me: where these owner features are available and only after the owner turns them on with a recent sign-in, Dibbit reads up to 12 matching or recent messages or conversations, each limited to 1,500 characters, from the owner's Requests, Sent conversations and Dibbit address mailbox each time the owner asks a question or requests a brief. Connected Gmail text is included only when Gmail is connected and the owner separately includes it. Dibbit sends that text and the question through Vercel AI Gateway to an OpenAI model hosted on Microsoft Azure, requesting zero data retention and disallowing prompt training. The text is server visible and not end-to-end encrypted. Answers are shown to the owner and are not stored on Dibbit's servers. The latest brief is kept for up to 7 days so a repeat request can be shown without reading mail again; for a brief that used Gmail, only the time it was made is kept. Dibbit keeps the consent record and daily, weekly and monthly usage counts to enforce plan limits, and deletes usage counts after 35 days. These features cannot send, move, label, delete, buy or redeem anything. The owner can turn them off, or remove Gmail alone, at any time. When the owner revokes Google access or deletes Dibbit's Gmail copy in Dibbit, Dibbit also removes Gmail from these features. A Gmail connection made after the owner included Gmail, including a reconnect to another Google account, is never included until the owner includes Gmail again.

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.

Dibbit also counts visits on its own servers to active public address pages and to Dibbit's own public pages, such as the home page, the claim page, the Founding Drop pages and the guides. After one of these pages is visible in a browser tab, the page asks Dibbit to count one visit. Dibbit computes a keyed hash of the network address (for IPv6, only its network prefix), the browser user agent, and the date, then re-keys it inside the database with a random key that Dibbit uses for only one UTC day and deletes after that day ends. Dibbit stores only the re-keyed result and does not store the network address or the user agent for this count. Because each day's key is deleted, Dibbit's visit-count records cannot connect visits on different days, except in restricted disaster-recovery backups until they age out, and a person who returns on another day is counted again. Hosting and security providers still process each page request. After a day ends, Dibbit's daily retention job replaces that day's visitor tokens with daily counts for each page and for the pages together, which the same job deletes before they are 90 days old; a missed run can delay that deletion, and restricted backups can retain the counts until they age out. Each address-page count also records how the visit arrived: a share link, a short link, the Dibbit homepage, direct or unknown, or another source. Visits to Dibbit's own pages are counted apart from address-page visits, record no arrival source, set no cookie, and are not linked to a later claim. Visit counts are shown only to Dibbit operators, in aggregate. Requests that declare an automated client or a prefetch, views of an address page by its owner while signed in, and views by signed-in Dibbit operators are not counted. This filtering reduces, but does not eliminate, automated and staff traffic. Abuse limits cap how many visits are counted from one network, for one page, and across Dibbit in an hour or a day; visits over a limit are not counted. For Dibbit's own pages, Dibbit also keeps a daily count of visits refused by per-network limits. Those limits use network hashes re-keyed with the same daily key, and the daily retention job deletes them after their day ends.

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.

A reply-alert address is processed by Dibbit's servers, by Resend, which delivers the email and keeps its own delivery logs, including the private link in the alert, and by the recipient's email provider. Dibbit does not show it to the address owner.

In an authenticated address-to-address conversation, the recipient can read and reply to the Request and the sender can read the matching Sent conversation. Dibbit's servers and narrowly authorized service providers process and store that content to operate the feature. Authorized personnel may access it only for the support, security, abuse-review, reliability, or legal purposes described in this notice. Dibbit does not routinely read private conversations.

A Huddle's title, description, host @name, admission mode, expiry, and aggregate member count are visible at its public route. An active Huddle member can see the room's active membership display names, items, answers, dates, and RSVP totals. A pending applicant cannot read the room. The address owner can see pending membership requests and can admit, reject, remove, or ban memberships within the controls offered by the service. A membership ban is not a verified person-level exclusion. Huddles are server-visible and are not end-to-end encrypted. Authorized personnel may access Huddle data only for the narrow support, security, abuse-review, reliability, or legal purposes described in this notice.

A raw name-rights case and supporting URL remain private from public profiles and other members. Authorized reviewers and personnel can see the case fields, supporting URL, status, and review record only as needed for the review, support, abuse-prevention, security, dispute, or legal purpose. After an authorized reviewer admits a case, a public profile may show only a neutral status and disclosure such as affiliation unconfirmed or name contested. It does not show the submission, supporting URL, submitter, reviewer, or operator reason code.

An outside agent that an owner approves receives the four fixed base tools to see that owner's public address, list and read that owner's Dibbit Requests inbox, and prepare one exact reply in an existing Dibbit thread for the owner's review. The reply tool works only after the owner gives that connection Requests message access, and it saves the reply without sending it. The base connection does not silently grant the message-source tools. The owner must separately enable communications_v1 for that exact client and choose Requests, Sent, or Protocol Mail, the owner's Dibbit address mailbox. Only then can the client list, search, and read those server-visible sources and save an exact reply proposal for the owner's review. Outside-agent access to Connected copies is not offered in this release: no outside agent can list, search, or read Dibbit's saved Gmail copy, and Connected wake-up callbacks, Connected first-response drafting and automatic work on a connected Gmail account are not offered either. Reading or searching Protocol Mail message text also needs the owner to allow reading for that connection, and each allowance lasts 15 minutes; listing message previews does not need it. Preparing or checking a proposal does not approve or send it; any supported delivery uses a separate owner review and send control, apart from the automatic replies described below. These 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. With a connection key, Dibbit holds that credential and the service receives only the key. Supabase also requires a phone field, but Dibbit leaves the phone field empty in newly issued outside-agent access tokens. Dibbit does not request or allow the phone scope for outside-agent connections. Older tokens or information already shared cannot be recalled. Revoking a communications source stops new access under that grant without removing the base OAuth connection; disconnecting revokes the connection's new tool calls. 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.

Saved outside-agent reply proposals have a 24-hour review window. Their subject, body and private review details become unavailable when that window expires; a bounded scheduled cleanup then removes those fields. Revoking the related source permission or removing its connected source also clears that review content. Minimal operation identifiers, keyed content fingerprints, permission versions and delivery-only evidence remain to prevent duplicate sends and check uncertain outcomes. They do not authorize another send or retain the message text. Account deletion removes the associated proposal records, subject to the restricted backup and legal-retention limits described in this notice.

Automatic replies are a separate permission, off by default. Each permission covers one connection and one source: Requests, Sent, or Protocol Mail. The owner turns one on after signing in within the last 15 minutes, once that connection has message access and reply drafting for the source. Each permission expires within seven days and allows replies of up to 2,000 bytes, up to 20 an hour and 100 a day, or the shorter expiry and lower limits shown when it is turned on. Sent and Protocol Mail permissions, and Requests permissions where Dibbit requires it, also need the owner's passkey approval of that exact permission. While the permission is active, the agent can answer a new incoming message with a short text reply it saved, without asking the owner first, at most once per incoming message. Requests and Sent replies are posted in the existing Dibbit conversation, where the other participant can read them. A Protocol Mail reply is queued from the owner's Dibbit address mailbox as a reply to the message it answers; a mail provider accepting it does not confirm delivery. Under this permission the agent cannot supply new text or a new recipient. Dibbit keeps the permission settings, the approval record, including the passkey credential identifier where a passkey was used, and a receipt for each automatic reply with message identifiers, a fingerprint of the text, and the time. Account deletion removes these records, subject to the restricted backup and legal-retention limits described in this notice. The owner can revoke the permission in Dibbit at any time, and revoking that source's message access or disconnecting the agent also stops it. Replies already sent cannot be recalled.

Separately from message access, where this feature is available, the owner can share one exact Protocol Mail item with one connection: a message, including an older one, or the text of a TXT or PDF attachment, an image, or an audio transcript from a message. Sharing needs a sign-in within the last 15 minutes but no Protocol Mail message access, and it does not let the agent browse or search the rest of the mailbox. The agent receives the shared content, such as the sender, subject, and message text, which can include contact details. Each item is available to that connection for at most 15 minutes. The owner can cancel it sooner, and disconnecting the agent also ends it. Dibbit then stops providing the item, and a bounded scheduled cleanup clears any copy Dibbit kept for it. The agent may prepare a reply to a shared message; that reply waits for the owner's review and is not sent by the tool that prepares it. The outside provider may keep content it already received.

A separate sealed_selected permission does not let an outside agent browse a Sealed Chat or obtain room keys. After an owner reviews and confirms the exact selected text, Dibbit stores a server-visible relay copy for that exact owner and client. Access and any returned draft expire after 15 minutes; bounded cleanup runs every five minutes, so physical deletion can follow expiry. Cancelling the selection or revoking or changing its grant immediately clears the live relay payload and any stored draft. The outside provider may retain content it already received, and disconnecting cannot recall that provider's copy. The returned text is only a draft for owner review and is never sent by the relay.

If you joined through an invite, you see the @name of the person who invited you. That person sees that someone joined and, once your invite qualifies, your @name. Members who invite see counts of people who joined, are waiting for a first conversation, are counting soon, or qualified. Members never see who sent the Request that qualified an invite, network or domain hashes, contact fingerprints, or how anyone else earned a number. Authorized Dibbit operators see the review queue, including the @names involved and review signals such as shared networks or email domains, and a list of the members with the most credits, which Dibbit monitors; every review decision is recorded. A ladder number is public like any other Dibbit ID, with no mark of how it was earned.

Dibbit uses infrastructure providers, including Vercel for hosting, analytics, and AI Gateway routing, Microsoft Azure for the bounded initial agent question, a live agent conversation, an explicitly requested Request or Connected-message translation, an owner-requested private-image summary, the optional owner AI helper, and owner-approved manual or automatic included-agent message assistance using an OpenAI model, Supabase for database, private object storage, and authentication, the configured SMS provider and mobile carriers for optional sign-in code delivery where offered, Resend for generic owner notification email, visitor reply-alert email, an owner-approved external email action, and optional authenticated inbound-email receipt, Cloudflare for security, Email Routing, and the reduced inbound-email Worker, Stripe for Checkout, subscriptions, billing management, and the optional hosted government-ID and live-face identity check, Apple for native App Store purchases, restoration, subscription management, and signed subscription notifications, Google for native Google Play purchases, restoration, subscription management, current purchase verification, and authenticated subscription notifications, 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.

For an App Store purchase, Apple receives the random purchase-account token Dibbit uses to bind the purchase to your account. It is not your email address or message content. Apple handles its payment and account data under the Apple Privacy Policy.

For a Google Play purchase, Google receives the opaque billing-account identifier Dibbit supplies to bind the purchase to your account. It is not your email address or message content. Google handles payment and Google Account information under the Google Privacy Policy. Dibbit uses Google's current authenticated purchase record, rather than an app-provided premium flag, to decide whether paid access is active. A pending chargeback-review notification is stored and surfaced for authorized human review; it is not treated as purchase authority and does not trigger an automatic financial decision.

Google processes the optional Gmail authorization and Gmail API requests. Dibbit stores the resulting encrypted OAuth credential and bounded message projection in its private Supabase-backed service so the connected owner can use that feature. Dibbit does not disclose that Gmail projection to other Dibbit users, and in this release it does not disclose it to outside agents: Connected access for outside agents is not offered. When offered, that access requires the owner to select Connected access for one exact OAuth client under communications_v1, and the grant does not disclose the Google credential, broaden Google scopes, include on-demand attachment bytes, or authorize an automatic send. Dibbit personnel and contractors do not access Gmail content for ordinary support or reliability work. Human access is limited to the specific Gmail messages for which the owner has given documented explicit consent for support, an AI result the owner chooses to report for human review, which can quote Gmail text, access needed to investigate a security or abuse incident, access required by applicable law, or aggregated and anonymized internal operations that cannot identify a person. Access is limited to the data needed for that purpose and is logged and access-controlled.

When an owner opens the native share sheet or calendar editor, the operating system and any selected sharing or calendar provider receive the information the owner chose to hand off. Dibbit does not receive the owner's contacts or read the owner's calendars through those controls. When an owner uses included-agent message assistance, Dibbit's server sends only the reviewed or policy-authorized bounded Request, Sent, or Connected text, agent brief, instruction, and included style preferences through Vercel AI Gateway to the fixed Azure-hosted model under Dibbit's managed service posture. The app receives no provider credential. Automatic work processes only the sources the owner enabled; it does not read every message, attachments, or Sealed Chats and does not send or change messages.

Stripe Identity roles: Dibbit decides whether to offer the optional check and how Dibbit uses its bounded result. Stripe hosts the check and handles the document and live-face information. Depending on the particular processing, Dibbit and Stripe may each act as an independent controller or business for their own purposes, and Stripe may also process information for Dibbit under the Stripe Identity terms. Stripe may compare or supplement submitted information using governmental, commercial, and other third-party sources where permitted. Stripe describes its own purposes, sources, disclosures, international processing, and rights process in the Stripe Privacy Policy.

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. The stricter Gmail-specific human-access limits above control for Google user data.

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.

Following a valid Dibbit share link or a short link can set a signed cookie, limited to that address page, for up to five minutes so the visit count can record how the visit arrived. After a counted address-page visit, Dibbit may set a signed first-party cookie for up to seven days that records only how the visit arrived and the visit date, not which address was viewed or the time of the visit. It is not set for a signed-in visitor who already holds an address. If that browser then claims an address, Dibbit records that the claim followed a counted visit, with the arrival type and visit date. The daily retention job deletes that record before it is 90 days old (a missed run can delay this); it is never shown to address owners and is deleted if the account is retired. Dibbit does not set or use the seven-day visit cookie when the browser sends a Global Privacy Control signal. Viewing and messaging work without these cookies.

Following a personal invite link, dibbit.ai/i/ followed by a code, sets a secure first-party cookie for up to seven days that holds that code, so the invite can be recorded after you claim an address. Claiming works without it.

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. Where Huddles are available, it may keep the member capability in sessionStorage so that tab can return to the room without placing the secret in a public URL or sending it as a query parameter. This storage ordinarily ends when the tab's browsing session ends.

Dibbit uses localStorage for device preferences, such as pausing hero motion or hiding a Group Answer card, and for the bounded own-mailbox recovery records described above. Preferences remain until they are changed or browser storage is cleared; recovery records follow their shorter clearing and expiry rules. Dibbit does not use advertising cookies at launch.

Message content, including authenticated address-to-address conversations on the Request substrate, 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.

Reply-alert records follow their Request. Stopping alerts, blocking the Request, the Request reaching the end of its retention period, repeated rejected deliveries, or an unconfirmed address reaching the end of its 48-hour confirmation window erases the encrypted copy of the address, return key, and link secrets; background maintenance applies the time-based expiries. The keyed address hashes, link digests, status, timestamps, and content-free delivery records remain until the Request is purged, when Dibbit deletes them. If an address stops an unconfirmed request, Dibbit keeps only a keyed hash of that address for 30 days so it is not asked again, even if the Request is purged sooner.

A Request translation consent receipt is minimal non-content audit state. It may remain after the related message is redacted or an account is retired while needed to show which disclosure version was accepted, preserve an idempotent first-acceptance time, protect the service, resolve a dispute, or meet a legal obligation. Account retirement does not currently erase that receipt. The receipt remains subject to applicable access or deletion rights and legal retention requirements, and it never preserves the message, returned translation, return-link token, or guest capability hash.

A Connected translation consent receipt, including one for a copied Gmail message, is deleted with that copied message: when the owner deletes Dibbit's copy of the connected account, when the copy is physically deleted after its retention period, or when the account is deleted. It never contains the message text or the returned translation.

A reported GoGo AI response or included-agent result enters restricted, append-only evidence that a person at Dibbit reads for human safety review. The selected response text is removed 30 days after the report. The record is deidentified 90 days after the report: the category, response identifier and digest, generation time, account binding and retry key are removed, and only the report identifier, its type and the report time remain. A bounded scheduled retention job applies both steps, so each can run shortly after its date. Until then, retiring the reporting account does not automatically erase the report, and it may remain while needed to review abuse or safety concerns, preserve report integrity, resolve a dispute, protect the service, or meet a legal obligation. The reporting path does not retain the owner's prompt, rest of the chat, free-form reporter note, bearer credential, or raw retry key.

Calendar suggestions and share payloads are transient handoffs to an operating-system surface. Dibbit does not create a server copy of the owner's contact list or calendar through those controls. A calendar or communication app may retain information the owner saves or sends under that provider's own settings and retention practices.

The device-held writing-style profile remains until the owner resets it or Dibbit clears it during sign-out or account switch. It is not included in the Dibbit account export, and clearing one device does not clear a different device. Manual included-agent message assistance does not persist its bounded context, instruction, style, or returned result as a chat transcript. Automatic included-agent work stores the selected source binding, a source digest and label, subject, triage suggestion, and any reply draft. That work becomes inaccessible after seven days. A bounded cleanup job runs every five minutes, so physical deletion can follow expiry; dismissing an item clears its generated output immediately. A draft remains editable unless the owner uses a separate send control. Dibbit's content-free admission records and model providers' operational or security metadata remain subject to their applicable retention settings and this notice.

In native builds with saved Compose drafts, an unsent recipient name and message are stored in protected, account-bound storage on that device. Dibbit does not upload this draft or send it automatically. The saved draft becomes unavailable seven days after its last local save and is removed when the draft store is next accessed. Successful sending, explicit local sign-out, or changing to another verified account also attempts local cleanup; a storage failure can require a retry. These local drafts are not included in the server account export, and clearing one device does not erase another device. Device storage protection is not end-to-end encryption of a sent Request.

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.

Huddle content, membership, and current RSVP records remain while needed to operate a room, enforce its admission and safety state, and provide the room history shown to participants. A room stops accepting activity when its host closes it or its expiry is enforced. The operational event ledger is limited to 10,000 rows per Huddle and has no fixed time expiry in this release. An RSVP update retains at most one content-free event marker for each membership and Plan; that marker does not store the RSVP choice, which lives only in the current RSVP row. Before retirement, other event payloads may contain the limited status, item-kind, role, admission, expiry, or retirement metadata described above.

Account retirement closes Huddles owned by that account, revokes member capabilities, removes Huddle content from product access, and sets current RSVP choices to null. It nulls every event actor and subject reference and replaces each event payload with exactly the single field retired: true. The Huddle identifier, event type, and occurrence time remain as minimal operational history, subject to applicable rights and legal retention requirements. Closing a room or removing a member cannot erase copies that a participant already saved or shared outside Dibbit.

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.

An owner-authored agent brief and its selected vibe remain while the address is active, unless the owner replaces or clears the brief. Account retirement hard-deletes the full brief row from the active database. Dibbit keeps only the separate, non-content retired address, agent, and anti-reuse tombstones described below; those records do not contain the brief. A restricted disaster-recovery backup may retain the deleted row 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.

Deleting Dibbit does not cancel an App Store subscription. Cancel it through Apple's subscription settings to stop future renewals. Dibbit removes the active Apple purchase-account linkage and retains a purchase-account-token hash, provider transaction identifiers, product identifiers, dates, and limited lifecycle evidence to prevent a deleted purchase from being attached to another account, handle disputes, and satisfy applicable recordkeeping duties. Apple retains its own billing records under its policies.

Deleting Dibbit does not cancel a Google Play subscription. Cancel it through Google Play subscriptions to stop future renewals. Dibbit removes the active opaque account binding and erases retained encrypted purchase tokens. It retains nonsecret purchase-token hashes, product and base-plan identifiers, dates, purchase state, and limited lifecycle evidence to prevent a deleted purchase from being attached to another account, handle disputes, and satisfy applicable recordkeeping duties. Google retains its own billing records under its policies. A separately encrypted pending-refund token and bounded chargeback-review record may remain through the provider review window, an active dispute, or a required legal or accounting retention period; its account binding is removed when the Dibbit account is deleted.

Dibbit keeps the consent receipt, bounded result, and limited 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. Dibbit queues a request to redact the associated Stripe verification session when an account is deleted and when an incomplete session becomes stale or reaches a terminal state covered by Dibbit's cleanup process. Provider processing can take time or fail and be retried; a queued request is not proof that Stripe has completed deletion. Stripe retains and deletes identity-verification data under its own terms, legal obligations, 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.

A name-rights case, its supporting URL, and its append-only submission and review events remain while needed to review the case, maintain or explain a namespace hold, prevent abuse, resolve a dispute, establish or defend a legal claim, or meet a legal obligation. They have no fixed public-profile display period, and they are not automatically deleted when the account is retired. Account retirement does not turn the case into a transfer, suspension, or legal-rights finding. Dibbit deletes or de-identifies case data when no stated retention reason remains, subject to restricted backup aging and applicable legal holds.

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.

Invite records, credits and their history, and review decisions are kept for as long as the number ladder operates, including after an account is deleted, so that no person is counted twice and fraud can be reviewed. Contact fingerprints are kept while the account exists and are deleted 12 months after the account is deleted. The keyed review copy of a network hash is deleted 90 days after the invitee answered that Request. These deletions run in the ladder's regular processing job, so a missed run can delay them. When an account is deleted, its unpicked rungs are released, its pending credits end, its invite link stops working, and its ladder numbers retire permanently.

A Gmail connection remains until the owner revokes it, removes the copied Gmail data, or deletes the Dibbit account. The bounded copied projection becomes inaccessible 30 days after its most recent successful source revalidation unless a later successful sync refreshes it. Dibbit's bounded daily retention worker then schedules that expired copy for physical deletion; workload or a temporary worker failure can delay the deletion. This cache expiry leaves the provider grant in place so the owner can sync again or revoke it separately. Dibbit asks Google to revoke the provider token before deleting its local OAuth credential. If Google cannot confirm revocation, Dibbit retains the encrypted credential so the owner can retry safely. The owner can also remove Dibbit from Google Account permissions and retry. Dibbit stores a content-free, credential-fingerprint-bound confirmation receipt after Google revocation; it does not contain the token. The separate delete control removes the copied Gmail thread and message projection. Account deletion will not purge the Gmail credential until that revocation receipt exists, then removes the credential and projection subject only to the restricted backup and legal-retention limits stated in this notice.

A user-selected communication import remains as a server-visible projection until the owner deletes that copied source or the Dibbit account is retired, subject to the restricted backup and legal-retention limits stated here. Deleting the Dibbit copy does not alter the source service or archive. Re-importing the exact same confirmed payload reuses its source digest rather than creating an unbounded duplicate.

Completed and ignored inbound-email delivery records retain only keyed provider-event hashes and content-free routing outcomes and are eligible for deletion after 30 days. The resulting Request follows the Request Inbox retention period described above. Dibbit does not retain a separate raw MIME, HTML, other-header, or unvalidated attachment copy. Optional admitted inbound files follow the private Request attachment retention and deletion process above; their immutable admission metadata is removed with the 30-day provider-event record. The private safe Message-ID reply context is removed with its Request or account.

A Plus exact email-action proposal keeps its server-selected From, recipient, subject, body, and attachment seals for at most 90 days from approval or, if it was never approved, creation. Scheduled retention closes any still-active action and irreversibly replaces or removes those fields with fixed redaction markers. The original action digest and content-free event and provider receipts may remain longer for security, reconciliation, dispute, and audit purposes, but the redacted action no longer appears in the owner action history.

A signed-in owner can request deletion from the account page. Completed 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. Completed deletion preparation 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.

The public account deletion instructions explain both the native and web self-service paths, what happens after confirmation, and how to request help without first signing in.

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.

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.

Sealed Chat reports: reporting is metadata-only by default and the report metadata can remain for up to 90 days. If you deliberately select one exact message or one admitted attachment and confirm the disclosure, that selected content leaves end-to-end encryption and is retained outside the chat for up to 30 days. The report records a tamper-resistant event and content digest and labels sender provenance as client-attested; Dibbit cannot cryptographically verify an E2EE event body it cannot decrypt. Exact evidence is shown only to a restricted, audited human reviewer after an explicit review action. A report does not trigger an automated verdict, contact change, group change, or other automated enforcement.

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. The selected-message outside-agent relay transfers only the exact text the owner reviews; it does not give Dibbit's server or the outside agent room keys, general room access, or permission to read all Sealed Chat messages. Relay access expires after 15 minutes, while an outside provider may retain content already received. A bridge to email, WhatsApp, iMessage, Telegram, WeChat, or another service does not preserve Sealed Chat protection by default.

The Stripe Identity check is optional. You can use Dibbit without an identity credential, although an address owner who chooses a checked-senders-only policy may not receive your message. You can ask Dibbit to stop future use of the credential or delete your account by contacting privacy@dibbit.ai. For access, deletion, or other requests concerning information that Stripe handles for its own purposes, use the contact and rights process in the Stripe Privacy Policy. Dibbit cannot guarantee the result of a request made directly to Stripe or require deletion where retention is legally required.

Taking part is optional, and you never have to share an invite link. Dibbit records who invited you only from an invite link you followed, an address share that led to your claim, a Founding invite link you used, or an @name you typed. The identity check bonus needs its own consent; you can withdraw it by contacting privacy@dibbit.ai, and credits already counted stay. Download your data includes your ladder credits and their status, your rungs and picked numbers, your invite links without their codes, and your invite records, which name the person who invited you but never the people you invited.

Signed-in owners can also download a resumable, multi-part NDJSON export of the current address, the current owner-authored agent brief and selected vibe with explicit owner-authored provenance, operational inbox history, Live Slates, owner-confirmed Memory records, and private-image metadata and any retained optional summary available to their account before deletion. For each Huddle owned by that signed-in account, the export includes the current door and its associated membership, item, current RSVP, and bounded operational event rows available at the fixed export watermark. It does not include an accountless membership in somebody else's Huddle because a private membership capability is not linked to a signed-in Dibbit account. 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.

Outside-agent connection records are not included in the self-service NDJSON export. These are the approved OAuth clients with their scopes and grant times, the communications permissions for each connection, Protocol Mail reading allowances and shared Protocol Mail items, and connection key labels, display characters, tool limits, and created, last-used, and revoked times. Automatic-reply permissions and retained automatic-reply records are included. A signed-in owner can review current connections and keys as described under Outside agents below. To request a portable copy of the connection records, contact privacy@dibbit.ai.

Name-rights case data and its supporting URL are not included in the current self-service NDJSON export. To request access, correction, deletion, or a portable copy of that case data, contact privacy@dibbit.ai. Dibbit may retain a case or event record when one of the review, namespace-hold, abuse-prevention, dispute, legal, or audit reasons above still applies, and will explain an applicable limitation when responding to the request.

A signed-in owner can review and revoke outside-agent authorizations from Inbox settings. 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. The owner can also add or remove the separate Request, Sent, Protocol Mail, and selected-message communications permissions without silently expanding another client's access. Cancelling an active selected-message relay or revoking its grant clears Dibbit's live relay payload, but cannot recall a provider copy. The owner can revoke an automatic-reply permission at any time; replies already sent cannot be recalled. The owner can revoke a connection key at any time and can cancel a shared Protocol Mail item before it expires.

A signed-in owner can review the Requests, Sent, and individual Connected accounts enabled for automatic included-agent work, turn that permission off, and dismiss a generated item. Turning it off prevents new work and invalidates pending or saved generated output. Changing the saved agent brief requires a new permission before automatic processing resumes.

A signed-in owner with an active Dibbit address can compose bounded text to another active @name and continue that conversation from Sent. The recipient's contact policy and block state still apply. The recipient can permanently block the Request from their inbox. The original sender can permanently close the same thread from Sent; that stops replies on the thread and future sends in that sender-to-recipient direction, but it does not block a separate conversation initiated in the reverse direction. A successful Send means Dibbit accepted the server-visible write; it is not a delivery receipt. Sent `unread` means only that the sender has not opened newer recipient content and is not a recipient read receipt.

When the Gmail connection is available, a signed-in owner can initiate sync, optionally enable or disable bounded periodic snapshot refresh, inspect the exact server-visible copy, revoke Google access, and delete the copied Gmail data from the connected-source controls. Removing the Dibbit connection does not delete the source messages from Gmail.

When explicit imports are available, a signed-in owner chooses the source and file or shared item, reviews the server-visible disclosure, and can delete the resulting copy. Dibbit does not use those controls to sign in to the source provider or delete anything from it.

When email-to-address receiving is available, the owner can handle or block the resulting Request under the ordinary inbox controls. Dibbit does not provide a hidden imported mailbox, and a reply cannot be sent through the inaccessible guest return thread. An eligible Plus owner can prepare a protected reply whose recipient, Dibbit From address, and RFC thread are derived server-side; that exact action is shown separately before approval. The local mail draft remains an untracked fallback.

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.