keychat
Keychat

https://www.keychat.io/

Keychat is the super app for Bitcoiners.
Autonomous IDs, Bitcoin ecash wallet, secure chat, and rich Mini Apps — all in Keychat.
Autonomy. Security. Richness.

https://www.keychat.io/

Public Key

npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8

Profile Code

nprofile1qqsth7fr42fyvpjl3rzqclvm7cwves8l8l8lqedgevhlfnamvgyg78spz4mhxue69uhk2er9dchxummnw3ezumrpdejq9hyvnq

Publishing to

eden.nostr.land

Author Public Key

npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8

Show more details

Last Notes

2025-07-18 14:43:08 GMT

Each message in Keychat is more independent, as almost every message changes both the sending and receiving addresses, like arrows shot from all directions to all directions, making it difficult for outsiders to identify the sender and the recipient.
#nevent1q…lsju

2025-07-10 13:58:16 GMT

It’s time for some nonlinear reading.
https://video.nostr.build/98a21f0d8b5766ffb56d7a5fbf33b61a07145215f7f7307ea1edfbebc39c6717.mp4

2025-07-10 11:17:53 GMT

- reply

🤷

2025-07-10 05:34:05 GMT

Many people are curious about the difference between Keychat and White Noise.
Keychat encrypts one-to-one chats and small groups with the Signal protocol, while large groups use MLS encryption. White Noise, by contrast, encrypts every message solely with MLS.
Think of each message as a letter: both Keychat and White Noise rely on OpenMLS to encrypt the content inside. The main distinction lies in the envelope—the format of the recipient address and how that address rotates.
For large-group messages, Keychat adopts exactly the same envelope as a Nostr direct message (NIP-17), blending the traffic so thoroughly that an outside observer cannot distinguish a Keychat message from a Nostr DM.
Why does Keychat choose the Signal protocol over MLS for one-to-one chats? Because Signal’s ratchet advances more frequently than MLS’s, providing stronger post-compromise security.
Could Keychat’s large groups interoperate with White Noise’s groups in the future? Quite possible—after all, the two are already 90 % identical.
#nevent1q…yypn

2025-07-09 09:51:25 GMT

- reply

A new version of Keychat supporting payments to Lightning addresses will be released this week.
👇
https://video.nostr.build/f264ad3dbbd836ee04f77df47aff4f24b82b5da0f044488f500eb61c341427a2.mp4

2025-07-09 04:30:18 GMT

- reply

Keychat currently only supports Nostr Zaps (NIP-57). Its built-in Cashu wallet doesn’t yet support direct Lightning address transfers, so that feature still needs to be developed.
https://github.com/nostr-protocol/nips/blob/master/57.md

2025-07-09 03:56:24 GMT

- reply

Yeah, in Keychat browser.

2025-07-09 03:49:31 GMT

- reply

After clicking the QR code, I encountered this error. Also, it would be even better if there were an “Open Bitcoin wallet” button.
https://image.nostr.build/f141732c77ae43e7b1d1d14e9cb478ba663e140aec1fb9c98060f429d5e4933f.jpg
https://image.nostr.build/ab1161ebf861ddc18c89851c44a154516ad1e25cc888f8c65df4757fb1e6bcd9.jpg

2025-07-07 06:45:50 GMT

https://image.nostr.build/92496f12e3c641e2d6fc2c817dbb1fab812f2463742e982631531556365f7d4c.jpg
#nevent1q…4snt

2025-07-07 06:20:19 GMT

Need more practice 😂
https://video.nostr.build/2777fc463fbe5c516419f13f75dc0068f30ada7f26af1ace6ff4666b92a8c1f9.mp4
#nevent1q…gmty

2025-07-06 05:35:29 GMT

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.
https://image.nostr.build/fdcf35c31f4ca50916ff6d1ae3d159f89480b1e1ff017c20763d627af0322864.png

2025-07-02 04:15:24 GMT

