Introducing: The XC Protocol

This roadmap leads us to an exciting, major development we’ve been working on: the XC Protocol.

The XC Protocol is a next-generation, semi-decentralized framework designed by Submit to fundamentally redefine privacy, security, and content integrity. While it is already becoming the new backbone for Submit, our vision extends further. Over time, and through careful vetting, we plan to open the XC Protocol to other platforms serving adult-focused communities, aiming to foster an ecosystem where user privacy, security, and content integrity are paramount.

We’ll be sharing more technical specifics about the XC Protocol in the coming weeks and months. Today, however, we want to talk about some of our design choices for XC and highlight the significant, user-facing changes this new protocol is bringing to Submit – changes we are actively developing and expect to fully roll out in Q2 2025.

(Note: Some parts get technical! Please feel free to ask questions in our Submit Development group if anything is unclear – we want this to be transparent.)

Why Semi-Decentralized? Addressing the Unique Challenges of Adult-Focused Platforms

Before diving into the exciting features the XC Protocol enables, it’s important to address a key design choice: why semi-decentralized? Why not adopt one of today’s popular fully decentralized protocols like AT Protocol or Nostr (both of which influenced our protocol design)?

The answer lies in the realities of operating a platform openly focused on adult themes and content. Society and governments worldwide often create significant hurdles for platforms like ours. We face intense scrutiny and regulatory pressure aimed at making it difficult, if not impossible, to operate responsibly. Understanding these challenges from the outset, we knew that any viable protocol for Submit must include robust, verifiable content scanning before data hits the network or is encrypted end-to-end. This is non-negotiable for ensuring legal compliance, platform longevity, and critically, the safety of minors.

Introducing XC Verify: Proactive, Privacy-Preserving Content Scanning

To meet this need, the XC Protocol includes a core service: XC Verify. This service is responsible for advanced, privacy-preserving content scanning before your content is encrypted and stored in your PDV or shared.

XC Verify goes beyond the basic hash matching commonly used for CSAM/CSEM prevention. While still using privacy-preserving hashes, we employ perceptual hashing. Here’s why that matters:

• Traditional Direct Hashing: Can be easily bypassed. Minor changes to an image or video (like cropping a few pixels) alter the hash, potentially allowing prohibited content to slip through.
• Perceptual Hashing (XC Verify): Creates a hash based on the visual characteristics of the content. This allows the system to detect prohibited material even if it has been slightly modified, cropped, resized, or altered. It’s a significantly more robust defense against evasion techniques.

Critically, this scanning process is designed with privacy in mind, primarily happening client-side where possible. We continue to collaborate with NCMEC and other agencies, sharing new perceptual hashes of known illegal material to contribute to broader child safety efforts.

Beyond Safety: Empowering Creators and Ensuring Authenticity

But the capabilities of XC Verify extend beyond essential safety measures. The same perceptual hashing technology provides powerful tools to support content creators, both big and small, and maintain the integrity of content on Submit:

• Combating Content Theft: By creating unique, robust fingerprints of uploaded content before encryption, XC Verify can help identify instances of unauthorized re-uploads or content theft across the platform, giving creators better tools to protect their work.
• Streamlining Copyright Protection: When creators report copyright infringement (e.g., via DMCA requests), the verified content fingerprints generated by XC Verify can potentially expedite the identification and removal of infringing copies, making enforcement easier and more effective.
• Enhancing Content Authenticity: We are actively exploring the integration of upcoming industry standards like C2PA (Coalition for Content Provenance and Authenticity). The goal is to leverage such protocols within the XC Verify framework in a privacy-preserving way. This could allow for verifiable markers of content origin and manipulation history, helping users distinguish authentic media from potentially misleading deepfakes or AI-generated content, without compromising the end-to-end encryption of the content itself.

XC Verify represents cutting-edge tooling for platforms in our space. We believe it’s an essential component not just for compliance, but for demonstrating our unwavering commitment to keeping illegal content off our platform and protecting children. It allows us to proactively address regulatory concerns by provably showing significant investment and effectiveness in content safety, enabling us to continue offering best-in-class privacy features like E2EE.

The Path Forward: Centralized Verification, Decentralized Potential

This need for mandatory, effective pre-verification via XC Verify is why we’ve architected the XC Protocol as semi-decentralized. We believe that for platforms handling adult content responsibly today, provably validating content before it enters the network is the only sustainable path. Centralizing this verification step is currently the only way to achieve this reliably and demonstrably.

While the verification component is centralized, the underlying architecture for identity (DIDs) and data storage (PDVs) draws heavily from decentralized principles (influenced by ATproto and Nostr). Our long-term roadmap absolutely includes further decentralization, most notably the ability for users to host their own PDVs. However, even in a self-hosted scenario, federation (connecting with the broader Submit network) would still require content passing through XC Verify to maintain the integrity and safety standards of the network.

