There are two parties that suffer from spam: the relay and the group members.
In Bitchat’s Geohash open and permissionless channels, it is mainly the group members who suffer from spam, since the relay can quickly delete messages and is therefore less affected.
In contrast, Keychat’s end-to-end encrypted group chat is closed and permissioned: the group owner can add or remove members, and only group members can read and send messages.
As a result, Keychat group members do not suffer from spam. Moreover, because Keychat messages carry an ecash sat stamp, the relay also does not suffer from spam.
nostr:note19tv086ndagrxk64vnkm9jvhukvacfuectv0y9tj08r0w7h5ayslsvtvql0
Bitchat’s Geohash channels are open, permissionless chatrooms where anyone can participate and send messages. This is similar to how any Bitcoiner can send a Bitcoin transaction.
However, open, permissionless systems are especially prone to spam.
Because Bitcoin’s block size is limited, transactions must bid for inclusion, and only those that pay sufficient fees are included in blocks, so senders cannot spam.
If open, permissionless real-time chatrooms are as indispensable as open, permissionless monetary payment systems, we can expect them to evolve a fee mechanism.
Strictly speaking, it’s an open, permissionless chatroom—much like how any Bitcoiner can send a Bitcoin transaction.
It’s well worth exploring, unlike the advertising or tipping models—it’s a straightforward pay-for-information approach.
The Bitchat Geohash channel is an open forum displayed in a chat interface.
Compared to an open forum, a group places more emphasis on the member list—only those who are allowed to join can view the group chat and send messages.
Testing Coolr.chat in Keychat browser.
https://video.nostr.build/3e58ae8d1d6a22f6e27184012d0812e29eaae4113b44eb79b901c3be9a429542.mp4
Why is the Keychat Mini App needed? 👇
"
This is a simplification, but let's say that basically there are just 3 kinds of websites:
Websites with content: text, images, videos;
Websites that run full apps that do a ton of interactive stuff;
Websites with some interactive content that uses JavaScript, or "mini-apps”;
"
Testing Vlogstr in Keychat browser.
https://video.nostr.build/1bf654a816dc18ea5cbb282833ff65f30900b2bc7a907f82afbf8749a2615c4c.mp4
When you want to log into Keychat with your second ID on Amber, you need to first select that ID in Amber, and then log into Keychat. Try it — it should solve your problem.
When you create a new ID, do you choose Create ID from Seed Phrase?
This seems to be a bug, and we’ll fix it next week. Thanks for the feedback.
You can also log in to Keychat with Amber. Keychat uses a seed phrase to derive multiple IDs.
Keychat’s receiving address is updated using the Signal double ratchet, and so far rotating the receiving address has had almost no impact on the stability of message reception.
Do you mean, like how users can choose their own message relay, they could also choose their own message notification server?
We’ll give it a try once we’ve finished the tasks we currently have on hand.
Other than the fact that we don’t know how stable it is, there are no other obstacles.
As for message notifications, the most challenging issue is the following.👇
We’re also keeping an eye on unifiedpush.org
Keychat wants to use public keys as IDs in more contexts, and also extend the use of Sats to more scenarios.
If you’re also interested in Ark, we recommend reading the documentation on https://second.tech/. We look forward to them joining Nostr to share updates, and we’ve been closely following their latest progress.
Build a spending wallet based on these off-chain solutions that balances security and convenience, rather than a vault for long-term storage of large amounts of Bitcoin.
https://yakbak.app/ YakBak has been added to Keychat Mini App list.
If you want to send voice notes, make sure to enable microphone access for Keychat in your phone’s settings.
nostr:npub18ams6ewn5aj2n3wt2qawzglx9mr4nzksxhvrdc4gzrecw7n5tvjqctp424
I’m not sure I understand what you mean. Are you using https://following.space/ in the Keychat browser to create a list?
The Keychat browser simply provides a more user-friendly environment for Nostr web clients, making it easier to use the ID and wallet for login and zaps.
For example, an operating system-level bug.
This is how Jumble displays multiple images — very nice.
Keychat emulates a postal system. Each message is a letter; the relay functions as the post office, and every message carries a postage stamp—an ecash sat.
The Nostr public key serves as the user’s ID, while the sending address, receiving address, and encryption key are independent of that ID and rotate continuously.
For one-to-one and small groups, these components are generated and rotated by the Signal protocol; for large groups, they are generated and rotated by the MLS protocol.
Logging into Keychat with your microblog ID allows you to receive Nostr DMs (NIP-4, NIP-17), but this is just a supplementary feature. We recommend using a new ID on Keychat—one that is completely unrelated to your microblog account.
Signal and MLS protocols generate a new encryption key for each message and delete it after use. This makes both protocols stateful, with the state stored only locally. In contrast, NIP-17 messages use a static encryption key that doesn’t change, allowing any client to decrypt past messages upon login.
You can send a NIP-4 DM to this npub, or join Keychat’s public group chat. 👇
A new version of Keychat supporting payments to Lightning addresses will be released this week.
👇
https://video.nostr.build/f264ad3dbbd836ee04f77df47aff4f24b82b5da0f044488f500eb61c341427a2.mp4
“What are you doing? Playing games?”
“Actually, I’m browsing notes.”
https://video.nostr.build/aebd0460badc5da72058dc9b270a0c97842217456352a32c974947d6f67a1050.mp4
If you want to log in to the Mini App with a different ID, remember to log out of the currently logged-in ID first, as shown in the screenshot below.
The security of off-chain BTC is not uniform—counterparty risk increases in the following order: Lightning-Channel BTC → Ark BTC → Spark BTC → Liquid BTC → Cashu BTC → Custodial BTC.
The Lightning Network is a channel layer plus a routing layer. If you run your own channel, the routing layer lets you settle payments directly.
For the other five off-chain wallets, the operator shares its own Lightning channels with users, allowing them to send and receive Lightning payments.
Liquid example
• Paying — your wallet sends the same amount of L-BTC, and the operator pays the invoice through its channels.
• Receiving — the operator first receives BTC over Lightning, then sends you the equivalent L-BTC.
Liquid, Spark, and Ark can make users’ sending and receiving of Lightning payments atomic.
Lightning is the transport network—other off-chain solutions plug in as special nodes.
Signal, WhatsApp, and Telegram all rely on WebRTC (Web Real-Time Communication) for their real-time voice and video calls. In a one-to-one call, the connection process can be divided into three stages:
Signaling exchange
Each endpoint uses the app’s signaling server to exchange SDP (Session Description Protocol) messages and ICE (Interactive Connectivity Establishment) candidates—IP address, port, encryption parameters, and so on.
NAT traversal attempt — STUN → direct connection
The client leverages a STUN (Session Traversal Utilities for NAT) server to discover its public-facing address and then starts ICE connectivity checks. In typical home or mobile networks, about 75 % – 80 % of calls succeed in establishing a P2P (peer-to-peer) connection, with media flowing directly between the two devices over SRTP (Secure Real-time Transport Protocol) and no relay involved.
Fallback relay — TURN
If NAT (Network Address Translation) types such as symmetric NAT, CGNAT (Carrier-Grade NAT), a corporate firewall, or a VPN (Virtual Private Network) blocks direct connectivity, ICE automatically abandons P2P and switches to TURN (Traversal Using Relays around NAT) to relay the media. This happens in roughly 20 % of cases, but TURN ensures the call can still be established under the worst network conditions—at the cost of higher bandwidth usage and added latency.
Evolution of Receiving Addresses in Signal, Simplex Chat, and Keychat
A receiving address is indispensable to any chat application—just as an envelope needs only the recipient’s address. Because this address is exposed plaintext metadata, its design determines how much metadata privacy the user enjoys.
Signal each user has a single receiving address that is also their ID. For Bob and Carl alike, Alice’s address is always the same—simply A—and it never changes.
Simplex Chat Here, the receiving address (smp://
Keychat Keychat goes a step further: the address not only differs per contact but also rotates over time. Alice begins with A(b1)for Bob and A(c1) for Carl; after she replies, they become A(b2) and A(c2), and so on. Each time Alice responds to Bob, her address is refreshed. This dynamic, per-contact rotation provides even stronger privacy than Simplex’s static per-contact addresses.
We need more Mini Apps that support Nostr login and Lightning payments.
To enable that, Mini Apps require solid infrastructure — IDs and Wallet.
Keychat’s underlying IDs and Wallet are purpose-built to support these two core needs.
In Keychat, everything starts with a 12-word seed phrase.
The seed phrase derives multiple IDs, which can serve as both chat IDs and browser IDs.
It also derives the private key used to recover the wallet.
Both chatting and using mini apps in the browser rely on the ID and wallet.
For developers, building web applications offers unique advantages over native apps — lower technical barriers, faster development, cross-platform support, and the ability to publish without app store approval. In fact, for most (mini) apps, web apps are already very practical and easy to use.
However, for users, the experience of Nostr web apps is limited because browsers do not natively support Nostr ID login or Bitcoin payments.
Keychat solves this issue by combining its ID and wallet with browser, overcoming this limitation and improving the user experience.
Separating the ID, sending address, and receiving address is the first step toward protecting the metadata privacy of encrypted messages.
nostr:note1f6vw6cvnp0mt4s3nwakahffwf3qvh4z49kvt93l9gmqy9jpwd2ksfggmq6
Keychat is the super app for Bitcoiners.
Autonomous IDs, Bitcoin ecash wallet, secure chat, and rich mini apps — all in Keychat.
Autonomy. Security. Richness.
Let me use the metaphor of a letter to explain how Keychat processes messages: encrypting the content and filling out the envelope.
The content of the message is encrypted using either the Signal protocol or the MLS protocol. These protocols continuously derive new encryption keys behind the scenes for every message, ensuring forward and backward secrecy. Keychat leverages these open-source libraries directly, reusing libsignal and OpenMLS for encryption.
When filling out the envelope, it’s important to understand that the user name, sending address, and receiving address are all separate concepts. The envelope doesn’t include the name. The sending address can be left blank, which effectively means a new random sending address is generated for each message. The receiving address, on the other hand, is constantly rotated—but it must be known only to the two communicating parties, so it can’t be purely random.
Now you might ask: should each message include the next receiving address in its content? That approach works, but there’s a simpler solution. During encryption, a continuously evolving key—tied to the message encryption process and known only to the sender and recipient—can be used to deterministically derive the next receiving address.
Then attach a sat stamp, and finally send it to the Nostr relay.
Decouple first, then allow each component to fulfill its role more effectively. nostr:note1zkkxvfetp5entw9aq3s3jn2e0s5p3kurz0zudprz8ygtaagek64shahcv2
Nostr-double-ratchet tests finally passing. Both ratchets should be working now, but don't take my word for it 😄
Signal-style 1-on-1 chat encryption in ~200 lines of typescript. Now just need to make it work again on iris.to and then other clients. https://github.com/mmalmi/nostr-double-ratchet
Is Nostr-double-ratchet compatible with the libsignal of the Signal protocol?
How should we solve this metadata privacy issue?
There is a very intuitive and simple solution.
We need to differentiate between ID and address. ID and address are not the same thing, and IDs should not be used as addresses.
We should separate the sending address and receiving address from the ID, and then update the sending address and receiving address for each message as much as possible. nostr:note14x4ftwu38xm3ajund24r0a4emj0m88j7e0gtewclcsdanev6s5cs53jcz4
NIP-4 vs NIP-17 vs Signal Protocol vs MLS Protocol
Microblog DMs and standalone chat apps represent different scenarios and application types.
Microblog DMs prioritize multi-device synchronization over enhanced security, while standalone chat apps favor better security over multi-device synchronization.
NIP-4 and NIP-17 are suited for microblog DMs, while the Signal and MLS protocols are ideal for standalone chat app.
NIP-4 and NIP-17:
These protocols are suited for microblog DMs due to their efficient multi-device synchronization, as the encryption key and receiving address remain unchanged. Importing an nsec key allows users to receive and decrypt DM messages, which is ideal for microblog DMs.
However, this same feature becomes a disadvantage for standalone chat apps because it compromises forward secrecy and backward secrecy, and exposes the recipient's identity.
Signal Protocol and MLS Protocol:
These protocols update the encryption key with each message, and the receiving address can also be updated. This feature is best suited for standalone chat apps due to its robust security features.
However, this advantage turns into a disadvantage for microblog DMs due to poor multi-device synchronization capabilities. Simply importing an nsec key is not sufficient to receive and decrypt messages in such scenarios.
NIP-4 vs NIP-17:
Both NIP-4 and NIP-17 do not conceal the recipient’s identity. However, NIP-17 conceals the sender's identity, unlike NIP-4.
Signal Protocol vs MLS Protocol:
The Signal Protocol is best suited for one-on-one chats and small group chats.
The MLS Protocol is ideally suited for large-scale group chats.
The Signal protocol and the MLS (Message Layer Security) protocol are both designed for end-to-end encryption of messages.
The Signal protocol is particularly suited for one-on-one chats and small group. On the other hand, the MLS protocol is more appropriate for larger group.
Both can be implemented on Nostr.
If you are interested in understanding the basic principles of these protocols, I highly recommend the following two videos:
Keychat users can choose which relays to use. They can also choose not to use Keychat relays at all.
Relays can charge for stamps, but they can also operate for free, although free relays often have other restrictions, such as proof-of-work requirements for messages and frequency limits.
Relays decide which ecash sats issued by mints can be used as stamps.
If a user uses ecash sats issued by a mint that the relay trusts, the relay receives the ecash sats and forwards the message.
When a relay accumulates a certain amount of ecash sats, the relay requests the mint to convert these ecash sats into Lightning Network sats.
If a user uses ecash sats from a mint that the relay has not previously encountered, the relay first receives the ecash sats and then attempts to convert them into Lightning Network sats.
If the conversion is successful, the new mint can be temporarily considered trustworthy, and the message continues to be forwarded.
If the conversion is not successful, the new mint is added to a blacklist, and the message is not forwarded. 
Current chat applications and email have forgotten that an address is not the same as an ID, treating the ID as the address. Emails and current chat applications send messages as [from: Alice's ID to: Bob's ID]. Regardless of how your geographical address changes, when Alice sends an email to Bob, it’s always [from: Alice's ID to: Bob's ID]. This compromises metadata privacy.
However, letters work differently; they are [from: Alice's current geographical address to: Bob's current geographical address].
Keychat separates the receiving address and sending addresses from the ID, and the receiving address and sending addresses are also different. Keychat messages are [from: Alice's one-time sending address to: Bob's almost one-time receiving address]. This makes it difficult for outsiders and relay administrators to determine who is sending messages to whom.
(The new note has modified some expressions, making it clearer.） nostr:note1h842qj25shjm8yrl20y6nlm8yxynlmn33ggu2fj5mh9nmsyjnkgs8pgse4
In practice, when we fill out an envelope, we don’t need to include the sender’s information; we only need to write the recipient’s address, and there’s no need to write the recipient’s name. As long as the recipient’s address is precise enough, the letter can be successfully delivered. Not needing to write the sender’s information is equivalent to being able to write any random address. 
nostr:note13pu0ntgaywtjgfx0lpqlgk4sxxqcnq5aw9fcgrd88jhmuk9ytzcsy46q2c