Spark is a variant of Statechains.
Statechains are an original second-layer protocol originally developed by Ruben Somsen in 2018.
Statechains are a proposed off-chain system that allows a user (such as Alice) to delegate the ability to spend a UTXO to another user (Bob), who can then further delegate the spending authority to a third user (Carol), and so on.
The off-chain delegation operations are all performed using signature adaptors and the cooperation of a trusted third party who employs the eltoo mechanism—and their knowledge of every previous delegation—to ensure each new delegation uses a state number higher than any previously used state number. These incrementing state numbers ensure that an on-chain spend by the most recent delegate (Carol) can take precedence over spends by previous delegates (Alice and Bob), provided the trusted third party hasn’t colluded with a previous delegate to cheat.
Beyond collusion with a delegated signer (such as Alice or Bob), there is no way for the trusted third party to steal funds. A delegated signer can always spend the UTXO on-chain without needing permission from the trusted third party, arguably making Statechains less trusted than federated sidechains.
We can think of Statechains as a digital version of Opendime. We know that Statechains can’t provide the same trustless self-custody as the Lightning Network, but we still like them. Statechains can be part of the Lightning Network.
https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39
https://bitcoinops.org/en/topics/statechains/
https://opendime.com/
https://bitcoinmagazine.com/technical/bitcoin-layer-2-statechains
https://www.spark.money/
#nevent1q…vlc6

2025-06-23 12:04:54 GMT

Keychat Mini Game
https://video.nostr.build/b713818a276022df7a8f86c28959f8a1434ee1f69a93a99b363dfc6b9e27668d.mp4

2025-06-21 05:15:18 GMT

Keet uses the Holepunch stack—not WebRTC—for its real-time voice calls. In a one-to-one call the connection likewise falls into three logical stages:
1 · Peer-discovery exchange
Each endpoint relies on HyperDHT ( Distributed Hash Table) to locate the other party:
The caller joins the network with the callee’s 32-byte Ed25519 public key.
Nearby DHT nodes return the latest announce record published by that key—essentially “I’m online at 203.0.113.7:54567”.
A short-lived, signed invitation token proves the request really comes from the owner of the calling key, preventing spam.
No central signaling server is involved; the DHT itself is the rendez-vous layer.
2 · Distributed hole-punch — DHP → direct connection
The two devices attempt to break through their NATs with DHP (Distributed Hole Punching) and then talk over UDX (Ultra-Datagram eXchange):
Each side enlists several random DHT peers as hole-punch helpers—they play the same role that STUN servers do in WebRTC but are fully decentralized.
Both endpoints fire simultaneous UDX probes at every candidate (IP:port) they learn.
As soon as one path succeeds, a one-round-trip Noise_XX handshake derives a session key, and encrypted audio frames start flowing directly between devices.
In residential or mobile networks this succeeds ~70 %–80 % of the time, giving a pure P2P (peer-to-peer) path with minimal latency—no relay, no bandwidth fees.
3 · Volunteer relay fallback
If symmetric NAT (Network Address Translation), CGNAT (Carrier-Grade NAT), or a strict firewall blocks every hole-punch attempt:
Keet asks nearby peers whether any is willing to act as a relay for this call.
If at least one agrees, the audio stream is tunneled through that peer—still encrypted end-to-end by Noise—so neither relay nor network can eavesdrop.
When no volunteer relay is available, the call fails; Keet has no equivalent to TURN (Traversal Using Relays around NAT) hosted in a central data-center.
#nevent1q…280p

2025-06-20 09:00:06 GMT

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.

2025-06-19 13:07:18 GMT

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://<queueKey>@<relay-host>/<queueId>) is different for every contact. Alice has one fixed address for Bob, A(b), and another for Carl, A(c). Having separate—but constant—addresses for each contact is already a significant improvement over Signal’s single, global address.
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.

2025-06-12 14:33:33 GMT

Highly recommend watching this talk — it gives an overview of well-designed Bitcoin payment solutions from the perspective of the Lightning Network.
#nevent1q…tenh

2025-06-11 09:49:23 GMT

https://image.nostr.build/3fc46b53a09b3aa3cefea3a0d2bf594786a565d83b57eb7c79f6d672b87ebaf8.png
https://youtu.be/GDYrGPb__cA
#nevent1q…n6ff