Could this change? Could self-hosted vaults eventually use different content verification services? Potentially. We are open to integrating with other providers if they emerge and can meet the rigorous technical and ethical standards required. But today, XC Verify is the purpose-built solution necessary to balance user privacy with the non-negotiable requirements of content safety and legal compliance in our specific context.

Now, let’s look at how this foundation enables groundbreaking features for your identity and data…

1. Evolving Your Identity: Separating Who You Are from How You Appear

When we talk about your “identity” on Submit today, you likely think of your username, your profile information (metadata), and perhaps the content you share – the things that represent you in this space. Under the hood, your current identity also includes a public key. This key serves two main purposes: it’s part of the cryptographic process used to secure data, and it acts as a unique, stable identifier that doesn’t change even if you change your username.

While using a public key as a fixed identifier isn’t inherently bad, as we planned the future of Submit and the XC Protocol, we saw an opportunity to build something more robust, flexible, and better suited to support our expanding vision for privacy, security, and user control. We wanted a system that could more elegantly handle verification, potential self-hosting, and sophisticated key management.

Introducing the Separation: Identity (DID) vs. Handle (Account)

Moving forward, the XC Protocol introduces a crucial separation:

• Your Core Identity (DID): This is your new foundational, unique, and persistent identifier. It’s based on the W3C Decentralized Identifier (DID) specification (specifically, our did:xc: method initially). Think of this as the stable anchor representing you cryptographically on the network. It never changes, ensuring links to your content remain permanent and providing a solid base for verification and key management.
• Your Handle(s): This is what you typically think of as your “account” – your chosen username, profile metadata, and how you primarily interact with others.

Why the Separation?

This distinction offers significant advantages:

• Stability: Your underlying DID remains constant even if you change your handle (username). This prevents broken links and ensures long-term consistency.
• Flexibility: A single core Identity (DID) is designed to potentially support multiple handles in the future. While most users will likely only need one handle for personal use, this allows for scenarios like having a separate handle for a business, organization, or specific project, all securely linked back to your core Identity.
• Enhanced Security: Key management, rotation, and verification are tied to the stable DID, creating a more secure and manageable system.
• Future-Proofing: This structure aligns with emerging web standards (DIDs) and provides a foundation for advanced features like using your own domain name (yourdomain.com) as a verified handle resolver, pointing back to your DID.

Under the Hood

As this system rolls out, you might notice new identifier formats:

mrslate
mrslate.submit.gg
xc://mrslate.submit.gg
did:xc:tg1eply9nzr44cxx2km1grpm
yourdomain.com
sub.yourdomain.com

Each of these formats all function as valid ways to reference a user, ultimately resolving back to the authoritative DID.

This evolution strengthens the decentralized DNA of Submit, but more importantly, it establishes the robust identity framework necessary for the next generation of Personal Data Vaults.

2. The Next Generation: Personal Data Vaults (PDVs) with End-to-End Encryption (E2EE)

Our original vault system, where each user had their own isolated space within our database (effectively, a MongoDB collection per user), was a solid first step. It provided better separation than traditional platforms and served us well for nearly two years. We learned how to optimize it and make it performant. However, as we planned the future with the XC Protocol, we knew we could – and must – go much further to truly deliver on our promise of unparalleled privacy and user control. Simply isolating data wasn’t enough; we needed to fundamentally change how it’s stored and secured.

From Isolated Collection to Dedicated Repository: The New PDV Architecture

Enter the next generation of Personal Data Vaults. Instead of a database collection, each handle now gets its own dedicated individual SQLite file. Think of this less like a slice of a shared database and more like your own personal, secure, version-controlled data repository (internally, we even use concepts like merkle trees, similar to git, to manage versions).

Why this shift? This file-based structure offers several key advantages:

• True Data Encapsulation: Your data lives in its own distinct file, physically separated from others, enhancing isolation.
• Performance Potential: SQLite is incredibly fast and efficient for managing structured data within a single file.
• Atomic, Isolated Backups: This architecture allows for truly individualized and atomic backups. We can back up your entire PDV file as a single, consistent unit, ensuring data integrity and isolation even during the backup process – a significant improvement over complex, potentially intermingled backups in traditional shared database systems.
• Foundation for E2EE: Most importantly, this architecture is perfectly suited for implementing robust, comprehensive End-to-End Encryption.

Regarding Backups: By default, Submit will automatically maintain encrypted backups of your PDV file stored on our infrastructure. This provides a crucial safety net in case of data corruption or system issues. However, aligning with our principle of user control:

