Block decisively. Describe carefully.

Dibbit applies a narrow deterministic pre-delivery phrase screen to the subject and details of a new public Request and to later guest text in that public-door thread. A match is rejected before a Request or message is stored or shown to the address owner. The screen is English-only, does not inspect attachments, media, inbound email, owner messages, authenticated address-to-address messages, or Sealed Chats, and will not catch every harmful message. It can also be wrong. A rejected send is a service rule, not a legal judgment, safety verdict, or claim that a person committed wrongdoing. Appeals can be sent to the same monitored contact.

Rate limits, message ceilings, replay controls, owner blocking, and manual reporting remain separate safeguards. Dibbit does not guarantee automated or human review of every message. Nonpublic content may be reviewed by authorized personnel or contractors only when reasonably needed for a specific report, support request, security incident, reliability problem, or legal duty. Access is limited to the information needed for that task.

An owner-approved outside agent can read that owner's Dibbit inbox and, when the owner allows it, prepare a reply for the owner's review through the fixed reply tool. It cannot obtain a guest's private return capability or use Dibbit to approve payments, bookings, contracts, or other high-risk actions. Owners should review the exact reply before delivery and disconnect an agent they no longer trust.

Current Dibbit Requests and guest return threads are access-controlled by the owner account and a random sender capability, but message content is stored server-side and is not end-to-end encrypted. Anyone with the complete return link can open that thread until it is blocked or expires.

Huddles are small, purpose-bound, server-visible rooms. A public join page does not mean that its host, members, content, or links are verified or safe. An invite code can be forwarded, and host approval is a host's decision rather than a Dibbit endorsement. A school-domain check, if offered, would establish only control of an eligible email address and would not prove identity, affiliation, age, authority, reputation, or safety.

Hosts should use approval for sensitive rooms, remove disruptive members, avoid collecting confidential information, and report serious concerns. Participants should keep membership capabilities private, verify consequential information at its original source, and leave or report a room that appears deceptive or abusive. GoGo Catch-up is source-linked organization, not a factual or safety verdict about a person.

Sealed Chats are a separate, release-gated native feature. If enabled, content would be encrypted and decrypted on participant devices, so Dibbit could not proactively inspect that plaintext on the server for scams, abuse, malware, or illegal content. A participant seeking help would need to choose and submit the relevant content with a report. Dibbit could still use available account, device, room, rate-limit, delivery, and network metadata to protect the service and respond to valid reports or legal duties.

Encryption does not make a participant verified or safe. Contact consent is not an endorsement, and own-device verification would not verify the other person's identity. Do not rely on Dibbit for emergencies or assume that a message, attachment, account, or device is harmless.