2025-06-10 07:06:04 GMT

This internal test version of Keychat shows users which actions in a Mini App trigger a signature request.
https://video.nostr.build/70041a33f363714d91c3af9e3655b3c8d8a8ba13596fab8da7d4d9d2e3e0bcd7.mp4

2025-06-08 15:53:33 GMT

- reply

That’s a strange bug. We’ll need to look into it. Thank you for your feedback.

2025-06-08 15:45:43 GMT

- reply

Is the Keychat version on your Pixel phone also the latest one?

2025-06-08 09:07:52 GMT

- reply

Please update Keychat to the latest version on both phones. You can download it from https://github.com/keychat-io/keychat-app or from Zapstore. Then try creating the group again.

2025-06-08 07:49:25 GMT

- reply

That’s a bit strange. What version of Keychat are you using?

2025-06-08 04:10:49 GMT

Testing Nostr Punchcard.
https://video.nostr.build/964c24ac09844c69936815b6ee51e3a608dbc08a745eb39755df1cb4957c9992.mp4
#nevent1q…9hzd

2025-06-05 08:07:08 GMT

GM
#nevent1q…h4xy

2025-06-02 15:46:20 GMT

If you operate your own Lightning channel, that’s the best case — you can use a fully native Lightning wallet.
If not, the five wallets mentioned above, each with their own tradeoffs, can still be used to send and receive Lightning payments by leveraging the service provider’s inbound liquidity. The difference lies in how “bitcoin” is stored under the hood — each takes a different form.
When both sender and receiver use the same provider and system, payments are typically settled internally without touching the Lightning Network. But if they’re on different providers, the payment is routed through the Lightning Network.
#nevent1q…qm7d

2025-06-02 15:37:34 GMT

- reply

We submitted Keychat to both the Apple Store and Google Play at the same time, but it’s still under review on Google Play. You can download Keychat from Zapstore @npub10r8…t2p8 in the meantime.

2025-06-02 15:03:54 GMT

https://image.nostr.build/0d19e6b5208656e89d4a67ead8c2fcf636bdecf82566ffef5eae1d6b2b842259.png

2025-05-31 13:41:46 GMT

- reply

We've been using the metaphor of a letter: the envelope is where the sending and receiving addresses are written. To protect metadata privacy, both the sending and receiving addresses need to be updated frequently.
NIP-EE group events
{
"id": <id>,
"kind": 445,
"created_at": <unix timestamp in seconds>,
"pubkey": <ephemeral sender pubkey>,
"content": <NIP-44 encrypted serialized MLSMessage object>,
"tags": [
["h", <group id>]
],
"sig": <signed with ephemeral sender key>
}
In the NIP-EE group event, the content field is first encrypted using MLS, and then encrypted again using NIP-44. The NIP-44 encryption is done using a Nostr keypair generated from the MLS exporter_secret to calculate the conversation key value. Keychat follows the same approach. The public key—used as the sender address—is randomly generated, and Keychat does this as well.
The difference lies in the receiving address. In NIP-EE, the receiving address is set using:
"tags": [ ["h", <group id>] ]
The h tag represents the Nostr group ID (from the Nostr Group Data Extension). Updating the group ID requires a member to send a commit message.
Keychat, on the other hand, uses:
"tags": [ ["p", <receiverPublicKey>] ]
This receiverPublicKey is derived from the MLS exporter_secret, so it updates automatically without the need for a separate commit message.
Keychat uses kind: 1059, as it satisfies the constraints of kind 1059, enabling the integration of both MLS messages and NIP-17 DMs in a unified format.

2025-05-31 12:10:06 GMT

- reply

Interoperability between the three clients in an MLS group isn’t hard, since they’re all built on OpenMLS and use shared relays.
The main difference is that Keychat uses a different “envelope” format for MLS messages compared to the other two clients. We need to write a note explaining the design rationale behind this “envelope” format, and we truly hope to have 0xChat’s understanding and support.

2025-05-31 11:53:10 GMT

