Pubky is the next web

If you have ever built an online presence, you already know the problem: you can do everything right and still lose your reach, your account, or your audience because a platform changed the rules. Most of the web has no clean way to leave without starting over.

Pubky is built to fix that by making identity key-based and portable, so users can control where their content and data live.

We ran a private beta earlier this year, found the weak points, and rebuilt what needed rebuilding. Now Pubky is open to everyone.

• Join Pubky: https://pubky.app
• Learn how Pubky works: https://pubky.org

Start in one minute:

Users

Open https://pubky.app, create your identity, follow a few people, explore a few tags, and make a post. Then start tagging profiles and posts. You’ll immediately notice two things: Pubky is fast, and your view of the network is something you shape, not something fed to you.

Builders

Start at https://pubky.org, then jump into the Pubky SDK and homeserver repo: https://github.com/pubky/pubky-core. Pubky gives you an identity layer that is not based on platform accounts, and a data model designed for portability, so you can build services without owning the user.

What is Pubky?

Pubky is a key-based web protocol and ecosystem from Synonym.

Your public key is your identity, and it is portable. That identity is not owned by an app or a company. You can use different clients and services without losing who you are.

This matters because it gives you a credible exit. If a host, app, or indexer becomes hostile, unreliable, or simply annoying, you can move without starting over. Your identity and data do not need to be surrendered to participate.

Pubky uses PKARR (Public Key Addressable Resource Records) published on the BitTorrent Mainline DHT so identity is asserted by keys rather than granted by a gatekeeper.

Tags, not algorithms

Most platforms rely on opaque ranking and engagement inference. Users get a feed shaped by someone else’s business model.

Pubky uses tags, within a special social graph, as explicit context. That gives you a simple way to curate and discover content based on meaning. It also gives developers a clean surface to build discovery tools without hiding decisions inside a black box.

Pubky can be used socially, but it is not limited to social. It can support publishing, discovery, coordination, payments and other applications that benefit from shared identity and portable data.

What changed since the beta

The beta proved the concept. Then we focused on making it feel solid.

We rewrote the Pubky app to be local-first. Your state lives on your device, the interface stays fast, and sync happens without turning every action into a slow round trip. The result is a web app that stays responsive and stable even as your graph and content grow.

This launch is where we find out how the system behaves under real usage, and where we learn what people actually want to build on top of it.

Pubky Ring

Keys are the center of Pubky, and keys deserve proper tooling.

Pubky Ring is the companion mobile app for managing your Pubky keys, authorized sessions, and service access. It is the cleanest way to keep identity self-custodial while still using services across devices.

Use Pubky App to publish and discover. Use Pubky Ring to manage the identity that makes it yours.

The Pubky SDK is ready for action

Alongside the public launch, we are releasing the Pubky SDK so developers can build directly on top of the Pubky ecosystem.

The SDK packages the practical pieces you need: identity, authentication, data access, homeserver interaction, and client logic. The goal is straightforward: build apps where users keep their identity and data even if they switch clients or providers.

Join the Pubky builders community, who are already building cool apps with it!

Do the thing!

• Use Pubky: https://pubky.app
• Manage keys: https://pubkyring.app
• Build on Pubky: https://pubky.org and https://github.com/pubky/pubky-core

If you try it and something breaks, report it. If it rocks, tell your friends!

Opening Pubky was originally published in Pubky on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bitkit 2.0 is a full rewrite. We rebuilt the wallet as fully native iOS and Android apps to make Lightning faster, more reliable, and ready for real world use. This new foundation unlocks background payments, stronger OS integration, and a cleaner core experience, while preserving self custody and seamlessly migrating existing wallets.

Some features are intentionally sequenced for later so we can move faster and ship bigger improvements next. This release prioritizes correctness, performance, and long term growth over carrying forward features that would limit what Bitkit can become.

A new foundation, built native

Bitkit is now built the way modern mobile wallets are meant to be built. By moving away from a shared cross platform UI layer and rebuilding natively, we unlock:

• Faster launch times and smoother interactions
• Fewer edge case bugs and better stability
• Deeper integration with OS level features wallets depend on
• A foundation that scales with future Lightning and payment use cases

This is the base layer for everything that comes next.

