The Idea of an Immutable Social Media

Discuss on Hacker News.

Ever noticed how some people on the internet seem to perfectly predict the future? You’ll see accounts confidently declaring “This IPO will completely tank” or “This company is going to the moon.” Then, suspiciously, the posts that got it wrong quietly disappear, leaving behind a pristine timeline of seemingly psychic predictions.

Take a look at this tweet highlighting the phenomenon:

This creates a messy secondary problem. It’s not even that silent deletions happen constantly. It’s just that they are so easy to pull off. That alone leaves a permanent sliver of doubt. And because that doubt exists, it’s trivially easy to fake a screenshot of a “deleted post” to ruin someone’s credibility. As an audience, we are left in a bind: do we trust the original poster who claims they never said it, or the person holding the screenshot? Without any “negative proof” to validate either side, it just becomes a guessing game.

How do we actually tackle this?

I was thinking about this last week and sketched out an architecture. I think the design is solid enough that I’m half-tempted to build it myself. I figured I’d put the idea out here to get a second pair of eyes on it and see if it holds water.

Here’s the claim: not even a government takedown order can make a post un-happen. Delete it from every server I own, get a court to sign off on it, doesn’t matter. The post survives, permanently, provably. I want you to try and poke a hole in that.

Let’s build this iteratively by exploring the attack surfaces.

1. What if user wants to delete a post? What if government orders to take down a post?

Nope. User can’t delete a post. Platform disallows user-driven EDITs and DELETEs.

If your first thought is, “Just disable the UPDATE/DELETE endpoints in the backend”, I’m going to stop you right there. That’s just a promise, and promises can be broken by whoever controls the database.

Think about it: how do you actually know a platform like X.com isn’t secretly deleting posts? I know I’m making an impractical, borderline-conspiracy allegation here, and they probably aren’t doing it. But in theory and technically, it is absolutely possible. If they wanted to quietly edit the history for just 1% of their users, there is nothing systematically stopping them. They own the database.

So, it can’t just be a backend rule. It has to be immutable by design.

Instead, what if we take the raw bytes of the post (text, image, video attachments), hash them, and push that hash to a public blockchain?

This means anyone can download the post contents, run the hash themselves, and verify the proof of existence on the ledger. Even if I completely wipe it from my servers.

import hashlib
import json

def generate_immutable_proof(user_id, content, media_bytes):
    # Construct a deterministic payload
    payload = {
        "user": user_id,
        "text": content,
        "media_hash": hashlib.sha256(media_bytes).hexdigest() if media_bytes else None
    }
    
    # Serialize and hash the entire post state
    serialized = json.dumps(payload, sort_keys=True).encode('utf-8')
    post_hash = hashlib.sha256(serialized).hexdigest()
    
    # Only this hash goes to the blockchain, not the heavy payload!
    return post_hash

Obviously, the platform itself won’t allow edits or deletes on a post. But say a government orders me to take one down to keep operating in that country. Comply or get banned, no real choice there.

So I remove it from the DB. The URL 404s. I say I don’t have the data anymore, and technically, I’m right. There’s no post data on the blockchain either, just a hash.

So who actually has the data? Users, on their own machines. How does it keep circulating? Through other social media. Government can go ask them. Not my problem anymore, I deleted it.

Anyone who downloaded the post before I pulled it can still prove it existed. Hash it, compare against the chain, done. There’s no faking it, and there’s nothing I can do to stop it.

Obviously, we can’t expect users to manually stitch together JSON and run SHA-256 commands by hand. So the platform itself provides a “Download Proof” button on every post. Clicking it gives you a ZIP file containing the raw post text, media attachments, the cryptographic signatures, and a small standalone Python or bash script.

Download Post Proof UI

Run it locally, and this is basically all it does:

# verify_proof.py — runs entirely offline except the last line
post_hash = hashlib.sha256(load_local_files()).hexdigest()
onchain_hash = query_blockchain_node(post_hash)

assert post_hash == onchain_hash, "Proof failed — hash not found on chain"
print("Verified: this post existed and is unaltered.")

The beauty of this: the script never hits the platform’s servers. Even if my entire website gets nuked from orbit or legally shut down, that ZIP file remains a self-contained, mathematically undeniable receipt of what was said.

2. What if a user claims we altered their post?

A user might claim, “I didn’t write that! The platform admin altered my post in the database.” Fair concern, this is technically possible on any platform where an admin can just edit a row.

However, this is a solved problem: Digital Signatures.

When a user registers, we generate a public/private keypair deterministically from their username, password, and a server-side salt. On a new device, the client just re-derives the same keys, no manual key-transferring, no “please don’t lose this file” warnings (yes, I thought of everything).

Here’s the important bit: the password never leaves the user’s machine, and neither does the key generation. The server only ever receives a hash of the password to verify identity, it can’t reconstruct the seed on its own.

There’s a subtler problem here though. If the salt were public or guessable, this setup would basically be a brainwallet, and brainwallets get drained. Anyone could sit offline, grind through common passwords against a known salt, and just compute your private key without ever touching the server. So the salt is withheld until after the server verifies the correct username and password hash. Now an attacker can’t cook up keys in a vacuum, they have to go through the login endpoint one guess at a time, which means rate limits, lockouts, and every other login-abuse defense we already have now double as key-cracking defenses.

# client side
password_hash = hash(password)
salt = server.authenticate(username, password_hash)  # only returns AFTER verifying

if salt:
    private_key = argon2id(password, salt)  # slow, memory-hard KDF
    public_key = derive_public(private_key)
    # private_key never leaves this machine

