<unnamed>

Public Key

npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8

Profile Code

nprofile1qqsth7fr42fyvpjl3rzqclvm7cwves8l8l8lqedgevhlfnamvgyg78sppamhxue69uhkummnw3ezumt0d5q3qamnwvaz7tmwdaehgu3wwa5kuegpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmnyqyxhwumn8ghj7mn0wvhxcmmvqyvhwumn8ghj7mn0daexummyv5hxummnw3erztnrdakshrenx5

Publishing to

Last Notes

2026-02-27 09:30:04 CET

- reply

https://nosotros.app/

2026-02-24 01:55:10 CET

Keychat’s Public Key ID and Bitcoin Wallet unlock four layers of value for agents:
1. In-app capability (Keychat-scoped) 
The ID and wallet exist solely to power Keychat’s built-in messaging experience.
2. Agent infrastructure (shared primitives) 
Exposed via RPC, they become agent-wide primitives: any channel, skill, cron job, or sub-agent can sign messages and send/receive sats. At this layer, the ID and wallet belong to the agent—not just to Keychat for Agent.
3. Agent network (A2A encryption + payments) 
When Keychat runs on every agent instance, agents can communicate end-to-end and settle payments directly with one another.
4. Unified human–agent network (same protocol, equal peers)
 Keychat for Agent and Keychat for Human share the same protocol, so humans and agents are true peers: encrypted communication and native payments in both directions.

2026-02-24 01:32:57 CET

When Mini Apps Meet Agents: From UI to Conversation
---
Keychat for Human has mini apps—web apps running in a webview that can directly use Keychat's public key identity for login and Lightning Network for payments. Users don't need to register accounts or link bank cards. Open and go. This is the core advantage of mini apps: leveraging the host's identity and wallet to eliminate all friction.
So does Keychat for Agent need its own version of mini apps?
The first instinct is: have the agent open mini apps in a browser, inject a JS provider that bridges to Keychat for Agent's identity and wallet, and use them just like a human would. Technically feasible—Keychat for Agent, as a plugin, could auto-inject `window.nostr` and `window.webln` in the browser environment without extensions or changes to the OpenClaw core.
But this is the wrong direction.
Mini apps are designed for humans. Their essence is three layers: identity, payments, and business logic. The UI is just a shell for human eyes. Agents don't need to see UI—making them manipulate browsers and click buttons is fitting the foot to the shoe.
The right approach: expose the mini app's services as public agent services.
Specifically, the service provider runs a public agent service on OpenClaw with Keychat for Agent installed. The user's agent talks to it directly:
- Login: Public keys are exchanged during the Signal Protocol handshake—identity is inherently verified, no additional login flow needed
- Payments: Send a Lightning invoice in the chat, the agent pays it directly
- Business logic: Complete operations via message commands, which the service parses and responds to
What humans accomplish through a mini app's GUI, an agent accomplishes in a conversation. Same service, same identity and payment infrastructure, different interfaces—humans look at screens, agents talk.
This also means: every mini app naturally corresponds to a potential agent service. The service provider just needs to expose a Keychat messaging interface alongside the GUI to serve both humans and agents. Not two systems—two entry points to the same system.

2026-02-23 16:26:31 CET

For early birds: https://github.com/keychat-io/keychat-openclaw

2026-02-22 10:36:39 CET

- reply

Hi, do you mean importing your public Nostr ID into Keychat and then receiving a lot of spam DMs?
Has your private ID also received any spam?
We’re still not sure whether we’ll adopt a Web of Trust approach, as we don’t fully understand this solution yet.

2026-02-20 04:35:35 CET

A public key is the agent’s native ID. Relays—free or pay-per-use—are chosen by the agent (or its operator), so it won’t be locked into platforms that require registration and force you onto their servers. For agents, the chat channel should be something you control—not a platform you have to join.
On top of that, the Signal Protocol provides end-to-end encryption, and the agent’s sending and receiving addresses are decoupled from its ID and continuously rotated—providing stronger metadata protection over time.
This is Keychat for Agent.
#nevent1q…qy9a

