We Should Never Need to Know
Who Someone Is
The DBBL Protocol is designed around a core principle: identifying behavioral patterns across platforms should never require centralizing personal identity.
No PII, Ever
Identity signals — phone numbers, email addresses — are hashed by the calling platform before transmission. The DBBL Protocol receives only the hash. It has no mechanism to reverse a hash to a real identity.
This is enforced by design, not policy. The API accepts hashes. It has no endpoints that accept or return raw phone numbers or email addresses.
What the Protocol Stores
✓ What Is Stored
- → phoneHashSHA-256 of the E.164-normalized phone number
- → emailHashSHA-256 of the normalized email address
- → usernameLowercase, trimmed plaintext + SHA-256 hash. Required for fuzzy matching.
- → violationCategoryOne of five enumerated categories (harassment, fake_profile, etc.)
- → severity + timestampsSeverity level and when the report was submitted
- → platformIdWhich member platform submitted the report
✗ What Is Never Stored
- → phone numberRaw phone numbers never transmitted to or stored by DBBL
- → email addressRaw email addresses never transmitted to or stored by DBBL
- → real nameLegal names, display names, and real names are never collected
- → additionalContextFreeform context submitted with reports is stored for human reviewers only — never returned via API
- → IP addressNo IP addresses or device identifiers collected from querying platforms' users
Hashing & Normalization
Hash consistency is critical for cross-platform matching. If two platforms hash the same phone number differently, they'll never match. The Protocol specifies normalization rules that all platforms must apply before hashing.
Phone Numbers
- 1. Strip all non-digit characters
- 2.
If 10 digits, prepend
+1(US numbers) - 3.
Ensure E.164 format:
+[country][number] - 4. Apply SHA-256 to the normalized string
Email Addresses
- 1. Lowercase the entire address
- 2. For Gmail: remove dots from local part
- 3.
For Gmail: remove
+tagsuffixes - 4. Apply SHA-256 to the normalized string
Platform Accountability
The DBBL Protocol trusts that member platforms submit only confirmed violations. This trust is not unlimited — it is tracked and weighted.
Platforms start as provisional with a trust score of 0.5. Platforms that consistently submit accurate, confirmed reports move toward standard and trusted tiers.
Every report is weighted by the submitting platform's trust score. A report from a provisional platform (0.5) contributes half the weight of a report from a fully trusted platform (1.0).
Only confirmed violations should be submitted. The DBBL Protocol is not a report queue — it's a record of your platform's moderation decisions. Submit only what you have already acted on.
Questions or Concerns
If you have questions about how the DBBL Protocol handles data, or want to report a concern about how a member platform is using the network, contact us.
privacy@dbblprotocol.org