In our previous post, “Why Submit Exists,” we explored why Submit was created – stemming from a need for safer, more accountable online spaces within the Kink, BDSM, and Fetish communities. Today, we want to dive into how we’re delivering on that promise, focusing on our foundational commitment to privacy, data security, and user safety, and unveiling the next major step in that journey.
From the very beginning, Submit wasn’t just another platform layered onto existing frameworks. As we state on our landing page:
Submit wasn’t built on top of someone else’s system. We started fresh — because our communities deserve more than retrofits and compromises. Privacy, safety, and consent aren’t afterthoughts here. They’re baked into the foundation.
This wasn’t just marketing speak. Our initial core design decision centered around how we handle your data. Instead of the typical approach where user data is intermingled in large database tables, we designed a vault system. Each user’s data was stored individually and separately, providing inherent isolation and a stronger baseline for security and control. This foundational commitment to privacy and data security shaped everything that followed.
For the last two years, this vault system has served as the backbone of Submit. We’ve learned immense amounts about managing data this way, optimizing performance, and operating a social network that, under the hood, functions fundamentally differently than most. In many ways, its principles align more closely with decentralized concepts.
Operating Submit for nearly two years with our original vault system has been an invaluable learning experience. Storing user data in isolated MongoDB collections proved the viability of prioritizing data separation from day one. We successfully navigated the challenges of optimizing performance for this unique architecture and demonstrated that a social platform can operate fundamentally differently under the hood. This approach provided a stronger baseline for privacy and security than traditional, intermingled database structures.
However, this journey also illuminated the inherent limitations of that first-generation system and highlighted areas where we needed to push further to fully realize our vision:
These experiences made it clear: incremental improvements to the existing system wouldn’t be enough. To truly deliver on our promise of unparalleled privacy, robust security, genuine user autonomy, and authentic community building – especially in the challenging context of adult content – required a fundamental architectural evolution.
This realization wasn’t a detour; it was the charted course. We took everything we learned – the successes, the limitations, the user needs, the operational realities – and channeled that knowledge into developing a clear, ambitious roadmap. This roadmap doubles down on our core values and paves the way for a future where privacy isn’t just a feature, but the very fabric of the platform.
And that roadmap led directly to the development of 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.)
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.
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:
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.
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:
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.
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…
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.
Moving forward, the XC Protocol introduces a crucial separation:
This distinction offers significant advantages:
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.
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.
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:
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:
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.
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.
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.
This robust, E2EE-native architecture unlocks further benefits:
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.
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.
Given this tension, we’ve approached verification with extreme care, guided by these principles:
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:
Looking ahead, we’re exploring ways to make verification even more flexible and community-driven:
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.
This has been a deep dive into the technical foundations and future direction of Submit, centered around the introduction of the XC Protocol. We know it’s a lot to take in, involving complex concepts from decentralized identifiers and end-to-end encryption to advanced content verification. But these aren’t just technical upgrades; they represent the tangible execution of the promise we outlined in our first post: to build a fundamentally different, safer, and more trustworthy space for the Kink, BDSM, and Fetish communities.
The XC Protocol, with its core components, represents a major leap forward. XC Verify provides significant, cutting-edge safety and creator protection, while next-generation Personal Data Vaults deliver comprehensive End-to-End Encryption. We understand these innovations involve complex ideas, but every element is crafted to put you in control. Our approach to User Verification further reflects this balance: offering optional tools to enhance trust and authenticity, while fiercely protecting user privacy and exploring less intrusive methods for the future.
This journey – strengthening privacy, enhancing security, combating abuse, supporting creators, and fostering genuine connection – directly embodies our core values. It’s about empowerment, integrity, and being truly community-driven. Submit was born from the need for a better way, and the XC Protocol is the next major step in realizing that vision.
We believe this is the future not just for Submit, but for how responsible platforms can and should operate, especially within the Kink, BDSM, and Fetish communities. But we build this with you. Your insights, questions, and concerns are invaluable as we finalize and roll out these changes.
Want to be part of the discussion? Head over to the Submit Development group right here on Submit and share your thoughts – let’s build the future together.