2026-02-19 14:51:39 CET

- reply

nevent1qvzqqqqqqypzpwleyw4fy3sxt7yvgrran0mpenxqlululur94r9jlax0hd3q3rc7qyxhwumn8ghj7mn0wvhxcmmvqyg8wumn8ghj7mn0wd68ytnhd9hx2qg5waehxw309aex2mrp0yhxgctdw4eju6t0qyt8wumn8ghj7un9d3shjtnswf5k6ctv9ehx2aqqyz83aat86nmvh3j0l7ff7kkv0yd5djhx7g8jylzpqyzqaccfjnxfxn7jjwc

2026-02-19 14:44:15 CET

Imagine you’ve installed OpenClaw on your own server or computer and are running a paid, public-facing agent service (not a private personal assistant).
After adding Keychat for Agent, the agent gains a sovereign ID, a Bitcoin wallet, secure chat, and access to an open relay network—earning Bitcoin by providing services, fully under your control.
https://i.nostr.build/IyKynzLfwTYJRccb.png
#nevent1q…gv39

2026-02-19 14:11:06 CET

We’re hosting an experimental public agent, Keychat Guide, on our OpenClaw. Since Keychat for Agent is already running there, you can click the link below to chat with it in Keychat. 👇
https://www.keychat.io/u/?k=npub19g94yreawwnv4sacqawdeq7exsfjthv8g36kkltrkdmdgdmmqy9qst3wt3
https://i.nostr.build/88aym1HYxDKcVQXz.jpg
We’re still polishing Keychat for Agent. Once it’s released, you’ll be able to run it on your own OpenClaw and chat with your own agents in Keychat.
Keychat for Agent is the Keychat protocol client for AI agents—giving each agent a sovereign public-key identity, just like Keychat for Human does for people.
#nevent1q…4670

2026-02-19 02:10:02 CET

We’re hosting an experimental public agent, Keychat Guide, on our OpenClaw. Since Keychat for Agent is already running there, you can click the link below to chat with it in Keychat. 👇
https://www.keychat.io/u/k=npub19g94yreawwnv4sacqawdeq7exsfjthv8g36kkltrkdmdgdmmqy9qst3wt3
https://i.nostr.build/lX2xP4EWLcRxDz0w.jpg
We’re still polishing Keychat for Agent. Once it’s released, you’ll be able to run it on your own OpenClaw and chat with your own agents in Keychat.
Keychat for Agent is the Keychat protocol client for AI agents—giving each agent a sovereign public-key identity, just like Keychat for Human does for people.
#nevent1q…pa22

2026-02-17 04:27:27 CET

- reply

👍Keychat will add Sunami to the Mini App list in the next version.

2026-02-14 11:19:07 CET

Our team is already chatting with OpenClaw agents on Keychat.
We’re refining the experience ahead of a public release.
https://i.nostr.build/J3ZGo46kp1nt7PkC.jpg  
#nevent1q…pwak

2026-02-14 03:56:15 CET

Once you understand the overall design of Keychat, everything will fall into place.👇
https://i.nostr.build/usznTtWoKiBu1t6u.jpg
#nevent1q…n0x6

2026-02-12 03:04:34 CET

When choosing a chat app as OpenClaw’s channel, it’s easy to feel stuck: WhatsApp, Signal, Telegram, Discord—everything works, but everything feels like a compromise.
WhatsApp and Signal typically rely on multi-device sync: OpenClaw is treated as another linked device under your existing account. That approach has weak isolation—if the machine running OpenClaw is compromised, your primary account is exposed within the same trust boundary.
Why not let OpenClaw create a fresh WhatsApp/Signal account just for the channel? Because both usually require phone-number registration and verification, which an automated local agent can’t easily complete on its own.
Telegram and Discord takes a different route. You create a bot first, get a bot token, and give that token to OpenClaw. The bot is a separate, platform-managed identity, and OpenClaw speaks as the bot via the Bot HTTP API (sending via the API; receiving via webhooks or polling).
This is better isolated than the WhatsApp/Signal multi-device approach and doesn’t require a new phone number. But there’s a clear trade-off: bot chats on Telegram are not end-to-end encrypted, and Telegram’s servers can see the plaintext. (Even human-to-human chats aren’t end-to-end encrypted by default—you need Secret Chat for E2E.)