- reply

In MLS, multi-device sync is achieved by multiple device IDs (leaf nodes) sharing a single user identity. Each device has its own leaf but proves it belongs to the same user via the same identity credential.
Each device joins the same MLS group as a separate leaf node, but all represent the same user.

2025-05-30 14:53:35 GMT

Testing NOL
https://video.nostr.build/1d81e5a0173ace9c8a3d820922e32bd600c0e1ab77f0116fd18ae52087507a79.mp4
#nevent1q…83r5

2025-05-23 02:25:19 GMT

- reply

It looks like the download was incomplete?

2025-05-22 00:31:21 GMT

- reply

Thanks. It works after delete local cache.
@npub1kun…3lhe
@npub1vxd…rs50

2025-05-21 14:10:14 GMT

- reply

Peergos is based on IPFS. I don’t know much about it — do you think IPFS is actually viable, or is it just a nice idea?

2025-05-21 09:48:33 GMT

- reply

Thank you for your analysis and suggestions. Blossom is mainly designed for storing public, unencrypted files.
One more question — are you satisfied with how Blossom performs in the second scenario?

2025-05-21 09:09:23 GMT

- reply

We have considered three scenarios:
The first scenario is hosting images and videos used in chat rooms. These need to be end-to-end encrypted and stored for about one or two weeks. Users typically access them only once within the chat room. No separate interface is needed—configuration can be done in the chat settings.
The second scenario is hosting images and videos for microblog posts. Since they are meant to be viewed by followers, encryption is not necessary, and the files should be stored for a long time. No separate interface is needed—configuration can be done in the microblog client, similar to setting a relay.
The third scenario is backing up important files. These must be end-to-end encrypted, stored for a long time, and require a dedicated interface to display all saved files.
For the third scenarios where files need to be end-to-end encrypted, our idea is to perform the encryption on the client side before uploading. We hope to see a Mini App like this, where users can log in using their own key pair and optionally pay with their wallet.

2025-05-21 08:13:22 GMT

- reply

What do you think about using multiple paid Blossom servers simultaneously to back up important files? Users would pay a monthly fee. The model is similar to using safety deposit boxes at several banks.

2025-05-21 04:45:12 GMT

- reply

That seems to be a design limitation of NIP-29.

2025-05-21 02:52:26 GMT

- reply

The relay is only responsible for forwarding messages; everything else is outside its concern. The group member list is determined by the group owner.

2025-05-21 02:35:05 GMT

- reply

If the user opens the group client, it only needs to fetch messages from multiple relays—specifically, messages from the last timestamp up to the current time. The client then uses the messages from whichever relay responds the fastest.

2025-05-21 02:20:43 GMT

- reply

> The main advantage is message stability and consistency.
🤔🤔🤔 Don’t think so.

2025-05-21 02:13:58 GMT

- reply

“ Normally a group will originally belong to one specific relay, but the community may choose to move the group to other relays or even fork the group so it exists in different forms -- still using the same id -- across different relays.”
It seems that NIP-29 was designed specifically to support only a single relay.

2025-05-21 02:10:46 GMT

- reply

Can 0xChat’s NIP-29 group work with multiple relays?
By the way, do you prefer group support for a single relay or multiple relays?

2025-05-21 01:50:35 GMT

We believe the biggest problem with NIP-29 is that it only supports a single relay, which goes against one of Nostr’s core features — the ability to use multiple relays.
#nevent1q…sj6p

2025-05-21 01:43:55 GMT

- reply

We believe the biggest problem with NIP-29 is that it only supports a single relay, which goes against one of Nostr’s core features — the ability to use multiple relays.

2025-05-20 16:16:58 GMT

- reply

#nevent1q…g2ms

2025-05-20 14:27:05 GMT

- reply

We are requesting the complete removal of version 1.20.3—not just from search results—because the error “installed version is higher, cannot downgrade” appears to be caused by the coexistence of two versions of Keychat (1.20.3 and the latest 1.32.4+6380). When users upgrade from version 1.31.13+6370, Zapstore compares it with 1.20.3 and triggers the error. However, upgrading from 1.20.2 does not cause this issue.

