Many users care deeply about whether Keychat will eventually support a true multi-device experience, where the same ID can be used seamlessly across several devices. Keychat relies on ratchet algorithms from the Signal and MLS protocols, deriving a fresh encryption key for every single message and discarding it after use. This makes the system inherently stateful—the cryptographic state on each device is constantly evolving—and it ensures that both past and future messages remain protected even if a device’s encryption state is later compromised. This property is known as forward secrecy and backward secrecy (also called post-compromise security). For exactly this reason, Keychat cannot behave like Nostr DMs (NIP-4, NIP-17), which reuse a static encryption key and therefore lack forward and backward secrecy, or like Telegram, which by default does not use end-to-end encryption, and simply allow the same ID to be logged in and used actively on multiple devices at the same time. When we think about multi-device support in Keychat, we can start from a baseline design. Suppose Alice and Bob each have a smartphone and a computer with Keychat installed. When they chat, those four devices can conceptually form a four-device group, where each pair of devices maintains its own secure session. From there, we still need a more refined design that improves this experience and avoids relying on centralized servers.

In the past, we largely overlooked this Lightning Pub–style design direction.

Lightning.pub

LIGHTNING.pub — Lightning shouldn’t be a hobby that loses money.

Turn Lightning from a tinkering cost into a revenue-generating asset — guests, commerce, one always-online Pub. Live in under a minute.

Most conversations about “second-best” Lightning wallet models tend to focus on large global hubs—custodial Lightning wallets or new protocols like Ark and Spark. It’s worth stepping back and mapping out the design space more clearly. When users run their own Lightning nodes and channels, they are both part of a decentralized network and in full custody of their own funds. This is the ideal wallet model. In reality, not everyone can do this. That opens up a design space for “second-best” solutions, mainly along two axes: the degree of centralization and the degree of third-party custody. It’s important to note that centralization and third-party custody do not always perfectly overlap. In other words, a centralized architecture does not necessarily mean that 100% of funds are fully custodial at all times. 1. For wallets like Coinos and Wallet of Satoshi, they are both global hubs and fully custodial: user funds are entirely under the control of the service operator. 2. Ark and Spark also move in the direction of global hubs. They still follow a server–client architecture, but their goal is to allow users to exit unilaterally. If the service fails, users should still be able to move their funds back on-chain into UTXOs they control, getting as close as possible to self-custody. However, their default transfers do not achieve Lightning’s instant finality. There is a time window in which the service provider and the previous owner of the funds (and in many cases, the operator is also the previous owner) could theoretically collude to double-spend. During those windows, users are not at 100% self-custody over their funds. 3. Lightning Pub takes a different path: its goal is to let more technically capable users provide custodial wallets to their friends and become local micro-hubs. Its focus is on lowering the technical barrier for “sharing your own Lightning node and channels” with people around you. That’s why Lightning Pub: 1. uses Nostr IDs as the basis for its built-in multi-user account system, and 2. uses encrypted messages relayed over Nostr relays (DM/RPC) to connect front-end wallets with the back-end node. So Lightning Pub is the Nostr-native Lightning node. In this sense, Lightning Pub effectively gives more people the opportunity to run their own small Wallet of Satoshi / Coinos–style custodial Lightning wallet, but scoped to a local circle of friends. Because these relationships are often built on existing social trust, the risks normally associated with third-party custody are partially mitigated. Once large, obvious centralized service hubs emerge, whether they are traditional custodial Lightning wallets or large Ark/Spark operators, they become much easier targets for regulators and governments to shut down. View quoted note →

Our first AQSTR campaign, Help the world discover Keychat, has now concluded. Thank you to everyone who participated, and to AQSTR for providing such a beautifully designed tool. View quoted note →

We’re incredibly grateful to all the users who’ve been recommending Keychat. Keychat relies on our users’ word of mouth to reach more people. View quoted note →

Here are two more mini-games you can play in Keychat.

Nostr Wars 3D

Blockstr - Bitcoin-Powered Tetris

Play Tetris with Bitcoin blocks! Speed increases as new Bitcoin blocks are found. Pay to play with Lightning, publish scores to Nostr.

View quoted note →

We feel that AQSTR @AQSTR could become the Product Hunt of Nostr, and that more and more apps will start launching there. We discovered ZapWork @zapwork while browsing AQSTR.

Keychat doesn’t remake the beads — it simply threads the pearls that already exist into a coherent whole. View quoted note →

@Stacker News We love how Stacker News charges 1 sat per reply — it immediately made us think of Keychat relays, where a 1-sat digital stamp is required before a message gets forwarded. If Stacker News added an “Open Wallet” button beneath the invoice, paying right inside the Keychat browser would feel much smoother.

Non-technical users can verify whether Keychat’s high-level design is sound — you don’t have to be a developer to do so. View quoted note →

In the Keychat browser, you can log in to Stacker.news with your Keychat ID and start posting right away — that’s the power of an autonomous public-key ID.

Stacker News

We made a five-minute Keychat overview video to help viewers grasp its design \ stacker news

@Keychat stacked 100 sats posting https://dev.nosotros.app/nevent1qvzqqqqqqypzpwleyw4fy3sxt7yvgrran0mpenxqlululur94r9jlax0hd3q3rc7qyxhwumn8ghj7mn0w...

Keychat’s goal of building an autonomous online Me serves as the thread that strings together existing beads — the Nostr protocol, Bitcoin graduated wallets (currently Cashu ecash), the Signal and MLS protocols, and Web Apps via WebView. View quoted note →

The new version of Keychat we’re working on can receive Nostr DMs (NIP-4 and NIP-17) and reply to them. However, the end-to-end encryption scheme for Nostr DMs always uses the Nostr ID’s private key for encryption and lacks both forward secrecy and post-compromise security (PCS). If the private key is ever compromised, all past and future messages are at risk of being decrypted by others. Because of this, Keychat labels Nostr DMs as “weak encryption” and displays a danger warning in the top-right corner.