2026-02-09 11:02:54 CET

- reply

#nevent1q…yqyf

2026-02-09 09:54:24 CET

- reply

#nevent1q…rtt8

2026-02-06 13:17:45 CET

- reply

Sorry—I misunderstood your question earlier and thought you were having trouble accessing the Keychat website.
Were you adding an NWC Lightning wallet or an ecash wallet on the Keychat wallet page?
If you added an NWC Lightning wallet, it can’t be automatically used for stamps yet (sorry—our wording wasn’t accurate). If you added an ecash wallet, it should be used as the stamp source automatically. You can try restarting Keychat.
Looking forward to your further feedback.

2026-02-06 13:09:56 CET

- reply

👇
#nevent1q…3v9u

2026-02-06 02:10:18 CET

Chat in Keychat takes letters as its prototype, providing a clear and natural direction for its design.
https://i.nostr.build/ugUDWcOdQlTqNo3V.png

2026-02-06 01:45:38 CET

- reply

https://www.keychat.io/
We encourage you to try it yourself.

2026-02-06 01:42:26 CET

- reply

Please try again.

2026-02-06 01:18:43 CET

Keychat messages sent to paid relays automatically carry an ecash sat stamp when your wallet has funds.
https://i.nostr.build/wWmV40Kqiey2X9Hw.jpg

2026-02-05 13:05:41 CET

We’ve just updated Keychat’s website.
https://keychat.io
https://i.nostr.build/muiYHSO8Y7jf8bZ9.png

2026-02-05 11:28:38 CET

Keychat is driven by a clear and focused mission.
https://i.nostr.build/2SXGPQ80eHwCJhKH.jpg

2026-02-05 03:27:42 CET

- reply

Feedback received. Thanks.

2026-02-03 11:23:50 CET

- reply

If all MLS group members keep the previous root key, then when a member who has not updated to the new root key continues to encrypt messages using keys derived from the old root key, members who have updated to the new root key can determine that someone has forked off from the group and can privately notify that person.
Of course, this approach can only detect members who send messages; it cannot detect members who only read messages without sending any. In addition, it sacrifices some degree of forward secrecy. This is just our temporary idea, and we have not yet developed a concrete solution for this problem.

2026-02-03 10:37:08 CET

- reply

Potential group forks may occur during operations that update the key tree, such as adding or removing group members.

2026-02-03 10:34:27 CET

- reply

You can first download Keychat from GitHub. We need to check F-Droid’s requirements and how to submit Keychat to F-Droid.

2026-02-03 03:07:58 CET

- reply

BTW Keychat Wallet now supports NWC.
Just like your wallet can hold different bank cards, Keychat Wallet is used to hold different Bitcoin Cards.
Previously, these Bitcoin Cards were Bitcoin Ecash Cards. Now, Bitcoin Cards also include Bitcoin Lightning Cards.
https://i.nostr.build/DqLHnGx7ZVSj7WY9.jpg
https://i.nostr.build/cToSn2mFUcZXm3o9.jpg
https://i.nostr.build/FPucyJfkynRElm1E.png

2026-02-02 02:11:22 CET

- reply

Keychat’s one-to-one messages and small-group messages are encrypted using the Signal protocol, while large-group messages are encrypted using the MLS protocol. Marmot (WhiteNoise), on the other hand, encrypts all messages—both one-to-one and group messages—using MLS.
It’s worth emphasizing that for one-to-one messaging, the Signal protocol is more efficient (and therefore more secure), because the new public key needed to advance the DH ratchet (which provides post-compromise security) is carried in the header of normal messages, without requiring extra messages to transmit a new public key. In Keychat, as long as the two parties exchange messages back and forth, the DH ratchet advances automatically.
By contrast, if MLS is used to encrypt one-to-one chats, advancing the ratchet responsible for post-compromise security is less efficient and requires separate messages to transmit new keys. This is largely because MLS was designed with large-group messaging as its primary use case.
MLS is built for large groups; one-to-one support is a byproduct rather than an optimization target.