• You Can Opt-Out: You will have the option to disable automatic backups for your PDV.
• Important Consequence: Please understand that opting out means if anything happens to your live PDV file (e.g., corruption, accidental deletion on our end during a major failure), your data will be permanently lost. Without a backup, there will be absolutely no way for Submit to recover it.
• Future Self-Hosting: Looking ahead to the possibility of self-hosted PDVs, the responsibility for implementing and managing backups will shift entirely to you or your chosen hosting provider. Submit will not automatically back up self-hosted vaults.

True Deletion, Immediately: This isolated, file-based approach also revolutionizes data deletion. On typical platforms, when you request account deletion, your data often lingers in backup cycles for weeks or months. Because your PDV and its backups are distinct, isolated units, when you request deletion of your data on Submit, we can delete your live PDV file and its associated backups immediately and completely. Your data does not persist; deletion means true removal from our systems.

The Crown Jewel: End-to-End Encryption (E2EE) for Everything

Let’s be clear about standard encryption practices today. Most platforms (including Submit currently) encrypt your data “at rest” (when it’s sitting on a hard drive) and “in transit” (when it’s traveling over the network). Sensitive fields like passwords and emails often get an extra layer of encryption within the database itself. This is good standard practice.

However, it leaves a potential vulnerability. If an attacker were to breach the running application servers or database systems, much of the data not specifically field-encrypted could potentially be accessed in a readable format. This is a common vector for data breaches across the internet.

The new PDVs, powered by the XC Protocol, change the game entirely by implementing End-to-End Encryption (E2EE) for all your primary content – posts, messages, images, videos, writings, etc.

• What E2EE Means for You: Simply put, once your content is encrypted on your device (computer or phone), only you and the specific people you choose to share it with hold the keys to decrypt and view it. Not Submit staff, not system administrators, not potential hackers who might breach servers, or any government agencies. Your content remains unreadable gibberish to anyone without the correct keys, which we do not possess.
• How It Works (The Process):
  1. Client-Side Power: Encryption and decryption happen directly in your browser or app (client-side) using cryptographic keys only you control. Your unencrypted content (beyond necessary scanning) doesn’t sit on our servers.
  2. Safety First (XC Verify): Before anything gets encrypted, it passes through XC Verify for safety and integrity checks (as detailed earlier), often happening client-side as well. This ensures harmful content is stopped before it’s locked away by E2EE.
  3. Targeted Encryption: When you share, the content is encrypted specifically for the cryptographic keys of the intended audience members (respecting your blocks and theirs). Public posts are still E2EE, accessible only by valid accounts who aren’t blocked.
• Moderation in an E2EE World: How do we moderate content we can’t see? We rely on user reports. When you report E2EE content, your device creates a special, temporary decryption key just for that report, re-encrypts the content with that key, and sends it securely to our moderation queue. To prevent abuse, it requires two moderators collaborating to use that key and view the reported content.
• Building Trust Through Transparency: We know E2EE requires immense trust. We’re committed to earning it through:
  • Independent Audits: Regular third-party audits of our code and infrastructure, with public reports.
  • Verifiability Tools: Building tools for you to inspect and verify the encryption/scanning process.
  • Open Source: Releasing key parts of the XC Protocol technology as open-source software.

A note on independent audits: We will hire third-party auditors to review our code and systems, publishing reports annually. Our aim is to release our first report 6 months after enabling E2EE.

Beyond E2EE: Other Enhancements Enabled by New PDVs

This robust, E2EE-native architecture unlocks further benefits:

• PDV Locking: Need an extra layer of security? You’ll be able to lock your entire PDV, preventing any access until you unlock it.
• Regional Deployment: To improve speed and responsiveness, your encrypted PDV file will likely be stored in a data center geographically closer to you.
• Zero-Knowledge Proofs (ZKP) Ready: The structure fully supports and utilizes advanced cryptographic techniques like ZKPs, opening doors for future privacy-preserving features.
• Messages Finally E2EE: Yes, this comprehensive approach means your direct messages will also benefit from full end-to-end encryption!

The Long View: Your Data, Your Control

This fundamental shift to encrypted, file-based PDVs is about giving you maximum control and security over your data. While it’s a distant goal on our roadmap, this architecture even lays the technical groundwork for a future where you might potentially host your own PDV, achieving ultimate data sovereignty while still securely interacting with the network (via XC Verify).

This next generation of Personal Data Vaults, powered by the XC Protocol and secured with comprehensive E2EE, represents a monumental leap forward in fulfilling Submit’s core promise: building a truly private, secure, and trustworthy space for our community.

3. User Verification: Building Trust in a Privacy-Focused World