2025-05-20 10:09:52 GMT

- reply

Is it NIP4 or NIP17 DM?

2025-05-20 07:27:46 GMT

Testing @npub16sg…gy58
https://video.nostr.build/fb031400dc0ab9f14fee3dc302c22f1f4cf6a9dedf480e0f50cc6b17aaa143bd.mp4

2025-05-20 03:23:01 GMT

When we came up with the idea of using sats postage stamps for Keychat messages, we assumed someone must have explored a similar concept for email. After some digging, we found these blog posts on ecash postage from over twenty years ago. If you're interested, it's well worth a read. https://www.erisian.com.au/wordpress/category/ecash
#nevent1q…yvf2

2025-05-20 03:05:31 GMT

@npub10r8…t2p8 Could you please remove the second upload in the screenshot as soon as possible? Thank you!
https://image.nostr.build/77974441cee97b8a5d8dae256148d8fa70156ce51419e7f225fd752003be60ec.jpg

2025-05-19 01:39:14 GMT

- reply

👍 Our focus is on enabling Mini Apps (web apps + Nostr login + Lightning payment) for users. The browser is merely the container.

2025-05-18 13:43:33 GMT

- reply

The comparison of relays to printing presses is made specifically in contrast to magazine editors. Relay operators are usually developers, and their role is vastly different from that of content editors—they are entirely different professions.

2025-05-18 13:20:25 GMT

A relay is a printing press, not a magazine editor.
#nevent1q…t04p

2025-05-18 13:16:57 GMT

- reply

A relay is a printing press, not a magazine editor.

2025-05-17 09:32:45 GMT

- reply

Keychat’s relay charges a 1 sat stamp for each message, while many Nostr relays are free to use.
https://image.nostr.build/29ff6cc700ceae88128a82ccb441ea394785c725e6d9b8582b8dfc0adfb4e61b.jpg

2025-05-16 15:19:46 GMT

When a Cashu mint starts charging fees, it’s not just the sender who pays — the receiver is also required to pay a mint fee in most transactions. This is likely to cause confusion among users.🤔
https://image.nostr.build/fc2d8979f8edf0e537a61f511e73d751ba3fca9ddeb0ce6f08d8c0dcdd956b8d.jpg

2025-05-16 03:21:11 GMT

- reply

Nosskey is likely a better solution than NIP-46.

2025-05-14 13:30:49 GMT

Testing YakBak.
https://video.nostr.build/71224f19105ee674827d45b7b72d1d5d7dada1cdce7689c0979f35e3e9f5da88.mp4
#nevent1q…4gsd

2025-05-11 11:14:27 GMT

https://image.nostr.build/8196d6880aa549b320412d098da8d92f30fc287b8a1153bd789c6b58855167c2.jpg
#nevent1q…gvs5

2025-05-11 10:20:41 GMT

- reply

https://image.nostr.build/e7bbc230d441fae3dd6186a1769c8b3e51635043662776d2bf072b4253ff5aab.jpg

2025-05-11 09:41:16 GMT

- reply

Sorry. Does the transaction also show as completed on the Minibits wallet transaction history page?

2025-05-11 08:18:53 GMT

Keychat attaches a 1 sat stamp to every message. But it doesn’t contact the Ecash mint server for each one. Instead, it fetches a batch of 1-sat ecash tokens in advance and uses them as needed to stamp messages.

2025-05-11 05:35:05 GMT

- reply

I figured out what went wrong. If you double-click the receive button too quickly, you’ll get a “token spent” error. The first click already successfully received the tokens, and the second click tries to receive them again.
We’ll tweak it to avoid this issue.

2025-05-11 05:13:48 GMT

- reply

The “Send Adaptor Signature” button appears unresponsive.

2025-05-10 15:21:05 GMT