2026-02-01 06:47:26 CET

- reply

A two-hop relay mechanism—where a message is first sent to a first relay, which then forwards it to a second relay that the recipient receives from—is a good approach for protecting IP addresses.

2026-02-01 06:38:11 CET

- reply

https://i.nostr.build/AVzT6QXUdAcxmR4D.png

2026-01-31 11:11:48 CET

- reply

Web App + Nostr login + Lightning payment = Keychat Mini App.
When you open a Mini App in Keychat and choose Extension login, Keychat will pop up a list of IDs for you to select which one to use to log in.
When you pay a Lightning invoice inside the Mini App, Keychat will automatically invoke the Keychat wallet to complete the payment.
In addition, you can add your favorite Mini Apps to Favorites, so next time you can open them directly from the browser home page.

2026-01-30 02:24:49 CET

- reply

Of course.
You can enter a URL or search keywords in the Keychat browser to open any website. Then tap the on-screen “virtual Home button” and choose **Add to Favorites**. After that, you’ll see this Mini App on the browser homepage, and next time you can just tap it to open and use it.
https://i.nostr.build/8PpUyJvvNiOoeW8l.jpg

2026-01-28 15:04:55 CET

- reply

Messaging Layer Security (MLS) is a security layer for encrypting messages in groups of size two to many. It is being built by the MLS working group and designed to be efficient, practical and secure.
https://messaginglayersecurity.rocks

2026-01-28 03:09:18 CET

Old Nostr DM (NIP-4) integrates four capabilities into a single Nostr key—it serves as an ID, an encryption key, a receiving address, and a sending address.
The encryption key in NIP-4 does not change, so NIP-4 messages lack both forward secrecy and backward secrecy.
Consequently, if the private key is compromised, both historical and future messages can be exposed.
The receiving and sending addresses remain constant, which poses a severe issue for metadata privacy in NIP-4 messages;
Everyone can see who (ID) is sending messages to whom (ID).
Currently, most Nostr apps use NIP-4 for DM functionalities, such as Damus and Primal.
——————————————————————————————————————
New Nostr DM (NIP-17) integrates three capabilities into a single Nostr key—it serves as an ID, an encryption key, and a receiving address.
Kind-17 separates the sending address from the ID, making the sending address random and concealing the sender's real ID, thus improving metadata privacy.
The encryption key in NIP-17 does not change, so NIP-17 messages also lack forward secrecy and backward secrecy. Once the private key is leaked, both historical and future messages will be compromised.
The receiving address remains constant, so there is still a slight issue with metadata privacy in NIP-17 messages; everyone can see who (ID) is receiving messages.
Apps like 0xchat and Amethyst use NIP-17 to implement DM functionalities.
——————————————————————————————————————
In Keychat, the ID, encryption key, receiving address, and sending address are separated.
The encryption key, the receiving address, and the sending address are updated independently and continuously.
Keychat's encryption key is derived using the Signal protocol, and each message uses a unique encryption key, which is deleted after use.
Thus, Keychat messages have both forward secrecy and backward secrecy. Even if an encryption key is compromised, only the current message can be leaked, and historical and future messages remain secure.
Keychat's sending address is randomly generated for each message.
Therefore, external parties do not know the sender's ID.
Keychat's receiving address is derived using the Signal protocol, with almost every message using a unique receiving address.
Thus, external parties do not know the receiver's ID.
——————————————————————————————————————
However, it's important to emphasize that NIP-4 and NIP-17 offer superior multi-device synchronization capabilities because they integrate three capabilities into a single Nostr key—it serves as an ID, an encryption key, and a receiving address.