Verification is often a contentious topic, especially within communities that deeply value privacy and anonymity – core tenets that Submit champions. Introducing verification might seem counterintuitive, potentially clashing with the desire to remain anonymous. We understand and respect that perspective deeply.

However, we also operate in a complex reality. Firstly, the regulatory landscape for online platforms, particularly those dealing with adult themes, is becoming increasingly stringent. Governments worldwide are pushing for stricter age verification measures, making it harder for spaces like ours to exist without addressing this directly. Secondly, the practical challenges of maintaining authentic online communities are significant. Issues like catfishing, scams, bots, and malicious actors seeking to exploit users or disrupt the space make building genuine trust difficult without some mechanism to establish authenticity.

Our Approach: Optional, Privacy-Preserving, and Transparent

Given this tension, we’ve approached verification with extreme care, guided by these principles:

1. Verification is Optional: Let us be crystal clear: We have no current plans to make verification mandatory or required to use Submit. Furthermore, we do not intend to gate features or restrict access based on verification status. Our goal is to offer verification as a tool for users who want an extra layer of trust, not as a barrier.
   • The Legal Caveat: We must be transparent that this could change. Evolving laws, potentially varying by country or even state/province, might someday force platforms like ours to implement mandatory verification. Should that happen, we will communicate clearly and explore the most privacy-respecting options available under the law.
2. Privacy Preservation is Paramount: Frankly, we do not want to be in the business of storing copies of your government IDs. It’s a massive security liability and goes against our core ethos. Our entire verification system is designed around avoiding this. We’ve invested heavily in client-side processing and cryptographic techniques to validate identity and age without needing to retain sensitive documents or biometric data on our servers. When we say privacy-preserving, we mean it.
3. Continuous Innovation: The methods outlined below are our starting point. We are committed to ongoing research and development to find new and better privacy-preserving ways to help users verify age, identity, and authenticity.

Current Verification Levels (All Optional):

With that foundation, here are the verification levels we plan to introduce, all processed with privacy as the priority and happening at the Identity (DID) level:

• Identity/Age Verification (Client-Side): Uses your device’s camera to analyze a government ID document (front/back) and your face in your browser. It compares the photo, estimates age, and confirms liveness. Crucially, ID images and facial data are not sent to or stored by Submit. We only receive a cryptographic token confirming successful verification. Periodic re-verification will be needed.
• DNS-Based Verification: Allows users to prove ownership of a domain name, which then resolves to their DID. This is ideal for established individuals, businesses, organizations, or events. The verified domain will be visible on the profile. (We recognize the need for more entity verification options beyond DNS and are actively exploring additional privacy-preserving methods for businesses and organizations).
• Verification Interview: For those uncomfortable with automated ID checks, a 1-on-1 video interview (in-browser) with a trained team member can validate you’re a real person (matching photos if provided). This includes client-side age estimation software alongside human judgment.

Future Directions: Decentralized Trust and Collaboration

Looking ahead, we’re exploring ways to make verification even more flexible and community-driven:

• Third-Party Verifiers: Could a trusted kink event organizer who checks IDs at the door act as a verifier within Submit? Or could established content creation platforms (like OnlyFans, etc.) that already perform robust age and identity checks for their creators potentially serve as trusted attestations? We see potential here. We envision a future system where users could potentially choose which external, vetted verifiers they trust, influencing the verification indicators they see on profiles. This requires careful consideration of interoperability and security, but it’s an avenue we’re actively exploring.
• Exploring Email-Based Age Verification: We are constantly researching less intrusive verification methods. One area we’re investigating is the potential for email-based age verification. The idea is appealing because it could offer a lower-friction path for users compared to ID scans or interviews. However, achieving this in a genuinely privacy-preserving way that meets our high standards is proving exceptionally challenging. We’re not sure yet if it’s feasible without compromising user privacy or introducing unacceptable security risks, but we are dedicating resources to exploring if a viable, secure, and private method can be developed.
• Web of Trust Concepts: We’re also researching models where multiple verified users could vouch for another user’s authenticity. Designing this to be robust against abuse is complex, but it aligns with our goal of empowering the community and exploring alternatives to centralized checks.

Building a Safer, More Authentic Space Together

We believe that offering these optional, privacy-conscious verification tools is a vital step in combating bad actors and fostering a more authentic environment, without compromising the core anonymity many users require. We will provide clear indicators on profiles showing which verification levels (if any) have been completed and when. We’ll also enhance platform warnings and guidance regarding interactions with unverified or new accounts.

Verification is a tool, not a mandate. It’s one part of our broader strategy, alongside robust moderation and the powerful privacy features of the XC Protocol, to build the trustworthy community we all deserve.