Here’s ChatGPT o3’s take on the history of using public keys as user IDs.
Since the invention of public-key cryptography in the 1970s, several consumer-facing applications have used the user’s public key directly as their ID:
• PGP / GPG (1991) – Users share a short PGP fingerprint (a hash of their public key) as their email identity.
• Bitcoin addresses (2009) – A Base58-encoded hash of a public key acts as the account for sending/receiving funds.
• Bitmessage (2012) – The “BM-…” address is a Base58 public-key hash used for encrypted mail and broadcasts.
• Tox ID (2013) – The long Tox string embeds the full public key; add it to start an E2E-encrypted chat.
• Tor .onion v3 / Ricochet IM (2014) – A 56-character .onion address is derived from an Ed25519 public key and serves as the chat ID.
• Secure Scuttlebutt (2014) – Feed IDs look like @<base64-public-key>.ed25519; the key is the permanent identity.
• Ethereum-style addresses (2015) – 0x… hashes of public keys function as login/payment accounts across smart-contract chains.
• Nostr npub (2021) – An npub is a Bech32-encoded 32-byte public key; any client can verify signatures from it.

2025-05-10 08:07:02 GMT

Keychat + Kinostr
https://video.nostr.build/a5200d669f62abdf13ec990e62fb15c905a691552dc9075745657e996875eff2.mp4

2025-05-09 15:08:07 GMT

How Keychat thinks about group
The essence of a group is to establish a boundary where only members can participate in communication. In a decentralized system, this boundary can only be enforced through encryption.
Groups generally fall into two categories: **chat groups** and **feed groups**. The former focuses on interaction—members are visible to each other, and messages are shared with the entire group. The latter is centered around content sharing—members are invisible to one another, and messages are individually encrypted for each recipient rather than broadcast to all.
Compared to chat groups, feed groups create much less social pressure, allowing both the sharer and the recipients to interact in a more relaxed and private environment.
#nevent1q…tldp

2025-05-09 14:01:40 GMT

- reply

#nevent1q…tqph

2025-05-09 12:00:59 GMT

- reply

I was able to reproduce the bug using both an iPhone and an Android phone. The Keychat IDs on both devices were already connected as chat friends. The Android phone displayed a QR code, which the iPhone scanned to add the friend. On the iPhone, a screen appeared with a button labeled “Resent signal session.” After tapping it, the original chat room showed the error message “signal session is null.” We're currently working on a fix for this issue. Did you experience the same problem?

2025-05-09 03:14:37 GMT

At the core, it’s the same encrypted note — but the way it’s presented makes all the difference.
Form shapes essence.
The user knows the note will show up in their friends’ feeds, not in a chat room. That makes it feel more relaxed — it’s a message shared with many, not a direct conversation.
And for the friends who see it, there’s no expectation to reply, unlike with a DM.
#nevent1q…tyf2

2025-05-09 02:49:39 GMT

Maybe we could use NIP-17, which is used to encrypt DMs, to encrypt feed notes as well.
Suppose you have 10 friends — when you post a note, it’s essentially like sending 10 identical DMs.
However, the note still appears in the feed. Only your friends can decrypt and read it; others can’t see the content.
#nevent1q…gq76

2025-05-09 02:05:36 GMT

- reply

When you post a note and only want certain friends to see it, you encrypt the note using their public keys. In essence, you’re sending the same note individually to each of them.

2025-05-08 05:07:43 GMT

- reply

Yes.

2025-05-08 05:04:13 GMT

- reply

Using a seed phrase means using new IDs — just like how a Bitcoin wallet seed phrase works.

2025-05-08 04:57:41 GMT

- reply

It might be worth trying Keychat’s 12-word seed phrase — it allows you to derive multiple IDs with ease.🤔
#nevent1q…lhnu

2025-05-07 10:21:49 GMT

- reply

https://app.flotilla.social/spaces/groups.0xchat.com/2gVadOYXRyzc2ne6

2025-05-07 10:20:00 GMT