Wake to pay: lightning that works in the real world

Bitkit can now receive Lightning payments even when the app is closed or your phone is locked (currently only available on Android). This enables real world flows like getting paid instantly at a counter or receiving funds while your phone is in your pocket. It also unlocks upcoming features like payment requests and subscriptions.

Seamless migration, no reset

Upgrading to Bitkit 2.0 does not mean starting over. Users keep their balances, Lightning setup, preferences, QuickPay configuration, and home screen widgets. The migration happens under the hood while your wallet stays yours.

Stronger OS integration, better reliability

Notifications, biometrics, and background behavior are now handled directly by the operating system. This results in more reliable notifications, smoother unlock and security flows, and better behavior when the app is not in the foreground. These are details users feel every day, even if they are invisible at first glance.

Bitcoin Map: Spend locally

In addition to the Shop feature, Bitkit now also includes a built-in Bitcoin Map so users can discover nearby merchants that accept Bitcoin. This positions Bitkit as a true spending wallet. Bitkit becomes a practical kit for using Bitcoin in the real world.

Cleaner send and receive

The most common actions are now simpler and safer. Send and receive flows have been polished to reduce friction, prevent mistakes, and make payments faster and more intuitive.

About contacts and profiles

Contacts and profiles are not included in 2.0. This was a conscious decision. Rather than rebuilding social features on deprecated technology, we chose to focus on a stronger core first. These features will return in a more powerful form through Paykit and Pubky, with better identity, richer Lightning flows, and stronger interoperability.

What comes next

Bitkit 2.0 is the base layer. The rebuild allows us to move faster, ship with more confidence, and expand the feature set beyond what was previously possible. We will share more later this year. Let us know what you think!

You can now download Bitkit 2.0 for Android or iOS

Bitkit 2.0: A new foundation was originally published in Bitkit on Medium, where people are continuing the conversation by highlighting and responding to this story.

ConsentKy was one of the more playful projects from our internal hackathon in Lugano, but beneath the humor is a clear demonstration of how Pubky’s identity tools can support simple, verifiable agreements between multiple users. The app uses Pubky Ring to collect consent from two people and then stores a signed, timestamped record of that agreement on each user’s Homeserver.

The concept is intentionally lighthearted, but the pattern it showcases is very real and broadly useful in decentralized identity workflows.

Core Idea: Mutual Consent With Cryptographic Proof

The flow is straightforward. Two users scan a Pubky Ring QR code, each approves the action, and once both have agreed, the app writes the result to their Homeservers. No accounts, no central service, no shared backend. Each user walks away with their own independently stored proof.

This makes ConsentKy a small example of how Pubky enables multi-party authorization without introducing trust in anything except the participants’ keys.

How ConsentKy Works

The interaction consists of just a few steps:

• User A opens ConsentKy
• User B scans the Pubky Ring QR code to authorize
• Both users click Agree
• ConsentKy writes a signed and timestamped “agreement” to each Homeserver via the Pubky SDK

Because the record is stored on both sides, each user maintains their own copy of the agreement. If the app vanished tomorrow, the data would still live with the identities that created it.

Why It Matters for Pubky

ConsentKy highlights a practical capability of the Pubky stack:

• Pubky Ring handles short-lived sessions and per-action authorization
• Pubky SDK writes create cryptographically anchored records tied to a user’s keys
• Homeservers give each participant their own authoritative copy of shared actions

This is the foundation for more serious use cases: approvals, shared ownership, multi-user workflows, or any scenario where two or more people need to authorize something together without relying on a central application to hold the record.

ConsentKy takes that pattern and wraps it in humor, but the underlying flow is genuine and technically grounded.

Github repo: https://github.com/jacobo-synonym/hackathon-2025/tree/main/consentky

ConsentKy: A Playful Experiment in Multi-User Consent With Pubky Ring was originally published in Pubky on Medium, where people are continuing the conversation by highlighting and responding to this story.

Core Idea: A Visual Cookbook for Pubky

Cooky organizes SDK examples into simple, focused “recipes.” Instead of searching through docs, developers can flip through curated snippets that cover identity, storage, discovery, and testing. Each recipe is readable, concise, and ready to paste into a project.

How Cooky Works

The interface behaves like a digital book:

• Flip through recipes
• Enlarge and copy code
• Bookmark useful snippets
• Mark recipes as “cooked” once tested
• Filter by keyword to find relevant examples

This gives developers a structured and accessible way to experiment with the SDK.

Why It Matters for Pubky

Pubky introduces new concepts, and onboarding developers can be challenging. Cooky helps by:

• Offering quick, copy-ready examples
• Making the SDK feel more approachable
• Encouraging hands-on exploration

It complements the official documentation by reducing friction and giving newcomers an immediate way to try things out.

A Simple Tool With Real Utility

Cooky is playful, but practical. It lowers the barrier to experimenting with Pubky and helps developers take their first steps in the ecosystem. You can try it at cooky.bolt.host.

Find it on GitHub: https://github.com/aldertnl/hackathon-2025/tree/main/cooky

Cooky: A Developer-Friendly Cookbook for Pubky SDK Recipes was originally published in Pubky on Medium, where people are continuing the conversation by highlighting and responding to this story.

Core Idea: A Lightweight Space to Try Pubky Interactions

Pubky Lab focuses on one purpose: letting developers quickly test public-key–based reads and writes against a Homeserver. It’s intentionally minimal and ideal for learning how the Pubky SDK behaves without setting up a full application.

To get started, you provide the Homeserver public key and, if required, a signup code. From there, the tool enables you to:

• Create a user
• Perform basic write operations
• Read values back
• List stored items
• Delete entries
• View logs as calls execute

This gives developers a direct feel for how the Pubky SDK manages data, permissions, and identity-based access.

How Pubky Lab Works

After generating a user and completing signup, each SDK call becomes a simple button press:

• Write operations return immediate success responses
• Reads confirm data stored on the Homeserver
• Listing retrieves all entries associated with the identity
• Deleting removes an item and updates the list on the next query

All logs appear in the interface and can be filtered by level, making it easy to observe request and response behavior.

Why It Matters for Pubky

Pubky Lab lowers the barrier for testing the SDK and understanding Pubky’s identity-driven data model. Instead of building an app or integrating with more complex tooling, developers can experiment with the fundamental calls directly in a controlled environment.

It is simple, but useful: a fast way to verify how Homeserver interactions work, to debug expectations, and to learn the basic flow of reading and writing with Pubky. It complements more advanced tools in the ecosystem by offering a clear entry point for experimentation.

GitHub repo: https://github.com/jvsena42/pubky-lab/

Pubky Lab: A Simple Playground for Testing Pubky SDK Calls was originally published in Pubky on Medium, where people are continuing the conversation by highlighting and responding to this story.

Core Idea: Direct, Scriptable Control Over Pubky

Pubky CLI provides a fast way to perform common Homeserver operations, including:

• Inspecting Homeserver status
• Creating signup tokens
• Registering new Pubky identities
• Publishing and managing files
• Disabling or enabling users

It uses the same underlying Pubky APIs as the SDK, but packaged into a lightweight tool suitable for automation, DevOps workflows, and development environments.

How Pubky CLI Works

The CLI exposes two main sets of commands: admin and user.

Admin operations

The admin info command displays the current state of the Homeserver, including user counts and available signup codes. Using the admin tools, operators can:

• Generate recovery files
• Create signup tokens
• Disable or enable users

This makes it easy to control access and manage accounts directly from the terminal.

User operations

To register a new user, the CLI walks through the same steps performed in the GUI flows. Using a signup token, a Homeserver address, and a recovery phrase, the CLI creates a new Pubky identity and registers it on the Homeserver.

Once registered, users can interact with their data:

• user publish uploads a file to the Homeserver
• user get retrieves a stored file
• user delete removes it

These operations rely entirely on Pubky’s key-based model. The recovery phrase acts as the user’s key material, enabling authentication and file operations without accounts or passwords.

Why It Matters for Pubky

Pubky CLI demonstrates how Pubky’s protocol can be used beyond apps and interfaces. Because everything in Pubky is key-based and API-driven, developers can manage identities, files, and server state directly from scripts or terminal workflows. This is important for server operators, automated provisioning, backups, testing, and any environment that benefits from programmable access.

