For those of you that missed my presentation in Lugano, here is a tweetstorm summary and introduction to our new Pubky ecosystem.
Let's begin! 👇
The Problem: A Captured Web
The web today is a mess of poisoned algorithms, censorship, and walled gardens.
🕸️ Poisoned Algorithms
Big Tech feeds you what serves them: corporate and state interests, toxic engagement, user manipulation... Algorithms are broken, and they’re breaking us.
Big Tech hates you.
🚫 Censorship
Think you’ve got free speech online? Not so fast. Platforms and governments decide what’s allowed, what’s “truth.”
The net’s compromised. It's not about what you say, it’s about what they let you say.
Big Tech is compromised.
🧱Walled Gardens
Big Tech’s idea of a web? Lock you in their app, farm your data, and make you pay for the privilege.
Your data is locked up in ecosystems that serve them. It’s digital serfdom, not freedom.
Their house, their rules.
Attempts to Fix the Web (So Far)
There’ve been attempts to "fix" the web, and made notable progress. Let’s talk Mastodon, Nostr, Bluesky, and where they have fallen short.
Activity Pub / Threads, Mastodon
Pros: Federated servers, community control, open-source.
Cons: Identity isn’t portable, centralized moderation doesn’t help if a server bans you. You’re still at someone else’s mercy.
Matrix / Element, etc
Pros: Decentralized real-time communication built to replace traditional chats. E2E encryption.
Cons: Federation still has a level of central control from larger servers. Complex infra makes it harder for users to run their own server.
Nostr / Primal, Damus, etc
Pros: Key-based identity. Resistant to some censorship. Super simple to start.
Cons: Scales poorly. No identity-based routing. No real delegation options. It’s a decentralized beginning, but lack of intentional design left gaps in the system.
Cons: DID depends on PLC directory — a centralized failure point.
We think there is a better way to unlock the web, so we built it.
Introducing Pubky
Vision
Pubky is a key-oriented, user-controlled web. Own your data, identity, and content. Break free from Big Tech.
Pubky Core
The decentralized protocol that powers Pubky. Identity, data routing, hosting.
Pubky App
Your interface to this new web. It’s a publishing tool, a curation engine, with personalized feeds, social tagging, and curation controlled by you.
Pubky Core: The Protocol
Let’s dig into what Pubky Core brings to the table.
Here’s what makes Pubky Core truly next-gen: PKARR, Mainline DHT, and Homeservers.
PKARR (Public Key Addressable Resource Records)
You hold the keys to your digital kingdom.
Your identity, data, and contacts are portable and censorship-resistant.
Your key is your uncensorable domain name.
Mainline DHT
Think BitTorrent tech, but for the web.
Decentralized peer discovery that scales.
20 million nodes. Global, resilient. Real P2P.
Homeservers
No lock-in, no walls. Anyone can run a homeserver. The same UX as "Log in with Google" — but with true freedom and control over sessions.
If your server bans you? Move. Carry on.
A Credible Exit
No one should control your social graph, data, or reputation but you.
With Pubky, you take it all with you.
Migration is built-in. True resilience and availability, built for users.
HTTP-friendly URLs
Not everything has to be some blockchain acronym.
Pubky is practical: normal HTTPS URLs, seamless integration, and a focus on usability.
Pubky Core Is Available Now
This isn’t vaporware. We’re open source, and we’re live.
Good morning, Bitcoin does not support or enforce any sort of "transactions" or "settlements."
These actions are misnamed within the protocol and Bitcoin literature.
1/10
A bitcoin "transaction" or "txn" or "tx" is actually a signed authorization to update the score of an originating account to redistribute its units into other accounts.
It is a proof, or a payment, not a transaction.
2/10
Nodes store these proofs in a temporary cache called the "mempool" until they're included in a new block by miners, validated by what is called "probabilistic finality."
Actual commerce and transacting happens outside of Bitcoin between peers in the physical world.
After weeks of arguing and consideration, I am now confident I can refute all arguments for a full-RBF regime, and that we should protect first-seen mempool policy from being subverted by keeping the existing environment intact.
1/5
My arguments include clear rationale that consider miners, incentive compatibility, maximization of fees per block, priority competition, utility for merchants, intelligent doublespend risk mitigation, protection of the user space, optimal culture of development of Bitcoin,
2/5
and optimizartion of Bitcoin adoption, utility, and activity.
What I do not know is the best path to communicating these learnings to Core, and best process for civilly halting the damage of the full-RBF regime.
3/5
I will be freezing my personal Bitcoin Core nodes at the current version (pre-taproot) permanently, barring any critical CVE fixes or such.
I will also stop using native segwit addresses and never use taproot (my nodes don't support it anyway).
Maybe this is inconsequential in the long run, but Bitcoin conservatism needs to start somewhere and I find the culture of Core to have soured and become reckless, and I simply do not want to trust my coin with their leadership any longer.
99% of users *should* be doing the same as me, simply because few of us are qualified to assess the code changes and complexity implications, making this a totally trusted process.
"Don't trust, verify" only works when you can actually verify.
A subset of Core devs are currently trying to attack Bitcoin by forcing a pet agenda to make all transactions RBF by default.
This attack includes bitcoin-dev mailing list lies and lobbying, code changes in Core node, and bribery attempts to miners.
1/5
Merchants rely on 0-conf txns as a way to meet consumer needs in commerce. RBF makes the mempool less reliable and spending Bitcoin more dangerous for consumers and businesses.
2/5
Bitcoin ATMs, Bitrefill, Muun, our company (Synonym/Blocktank) and any merchant can manage doublespend risks easily. We are working on tools to make 0conf acceptance easier/safer, but some devs would rather try and break a Bitcoin use case to protect their niche designs.
3/5