The Keychat customer discussion group is a NIP-29 Relay-based Group.
We use Chachi by @npub107j…ncxg , a NIP-29 web client, to join the group in the Keychat browser. A new NIP-29 web client, Flotilla by @npub1jlr…ynqn , has also been released — you can try it out directly in the Keychat browser by clicking its link.
The Keychat customer discussion group runs on the 0xChat relay by @npub10td…x2wl . That’s Nostr’s collaborative magic at work.
Welcome to join:
https://chachi.chat/groups.0xchat.com/2gVadOYXRyzc2ne6
https://video.nostr.build/f07199f8c1244e824e50795acb4edab1155833b8a40ccba16c100c8efb9c9a85.mp4

2025-05-06 14:02:34 GMT

- reply

Yeah

2025-05-06 13:55:09 GMT

Not many may have noticed, but Keychat recorded sats revenue on its very first day. While the earnings were minimal, they represented the launch of a meaningful and sustainable profit model.
#nevent1q…e2df

2025-05-06 13:11:43 GMT

Maybe it’s more appropriate to call Keychat users “Keychat customers.” Those who pay are the real customers.
In most “free” apps, it’s the advertisers — not the users — who are the customers, while the users themselves are the product.

2025-05-06 10:52:09 GMT

- reply

Thank you.
Keychat browser doesn’t include a built-in Nostr client. Instead, it combines IDs and Wallets with WebView (the OS’s native browser engine) to serve as a better host for various Nostr web clients. We still need more of these clients.
Beyond that, Mini Apps with Nostr ID login and Lightning payments unlock a much wider range of possibilities than basic Nostr clients.

2025-05-06 01:43:30 GMT

- reply

#nevent1q…54as

2025-05-06 01:41:57 GMT

In Keychat, services can be offered in two ways: through chat bots or Mini Apps.
Both are open for anyone to provide.
Chat bots are ideal for simpler, single-purpose tasks — like AI bots. Mini Apps, on the other hand, are designed for more versatile and feature-rich services.
Users pay sats to chat bots and Mini Apps through their Keychat Wallet. The operators of these services receive the sats directly.

2025-05-05 23:51:26 GMT

- reply

Yes. The sats go to the bot operator. Anyone can run a bot.

2025-05-05 13:44:44 GMT

For a browser app, it only takes you — it’s a tool you can use alone.
Maybe that’s why browser apps come in even more varieties than chat apps.
#nevent1q…fmam

2025-05-05 09:15:48 GMT

https://following.space/ by @npub12rv…85vg is a Mini App for Keychat. You can log into it seamlessly through the Keychat browser like this 👇
https://video.nostr.build/73eb9d935541726a70ffd6216ef142a09811f74c182c4adbc7b5f1b1fe30aae7.mp4

2025-05-04 13:23:27 GMT

- reply

#nevent1q…9p4z

2025-05-04 08:49:39 GMT

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.

2025-05-04 08:25:24 GMT

- reply

Keychat group chats use end-to-end encryption, so new members need invites — joining via a link isn’t possible. If you prefer an open group chat, try Chachi in the Keychat browser.

2025-05-04 08:19:56 GMT

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.
#nevent1q…sypc

2025-05-03 14:37:11 GMT

- reply

You can give Keychat a try first and see how it feels.

2025-05-03 14:32:04 GMT

- reply

note1w2vtwrfzm77kf6vgrznfzuu0x0kc5040mwmqunw69lfwrqf5m20syqgjfj

2025-05-03 14:28:51 GMT

- reply

note1lscq8kz2huwnzngtdfqs22r7wlrasjy7uavcq22gjzxu8zawknqsvjy29d

2025-05-03 02:17:26 GMT

- reply

This is a very solid proposal. We ought to implement it.

2025-05-02 13:20:15 GMT

- reply

Sorry, this feature isn’t working properly on Android. It works fine on iOS. We’ll fix it.

2025-05-02 13:06:56 GMT

- reply

Swiping right from the left edge of your phone takes you back to the same position in the feed. If you’d prefer to use the Android back button, we can support that in a future update.

2025-05-02 11:17:58 GMT

- reply

note1qu6hf92ju8esurtt40du6y3tye38jvstyp58tzs89m8mgjjgawpsq4pvdk

2025-05-02 11:07:07 GMT

- reply

cc@npub1syj…f6wl