That closes the offline attack, not the breach scenario. If the database ever leaks, an attacker walks away with salts and password hashes together, and it’s offline cracking all over again, weak passwords and all. Running the derivation through something slow and memory-hard like Argon2id buys real protection here, since it makes cracking weak passwords at scale expensive even with GPUs on hand. I’d probably also nudge users at sign-up that this password is now also a signing key, so maybe don’t reuse “password123.”

Every time they publish, their client signs the post hash using their private key.

If they change their password (meaning their keys change), we record it as a state change on our smart contract:

event UserEvent(
    bytes32 indexed userId,
    uint64 indexed sequence,
    uint8 eventType, // e.g., 0: ACCOUNT_CREATED, 1: KEY_ROTATED, 2: POST_CREATED
    bytes32 eventHash
);

To maintain the chain of trust during a password change, the client signs the new public key with the old private key, and vice versa. If a user entirely loses their password and requires an admin reset, we emit a PASSWORD_RESET event on-chain. Note that this is purely non-breaking: their older posts will continue to be displayed as verified using the historical keys active at the time of posting, since the key rotation happened well before the reset.

Misc: Isn’t there already a solution like this?

While researching this, I stumbled on Nostr. Turns out a good chunk of Section 1 and 2 already exists in the wild: client-held keys, signed posts, no central authority that can rewrite your words.

Where this design and Nostr part ways is proof of existence over time. Nostr can prove you signed something. It can’t prove when, beyond taking your client’s word for it, and it has no answer for “prove this existed before the event it’s predicting.” Deletion on Nostr is also just a polite request — relays can honor it or quietly ignore it, which is the exact failure mode we’re trying to kill here, just spread across more servers instead of one company.

So think of this less as “reinventing Nostr” and more as bolting a permanent, third-party-notarized timestamp (and a credibility layer for burner accounts) onto the same core idea. Could probably build this on top of Nostr’s event/relay model instead of from scratch. Something to explore.

3. What if a user claims we delayed their timestamp?

I can’t write to the blockchain the second someone hits “upload.” Gas fees and block times mean I’m realistically batching these hashes and pushing them every hour or so.

So a user could argue, “I posted that prediction before the event happened, but your proof only shows it existing an hour later. How do I know you didn’t sit on it?”

Fair point.

So the moment a post goes up, the backend fires the hash and signature off to a few Timestamp authority (TSA) servers, three different providers, say, so no single one going down ruins your day. Each one hands back a signed timestamp: a receipt saying “this exact hash was in front of us at this exact second.”

That receipt exists an hour before the blockchain batch even runs. So even though the chain write happens later, I’ve already got third-party proof of when it actually happened, no need to wait on the batch. The post can go live right away too, tagged “proof pending” until the batch catches up and locks it in permanently.

4. If TSAs are creating a proof of trust, what’s the purpose of the blockchain?

Fair question. If a TSA already gives me a trusted timestamp, why bother with a blockchain too?

Two reasons.

TSAs are stateless. I can’t ask a TSA “show me everything this user’s ever posted.” It just answers “was this hash presented at this time,” ONE at a time. It’s a stamp, not a ledger.

And a TSA is just a company. It can go under, get bought, get compromised, or start quietly backdating stuff if someone pays enough. You’d probably never know until it’s too late.

A blockchain doesn’t have either problem. Anyone can query a user’s full history, not just one hash at a time. And there’s no single company to lean on, altering it means rewriting what a bunch of independent nodes already agreed on. That’s expensive and hard to hide, unlike compromising one vendor.

So: TSA proves when. Blockchain proves what happened, permanently, without trusting one party to keep the receipts honest.

5. What if an attacker creates burner accounts for every outcome?

So what stops someone from just making a bunch of accounts to cover every outcome?

Account A posts: “The market will crash tomorrow.”

Account B posts: “The market will rally tomorrow.”

Reality: The market crashes.

They abandon Account B, and suddenly Account A is a genius.

Sure, that works once. But it doesn’t scale. Say a month later, another event comes up.

Account A posts: “Company X will get acquired.”

Account C posts: “Company X will not get acquired.” (Can’t reuse B, it’s already burned.)

Reality: Company X doesn’t get acquired.

Now Account A, the “genius” one, takes a hit too. To keep a spotless streak going for just 10 predictions in a row, you’d need 1,024 accounts (2 to the power of 10) running from the start, one for every possible branch of outcomes.

That’s a lot to juggle by hand, sure. A bot farm could probably pull it off, honestly, and I don’t have a clean answer for that yet. But at least it stops being something a random person does on a whim over a weekend. Might be enough friction, might not be. Open problem.

6. What if the accountability scares everyone away?

Fair question. Wouldn’t people be terrified of this level of accountability?

Yeah, probably some. That’s kind of the point, though. This isn’t for posting your lunch or a meme. It’s for people who actually want their words on the record.

There’s a real charm to platforms that let you delete stuff, honestly. Being able to post without it following you forever is worth something, and most social media doesn’t need to be this serious. This isn’t trying to replace that, it’s for the specific cases where the whole point is proving you meant it.

Picture a market analyst or a pundit making bold calls. If they start using this as their real channel, that says something, they’re standing behind it. If a rival won’t touch the platform, that says something too.

Doesn’t mean you can never be wrong. People change their minds, learn stuff, update their views, that’s normal. But there’s a difference between saying “I was wrong” and just quietly deleting the post so nobody remembers you said it.

Anyway, that’s the pitch. Tell me where it breaks, and whether you think there’s actually an audience for something like this.

Feel free to connect with me on LinkedIn

Thanks for reading!