The CLI uses the same primitives that power the Pubky App and the Pubky SDK, reinforcing the idea that Pubky is an open, modular stack where identity and data management can happen anywhere. It is a practical, developer-focused tool built on top of the core protocol and shows how flexible Pubky’s architecture is for real-world use cases.

Github repo: https://github.com/pubky/pubky-cli/

Pubky CLI: Command-Line Access to Pubky Homeservers was originally published in Pubky on Medium, where people are continuing the conversation by highlighting and responding to this story.

Core Idea: A Wiki Without Gatekeepers

Wikipedia is an extraordinary resource, but it has structural limitations. Pages can be locked, edits can be reverted or restricted, and content can be blocked or removed entirely depending on jurisdiction or server policy. When a page disappears or becomes inaccessible, the knowledge effectively disappears with it.

Wiky flips that model. Every page is published through the Pubky SDK onto user-owned Homeservers distributed globally. Anyone can fork any page without permission, modify it, and publish their version. There is no central admin and no single server whose decisions define what is visible or allowed.

How Wiky Works

The app uses Pubky Ring for authorization. After scanning the QR code, the user receives a session and can create or edit pages. Writing a page stores the content under the user’s Pubky identity, and each Homeserver write produces a unique page ID tied to that keypair.

Because this data is public, anyone who knows the user’s Pubky identity can inspect their published pages using a Pubky explorer. If someone wants to modify a page, they simply fork it, make changes, and publish their own version. There is no need to request access or obtain approval.

The system embraces divergence rather than preventing it. Instead of a single canonical version of an article, communities can maintain their own branches. Researchers, local groups, or niche communities can keep versions that reflect their needs, and readers can choose which branches they trust.

Why built with Pubky

Wiky demonstrates several core strengths of Pubky:

• Key-based publishing means users do not need accounts or roles to create or modify content.
• Homeserver distribution increases resilience, since pages live across many locations rather than a single host.
• Forkability is built in at the protocol level.
• No central authority can lock, delete, or freeze content.

It also illustrates how Pubky shifts publishing from a server-controlled model to a fully user-owned one. Instead of one organization enforcing consensus, content becomes a living, forkable graph of pages tied to cryptographic identities.

Github repo: https://github.com/ok300/hackathon-2025/tree/main/wiky

Wiky: A Decentralized, Forkable Wiki Built on Pubky was originally published in Pubky on Medium, where people are continuing the conversation by highlighting and responding to this story.

Core Idea: A Visual, Controllable Pubky Testbed

Publar gives developers a complete Pubky network in a sandboxed environment. It automatically handles:

• Local Homeserver creation
• Client connections
• PKARR records and a shared local DHT
• Log output and event tracing
• Indexer behavior and periodic reads
• Network actions like republishing or taking nodes offline

With everything running locally, developers can observe Pubky’s behavior end to end, break parts of the system intentionally, and inspect how components respond.

How Publar Works

When opened, Publar begins with an empty workspace. From there, developers can construct any network topology they want. For example:

• Add multiple Homeservers
• Add clients attached to those Homeservers
• Add indexers that read from them

Each Homeserver generates its own keypair and PKARR record and joins a local DHT. Developers can connect clients, read and write data, and inspect real-time logs from each node. Publar also exposes an HTTP server for every node it creates, so the simulated network can be used directly for development and testing.

Publar includes built-in scenarios as well. One example shown during the demo was an indexer test that simulates indexers reading data from multiple Homeservers. When the network is started, Publar boots each node, shows connections as they form, and streams the events as they happen. Developers can then trigger actions like forcing republishing or simulating node failures to see how the system behaves.

Why It Matters for Pubky

Publar fills a critical gap for developers working with decentralized identity and data routing. Pubky involves distributed components that interact across networks, and recreating these conditions manually can be slow and error-prone. Publar removes that friction by giving developers a fully controllable environment with no external dependencies.

Because everything runs locally, Publar is ideal for protocol development, debugging, and validating assumptions before deploying anything to real networks. It provides a way to visualize and understand Pubky’s identity routing, Homeserver behavior, and indexer logic in a contained space.

Github repo: https://github.com/afterburn/pubky-hackathon-2025/tree/main/publar

Publar: A Local Sandbox for Building and Testing Pubky Networks was originally published in Pubky on Medium, where people are continuing the conversation by highlighting and responding to this story.