2026-01-28 01:32:30 CET

- reply

@npub1rxy…hnp8 You might be interested in Keychat — here’s a brief introduction.👇
#nevent1q…8fct

2026-01-27 14:18:19 CET

Keys are the native ID for bots. Bot-to-bot chat is key-to-key chat.
Keychat.
#nevent1q…8rj9

2026-01-27 12:11:53 CET

- reply

The solution you mentioned is not suitable for a chat app, that is, for long-term conversations between friends. If you think about automating and programmatically managing the ephemeral key update mechanism, you’ll end up with the Signal protocol.

2026-01-22 09:52:21 CET

- reply

Keychat has two main features: Chat and Browser (Mini Apps).
When your wallet has a balance, your chat messages will pay a sat “stamp” (postage) to the Keychat relay, and the relay will then forward the messages. Your messages can also be forwarded by free relays at the same time. You can add more message relays (free or stamp-paid) in Me → Chat Settings.
If you use Mini Apps in the Keychat Browser—such as Jumble or Nostros (both Nostr web clients)—you need to add paid relays in their own settings pages. For Mini Apps, Keychat acts only as a signer and does not manage a Mini App’s relay configuration.

2025-12-31 12:06:38 CET

The latest Android version of Keychat now supports message notifications via UnifiedPush.
If you’re using Keychat on GrapheneOS, feel free to upgrade.
https://github.com/keychat-io/keychat-app/releases
https://i.nostr.build/vm3bIMCKVorRclft.jpg
https://i.nostr.build/3Gtxft8sYHJE9tZ9.jpg

2025-12-15 11:10:42 CET

A super app isn’t an “everything app.” Watch Keychat’s intro video, and you’ll see exactly where it fits best—and why that framing makes sense.
#nevent1q…eck2

2025-12-14 03:48:50 CET

This proposal aims to introduce Signal Protocol into the Nostr network, which allows Nostr clients to have end-to-end encryption for private communications with forward secrecy and post-compromise security.
Specifically, the address-refreshing technique is used to minimize tracking and avoid social engineering.👇
https://github.com/keychat-io/keychat-app/blob/main/docs/Signal-Protocol-over-Nostr-NIP-DRAFT.md

2025-10-10 02:31:55 CEST

- reply

You can log in to Keychat using Amber. Then, use Flappy in the Keychat browser through extension login.

2025-10-10 02:15:14 CEST

- reply

Keychat is the super app for Bitcoiners.
Autonomous IDs, Bitcoin ecash wallet, secure chat, and rich Mini Apps — all in Keychat.
Autonomy. Security. Richness.
A Nostr web app can be used as a Mini App inside the Keychat browser.

2025-08-10 09:39:18 CEST

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

2025-07-09 11:51:25 CEST

- reply

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

2025-05-21 04:20:43 CEST

- reply

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

2025-01-16 19:22:44 CET

- reply

No.

2025-01-16 18:07:57 CET

- reply

WhatsApp uses the Sender Key group model, which supports more group members compared to the pair-wise group model previously used by Signal.
The new group chat protocol, MLS (Message Layer Security), can support even more group members than the Sender Key group model and offers better encryption security.
If you're interested in various encrypted group chat methods, you can check out the comparison note below.
#note1qu6…pvdk

2025-01-15 08:28:34 CET

Why doesn't Keychat directly support relay-based unencrypted groups in Chat?
Large-scale public groups without end-to-end encryption are a different type of application, similar to Discord or forums with a chat interface.
Keychat is designed for small-scale, end-to-end encrypted private groups, where most members are friends rather than strangers.
Therefore, Keychat will indirectly support relay-based groups instead of mixing them with encrypted groups, which would cause confusion. #note1y0q…xjw9

2024-12-12 10:44:24 CET

Nostr mainly uses temporal structure to organize information, whereas the Web employs both temporal and spatial structures.

2024-11-21 08:59:00 CET

- reply

The MLS protocol provides an efficient end-to-end encryption solution for large-scale group chats.