Half-Baked #2: Cryptographically Deniable Distributed Social

Half-baked is a collection of articles that cover some ideas I’ve thought of, but haven’t fully worked out, or even researched. The majority, or perhaps all of these, will be bad ideas. Many will not be technically viable. But on the very slight chance they inspire better ideas, I figured they were worth publishing.

A Distributed Social Protocol Built on Impermanence

Permanence is not optimal for social media. There’s both comfort, personal security, and efficiency in a delete button. Censorship resistance currently comes at the cost of permanence, but it might not have to!

When opting for censorship-resistant content distribution networks, users cannot take back something they said, and the cryptographic proof of each piece of content is not deniable without starting a fresh account. This is suboptimal in terms of user experience, and downright dangerous depending on what regime you live under (or will live under if the political winds shift).

I also see permanence as a dealbreaker for any real mainstream adoption, which demands a delete or edit button against bad takes, possible misinterpretations, or simple account maintenance.

Proving Authenticity with Deniability

The idea is to introduce some deniability knowing that it will be much better than complete permanence, even if not perfect.

Note: this doesn’t solve the problem of “screenshotting” or taking a snapshot of the state of the network to prove a certain user said something. This is likely not a problem that can be solved, and this doesn’t attempt to. Greater ownership for the majority is still better, and accountability for the top 1% of accounts or contentious posts is likely a positive thing.

So, with that in mind, the idea is to focus on cryptographic deniability.

Where:

1. Users create a profile anchored to a single source of truth (i.e. a blockchain or rollup)
   
   1. This profile includes the user’s preferred Personal Data Store (PDS) or relayer
   2. Profile includes the user’s key whitelist link (could be self-hosted or third-party)
2. Users post content and events to a PDS
   
   1. Every post is signed by a unique key that is whitelisted, either in advance or at the time of posting
   2. The use of a PDS ensures efficient storage while allowing for redundancy as desired
3. Client apps facilitate the routing of information based on the latest (or periodically updated) user profile state
4. Content consumers (and/or clients) verify that content is legitimate by making a call to the user’s whitelist to verify the post’s public key inclusion
5. Feedback is provided to a PDS if content is found to be unverifiable so that they can delete the data else risk losing reputation or business
6. Users may deny content simply by un-whitelisting keys, or may go further by publishing associated private keys for various degrees of deniability/tradeoffs

A simple example post object:

{ 

"id": "hash(content, user, timestamp, signer)”, // Hash of the record’s payload 

“content”: “hello world”,

“user”: <userID>,

"timestamp": <unix>,

"signer": <publicKey>,

"signature”: “signature(id)” // The "id" field signed by the signer privateKey

}

An example network:

Limitations

Soft timestamp enforcement — PDS/relayers must enforce timestamps, similar to Nostr, and likely require a reputation layer to ensure trust in content

Fairly heavy on the bandwidth — Requires more communication and API/RPC calls than alternative networks require

Utility in Other Domains

Maintaining privacy or pseudonymity in decentralized systems is a challenge when trying to prove reputation with public zk-certs. These zk-certs must remains accessible by anyone at any given time, but the anonymity set shrinks rapidly as you prove more things about yourself to the world. This is a potential way to alleviate this to some degree.

Building a publicly-accessible zk-cert service may be a way to provide this deniability without the constraints the high bandwidth requirements dictate for a social network.

TLDR;

In summary, the idea is simple. Users maintain a public list of public keys they attest to controlling. Posts, each signed with a unique key, can be attributed to the author so long as the user continues to include the corresponding public key in their whitelist.

‍