Core Idea: Bookmarks as Pubky Data

Booky reads and writes bookmark folders directly to your Homeserver. When the extension loads, it pulls your folders into the browser’s bookmark bar. Any new bookmarks you add can be synced back to your Homeserver.

This makes your bookmarks:

• Portable across browsers
• Shareable with others through Pubky
• Private when needed
• Independent of any external sync provider

How Booky Works

After signing in with a recovery file or Pubky Ring, Booky creates bookmark folders based on what it finds on your Homeserver (for example, Priv, Private Sharing, Bitcoin).

You can also “monitor” a friend’s Pubky identity. Paste their Pubky into the extension and Booky pulls their shared bookmarks into your browser.

Booky supports several folder types:

• Priv — Only visible to you
• Private Sharing — Shared only with specific Pubkys
• Public folders — Visible to anyone monitoring your Pubky
• Group folders — If multiple users have a folder with the same name,Booky aggregates everyone’s bookmarks into one shared view

Adding a bookmark works like normal. Choose the folder and Booky syncs the entry automatically.

Why It Matters for Pubky

Booky shows how Pubky enables common features like syncing and sharing without centralized accounts. It uses:

• Pubky SDK for reading and writing data
• Homeservers for storage and syncing
• Pubky identities for access control

The extension is simply a client. The data stays with the user and can be accessed or extended by any compatible app.

Find it on Github: https://github.com/catch-21/hackathon-lugano-2025/tree/booky/booky

Booky: Sync and Share Browser Bookmarks Using Pubky was originally published in Pubky on Medium, where people are continuing the conversation by highlighting and responding to this story.

During our internal hackathon in Lugano, we introduced Pubky MCP Server, a Model Context Protocol server that exposes Pubky’s entire ecosystem to MCP-compatible editors such as Cursor. Its goal is straightforward: give developers a single tool that can answer questions, explain concepts, generate code, and bootstrap complete Pubky apps with minimal effort.

Core Idea: Pubky Knowledge and Tools in Your Editor

Pubky MCP Server packages the full Pubky ecosystem into an AI-ready interface. It includes:

• Documentation for PKARR, PKDNS, Pubky Core, Nexus, Social Graph, and more
• Code examples and scaffolding templates
• Development utilities
• Interactive guides and debugging tools

Instead of relying on search engines or models that may hallucinate incorrect details, MCP-compatible apps can query Pubky MCP directly and get authoritative, protocol-accurate information.

How Pubky MCP Works

Once connected in an editor like Cursor, the MCP server becomes the primary source of truth for anything related to Pubky. The project includes an agents.md file that defines routing rules: any Pubky-related query is handled by the MCP server before the editor consults external internet sources.

From there, the workflow is simple:

• Ask broad questions such as “What is Pubky?”
• Debug errors like a 403 when writing to a pub path
• Request explanations of Pubky architecture layers
• Generate code examples, such as creating a PKARR keypair
• Produce scaffolds or full applications using the Pubky SDK

The tool does more than documentation lookup. It can analyze issues, propose fixes, validate data, and create project structures tailored to the user’s framework.

One example shown in the demo was generating a complete Next.js application: a Pubky SDK recipe “cookbook” with filtering, search, bookmarking, and copy-ready code snippets. The MCP server provided the architecture, components, and logic in a single request, producing a functional app in seconds.

Why It Matters for Pubky

Pubky MCP lowers the learning curve for developers and makes the entire ecosystem easier to build with. It ensures that development environments consistently reference accurate Pubky APIs and concepts, avoiding guesswork and misinterpretation. Because Pubky is key-based and modular, having a precise source of truth is essential for correct implementation.

The project also shows how well Pubky fits AI-assisted development workflows. MCP lets developers “vibecode” Pubky applications using real tools, not generic model intuition. It speeds up onboarding, simplifies experimentation, and helps developers create functional prototypes quickly.

Github repo: https://github.com/infin1t3/hackathon-2025/tree/main/pubky-mcp-server

Pubky MCP Server: An AI-Ready Interface for the Entire Pubky Stack was originally published in Pubky on Medium, where people are continuing the conversation by highlighting and responding to this story.