keychat
Keychat

https://www.keychat.io/

Keychat is a chat app, built on Bitcoin ecash, Nostr protocol and Signal protocol. Keychat is inspired by the postal system — stamps, post offices, letters. Keychat uses Bitcoin ecash as stamps and Nostr relays as post offices. Keychat uses Signal protocol to ensure message encryption security and meta-data privacy. https://www.keychat.io/ https://github.com/keychat-io

Public Key

npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8

Profile Code

nprofile1qqsth7fr42fyvpjl3rzqclvm7cwves8l8l8lqedgevhlfnamvgyg78spzpmhxue69uhkummnw3ezumrpdejqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcr9j8du

Publishing to

nostr.land

relay.damus.io

nos.lol

nostr.bitcoiner.social

relay.snort.social

nostr.wine

Author Public Key

npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8

Show more details

Last Notes

2025-04-03 04:13:00 GMT

ID+Wallet, Chat+Browser
#note13sx…nk7y

2025-03-31 13:56:40 GMT

Some updates:
We've finally sorted out the Apple developer account. We expect to release the iOS version of Keychat within a week or two, and possibly a macOS version as well (although the UI isn’t fully optimized for large screens yet).
We're currently revising our MLS group implementation. We've studied the codebases of NIP-104 and White Noise in depth and learned some useful design ideas—such as encrypting MLS messages using NIP-44 and hiding the `group_ID`. We’ve also been posting comments and discussing better mechanisms, like more efficient ways to update the MLS group’s receiving addresses. Ultimately, we hope different MLS clients will be able to interoperate.

2025-02-24 09:45:27 GMT

- reply

#note1qam…3zcm

2025-02-24 09:44:59 GMT

Keychat’s design approach: decouple and couple. 👇

2025-02-24 05:20:22 GMT

algo.utxo.one offers a relay service equipped with a recommendation algorithm.
Jumble provides a Nostr web client.
Keychat supplies a browser with built-in public key extension login and a Bitcoin Cashu ecash wallet. https://video.nostr.build/d0a044682051a3a7a4e3e1e3c3685f127d70027ef37185644e0181bee13981a5.mp4 #note1s6r…qq4y

2025-02-22 02:59:15 GMT

couple, couple, couple. #note13sx…nk7y

2025-02-22 02:57:52 GMT

decouple, decouple, decouple. #note1zkk…hcv2

2025-02-21 02:46:30 GMT

Offline Me needs self-controlled IDs and wallets to live in the physical world.
Online Me also first needs self-controlled IDs and wallets to live in the digital world.
Then Me can chat and browse.
In Chat, Me uses the IDs and pays for relays per message with the wallets.
In Browser, Me uses the IDs to log in to web apps and pays in Bitcoin with the wallets. https://image.nostr.build/000ac5733cdc66e38d0cd0948080d36020e3e16147cbfb77d0bea100d004bb06.jpg https://image.nostr.build/000e70d0a118e66e313d22b24d64ec44b226423dc78ccfaf5fa0fe5fac48a024.jpg

2025-02-20 11:36:56 GMT

- reply

The relay only needs to forward both stamped and unstamped messages. Think of the relay as a post office.

2025-02-18 10:14:36 GMT

Just as a person can live in a new country with only a passport and a wallet, a self-controlled ID and wallet together form the online "Me."
Then, Me can chat and browse.
In Chat, users use the ID and pay relays with the wallet on a per-use basis.
In Browser, users can log in to websites with the ID and use the wallet to pay BTC Lightning invoices. https://image.nostr.build/000ac5733cdc66e38d0cd0948080d36020e3e16147cbfb77d0bea100d004bb06.jpg https://image.nostr.build/000e70d0a118e66e313d22b24d64ec44b226423dc78ccfaf5fa0fe5fac48a024.jpg

2025-02-18 03:14:52 GMT

The new version of Keychat supports Amber (NIP-55) login.
https://github.com/keychat-io/keychat-app/releases
The latest version has also been uploaded to Zapstore. https://image.nostr.build/326c80978cbf4a29dfee39091be41cc8d5f89db19eb60cf59c07f92cb2dd72c3.jpg

2025-02-16 14:06:19 GMT

Nostr mainly uses temporal structure to organize information, whereas the Web employs both temporal and spatial structures.
Npub.pro endows Nostr with a spatial structure, allowing users to organize premium notes by category. https://video.nostr.build/10a9b3145c36347bf0ad79475c807b6a4905c8dbc9ddd5fd16cced30faba44f0.mp4

2025-02-11 12:34:11 GMT

- reply

Is Nostr-double-ratchet compatible with the libsignal of the Signal protocol?

2025-02-08 01:51:39 GMT

I chat, I browse, I own me. https://image.nostr.build/142fe2a4c6623c51bac9f0126685af437579a005b8531d2bf4b23eebe5bb9ab3.jpg

2025-02-07 10:36:18 GMT

Purchasing Mullvad VPN using the built-in Cashu wallet in Keychat is very easy. https://video.nostr.build/380d4be9d79bb86462bbb4c31409fdab56b86a243ef8ac63a9d318027fca5960.mp4

2025-02-06 15:26:47 GMT

Stablecoin is a bridge; humans cannot dwell on it. #note1eql…mxqq

2025-02-06 04:07:18 GMT

Keychat encounters issues when receiving tokens(cashuB) generated by other Cashu wallets. We are working on fixing this bug.

2025-02-05 11:15:51 GMT

@npub1ces…t37c Could an “open wallet” button be added to the Lightning Network invoice page?
This would let users pay directly using wallet, eliminating the need to copy and paste the invoice. https://video.nostr.build/f369afd0599ef8fd0395d3afff176fd592040512f2a2527ca7419d80be5d0d51.mp4

2025-02-05 01:20:10 GMT

This is the way Keychat users interact with Chachi.👇 https://video.nostr.build/482e1891e522e12b290fcfa0446290d55b940fe600946316c7971d55c3bb3545.mp4

2025-02-04 16:54:17 GMT

The wallet is more important than the ID, because it stores real money—sats—that is recognized even in the offline world. The ID may be purely online and unrelated to any offline identity. #note1vc7…5nkf

2025-02-04 16:42:46 GMT

- reply

Keychat distinguishes between the ID and the receiving/sending addresses. The ID remains unchanged, while the receiving and sending addresses are updated continuously. The ID does not appear on the envelope; only the addresses are displayed.

2025-02-04 16:19:17 GMT

- reply

Plz check this note.
#nevent1q…j20j

2025-02-04 16:02:07 GMT

- reply

We’re testing nip55 and aren’t 100% sure if it’s fully compatible with Keychat yet, but it should be fine.

2025-02-04 15:41:34 GMT

Any website or web app that supports nip7 extension login or Lightning Network invoice payments—whether it’s a Nostr web client or not—can enjoy an enhanced user experience in the Keychat Browser. #note1jc5…u6w4

2025-02-04 15:33:37 GMT

An ID can serve as both a Chat ID and a Browser ID, or it can be solely a Chat ID or solely a Browser ID. https://image.nostr.build/865b5b6b674e391e917506edb2c34d7fdcb8281fde3d959f89276aca13bc6451.jpg

2025-02-04 12:27:08 GMT

Once one’s online self is established, his two most common online activities thereafter are chatting and browsing (including using web apps).
Chat applications are the most popular in the smartphone era, while browsers defined the PC era. #note144u…r524

2025-02-04 10:00:15 GMT

Keychat’s Browser provides the best browser for all Nostr web clients.
They only need to support nip7 extension login and Lightning Network invoice payments. #note1c2l…2x3s

2025-02-04 09:53:10 GMT

User-controlled IDs and wallets are the cornerstones of Chat and Browser.
In Chat, users need an ID and use a wallet to pay relays on a per-use basis.
In Browser, users can log in to websites and web apps with their ID (for history and state), and use a wallet to pay Lightning Network invoices to purchase services. #note1vc7…5nkf

2025-02-04 08:43:45 GMT

The new version of Keychat has added a browser tab.
Users can log into the website using their ID and pay Lightning Network invoices with the built-in cashu wallet.
We will release the iOS version as soon as possible.
Android APK download:
https://github.com/keychat-io/keychat-app/releases/tag/1.26.5+6319 https://image.nostr.build/93db385f3b4c2466e5806627c4921cf4d6ff9bc18c3f1b0e884e7594cefbc282.jpg https://image.nostr.build/c093e843de8e9aaa180559cabfbcf40068f1513af4d35afbe415691aa0830c43.jpg https://image.nostr.build/b79993beedc13805f5138b5370af71db8faf76e94112ab7e93aadeed8ca697cd.jpg https://image.nostr.build/0479f9c366064e80a2dda4b8be7f3b340e3aee3214c8078dc71f3d8c95c0db91.jpg #note1vc7…5nkf

2025-01-26 14:18:14 GMT

User-controlled IDs and wallets together constitute one’s online self. #note1j9a…dt7d

2025-01-26 04:10:31 GMT

When a person arrives in a new country with only a passport and money, they can manage to live there. Dining at a restaurant requires money, not a passport. Staying at a hotel requires both money and a passport.
This serves as the starting point for how Keychat thinks about the online world: user-controlled IDs and wallets.

2025-01-20 04:13:13 GMT

In a chat application, do you prefer that others must request your approval before adding you as a friend or to a new group, or do you prefer that others can add you directly as a friend or to a new group?

2025-01-17 04:45:11 GMT

Providing encrypted image "storage" for Keychat's private messages is different from providing image storage for Damus's public notes.
Keychat's message images only need to be stored for a short time, such as one week. Once the recipient receives the image, the image server can delete it. The server simply acts as an image relay.
In contrast, Damus's note images need to be stored for a much longer time, possibly indefinitely, which is true image storage.
This difference is similar to the distinction between providing a relay for Keychat and a relay for Damus. ⬇️ #note1lke…cgnd

2025-01-16 18:31:05 GMT

- reply

The response provided by ChatGPT:
WhatsApp’s two founders, Jan Koum and Brian Acton, left the company after it was acquired by Facebook due to fundamental disagreements with Facebook’s corporate culture and strategic direction, particularly regarding privacy and monetization.
1. Conflict Over Privacy Principles
• WhatsApp’s Philosophy: From the start, WhatsApp prioritized user privacy, vowing not to include ads or excessively collect user data. Both founders were strong advocates of privacy protection.
• Facebook’s Business Model: Facebook relies on advertising revenue, which requires extensive data collection for targeted ads. After acquiring WhatsApp, Facebook gradually moved to integrate WhatsApp’s user data with its own, which the founders saw as a betrayal of their promises to users.
2. Disagreement on Monetization
• WhatsApp’s Revenue Model: Before the acquisition, WhatsApp charged users an annual subscription fee of $0.99.
• Facebook’s Ad-Driven Strategy: Facebook viewed advertising as the best path to large-scale monetization and explored inserting ads into WhatsApp or leveraging its data to enhance Facebook’s ad business. This directly conflicted with the founders’ “no ads” philosophy.
3. Cultural Differences
• The founders valued a simple, efficient, user-centric approach to product development. In contrast, Facebook’s culture was focused on rapid growth and monetization, creating a clash that made it difficult for the founders to adapt post-acquisition.
4. Escalating Internal Conflicts
• As Facebook tightened its control, the founders lost influence over key decisions, such as data-sharing policies, encryption, and the product’s future direction.
Timeline and Background of Their Departures
• Brian Acton: Left WhatsApp in 2017 and openly criticized Facebook, especially after the 2018 Cambridge Analytica data scandal. He later supported the “#DeleteFacebook” movement.
• Jan Koum: Resigned in 2018, reportedly following heated disagreements with Facebook’s management over data privacy and monetization strategies.
Conclusion
The core reason for their departure was the fundamental conflict between their commitment to user privacy and Facebook’s ad-driven business model. This conflict highlights the cultural and value-based clashes that can arise when a small, focused startup is acquired by a profit-driven tech giant.

2025-01-16 18:29:27 GMT

If you’re curious about why WhatsApp’s two founders left after being acquired by Facebook, you can ask AI.

2025-01-14 11:04:43 GMT

Chachi is a Nostr web client focused on Relay-based Groups.
https://chachi.chat/
https://github.com/nostr-protocol/nips/blob/master/29.md
This is why we love Nostr + Web.👇 #note1y0q…xjw9

2025-01-14 09:49:22 GMT

Will Keychat support relay-based unencrypted groups (NIP29)?
Keychat will not support it directly.
Keychat will support it indirectly.
Like this 👇 https://video.nostr.build/80ebe395440216bfdb23e80e063e8a56d585e038a83806087e57d211f066db7f.mp4

2025-01-13 16:44:16 GMT

- reply

#note1ucp…80r2

2025-01-09 04:07:37 GMT

Is SimpleX more secure because it has no ID?
Then why did SimpleX Chat previously only have 1-time invitation links, and now it has added the SimpleX contact address?
What exactly is the SimpleX contact address?
Does it count as an ID? Or does it not?
If Keychat named its features like SimpleX Chat, it would look like this?👇
https://simplex.chat/docs/guide/making-connections.html#comparison-of-1-time-invitation-links-and-simplex-contact-addresses https://image.nostr.build/6eef8335edf53a04eaab3b16ef91345b1bb2dc29b411e937cb7468113c28d3e4.jpg #note1ucp…80r2

2025-01-07 08:37:32 GMT

- reply

It’s hard to convince them to support Bitcoin payments (on-chain, LN); they have all sorts of reasons to oppose it. Yet, they agreed to integrate MobileCoin.

2025-01-07 08:31:13 GMT

- reply

Signal probably doesn’t want to integrate Bitcoin payments, rather than not knowing how to.

2025-01-07 08:16:27 GMT

- reply

The Signal app has integrated MobileCoin, a shitcoin.
Cashu sat is Bitcoin ecash sat. https://image.nostr.build/93fe8940c163308257b91757d9855925e1c6098fea02d6d2440ffdb5c8d211ac.jpg

2024-12-31 00:43:35 GMT

- reply

We will, once the stable version is ready.

2024-12-05 04:19:14 GMT

We feel that the web and browsers will enter a renaissance.

2024-11-28 12:13:16 GMT

The latest version of Keychat uses OpenMLS to implement large group chat.
Please note that MLS large group chat is still in its early testing phase, and we will continue to develop and refine it. OpenMLS is also in its early stages.
If you're interested in learning about the MLS protocol, the note below might be helpful.
https://github.com/keychat-io/keychat-app/releases #note1h9f…gejs

2024-11-21 06:09:18 GMT

Over the past few weeks, we have been learning and testing the MLS protocol and have gained a deeper understanding of it. Below is a note providing a general description of the MLS protocol.
The MLS group members (A, B, C, D, E, F, G, H) form the leaf nodes of a binary tree as shown below. Each member has a pair of public and private keys.
For member A, they use their private key and member B’s public key to perform an ECDH computation. For member B, they use their private key and member A’s public key to perform an ECDH computation.
Both compute the same value. This value becomes the private key of Node3, and from this, the public key of Node3 can also be derived.
Similarly, other members perform their respective ECDH computations.
Moreover, nodes higher in the tree also perform their respective ECDH computations up to the Root. Node3 and Node4 compute the private key of Node1 through ECDH, while Node5 and Node6 compute the private key of Node2. Node1 and Node2 compute the private key of the Root through ECDH.
The private key of the Root is the shared key among the MLS group members. Each member uses this shared key along with their respective related keys to derive their message encryption key.
The most important feature of this key tree is that child nodes know the private keys of their parent nodes.
—————————————————
If member A suspects their key has been compromised, they need to update their key.
Member A generates a new key pair (public key and private key) locally and recalculates the keys for Node3’, Node1’, and Root’.
Then, A encrypts the public keys of Node3’ and Node1’ using the old public keys of Node3 and Node1, respectively, and sends them to all group members.
When member H receives and decrypts the message, they obtain the public key of Node1’ and, combined with the private key of Node2, perform an ECDH computation to calculate the new private key of Root’.
Other members perform similar operations. As a result, all members successfully update the key tree.
The advantage of the MLS protocol is that when a member updates their key, the complexity of updating the key tree is reduced to O(logN).
Imagine if there were no binary tree. When A updates their key, they would need to update the message one-to-one for each group member, resulting in a complexity of O(N).
However, if member B’s key is compromised, member A updating their key cannot rescue member B. Each member’s update key operation can only protect themselves, not all members. https://image.nostr.build/10752c810a9aef73885173ecb7b76f9e65ce322c2c2edefdda7a82dd4b58d7a4.jpg https://image.nostr.build/80864aad3cb9a3e8ecd91cd0de77c10cd5ba9d54dbe182c9631825ab0482069b.jpg #note1guz…mq8y

2024-11-06 12:46:05 GMT

The Nostr protocol utilizes the secp256k1 algorithm, while the Signal protocol employs the Curve25519 algorithm.
Given this scenario where two protocols use different algorithms, how does Keychat manage this? Is there a need to standardize on one algorithm?
There is no need.
Keychat employs Npub as the ID, similar to how a phone number is used in the Signal app.
This setup allows Keychat to effectively abstract the entire Signal protocol as a message encryption protocol.
Keychat relies directly on the Signal protocol for encrypting messages. #note16gv…583q

2024-11-06 10:22:03 GMT

Pubky is very aware that it is web. 👍 #note1efj…aud4

2024-10-26 12:46:34 GMT

- reply

Could you add me on Keychat?
H4sIAAAAAAAAExWSuQ1dQQzEenH8At1HHa5AWkkVuH8YP2dADubP3/r35/vOXRKpRDt3snVxOkAJeyzKubbTE2FEwneeJkSLliCuxPtAL2ZH3PDO5DyGfLP3Dd95ye0IoVvdK/CWkMpVeMPAokfwibmheyPf1uZMYttdF6rqqlUrIGkrZh80u4v9iIwRrJuPjUPQUfADFeMXTDbw2BLXdLlHiqbkiXPWGNxC38tBy1CLEaI40lrJbzZ8nFMmUIFgwK6i2ToYjX3TF2UfeklYS/vTFZHlhrsSt0e9Hkf7yOiiADnKCehqAx4piQR1UNb5mdfDg2hmfRbykaKYppB+oArNWx5b4gpRm4VJWg4BAJO0WmPVMzS37zfYYgvpIt2T+9AZgBkijPT7dTJZz+BrU7bYHJOGn7JfwLqv9uWlyYv+vUDVwj3mgMXiIVyCuq9jncs2zRJ6vUF8fj/zCNtx5EdiZkNX/eaNa/4HhG4nH3cCAAA=

2024-10-13 01:10:09 GMT

- reply

Thank you for the feedback.

2024-10-12 01:35:07 GMT

- reply

Matti means that as long as two friends are willing to use a particular chat app, they can start using it. This is not possible for microblogging platforms.

2024-10-11 03:59:02 GMT

- reply

Signal and Telegram both use the open-source solution WebRTC for voice and video calls.

2024-10-03 07:10:49 GMT

👍
PPE relay uses a prepaid, pay-per-use model.
Wouldn’t using the ecash sat stamp mode be simpler and more straightforward? #note1c4q…fclk

2024-10-02 00:06:38 GMT

- reply

👍
Your idea is the symmetric ratchet in the Signal protocol's double ratchet algorithm.

2024-09-29 02:25:17 GMT

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.

2024-09-26 02:51:17 GMT

Imagine a relay with countless mailboxes, each with a unique number. For parties already engaged in double ratchet algorithm chat, only they know the value of the latest DH ratchet. This value can be used to derive a receiving address (mailbox number) that only they know. The chatting parties simply need to go to this mailbox to retrieve messages.
Since only the chatting parties know the latest mailbox number, even if the sending address is random, as long as the mailbox number is correct, they can confirm that it comes from their chat partner.
Therefore, the mechanism for determining the receiving address is most important, while the sending address can be randomly generated. #note10mm…xxjm

2024-09-25 13:15:30 GMT

https://image.nostr.build/b498ce30f2a7147603a5e8f13bc4c7c3765ba98028db4dd2eb9fdfb97c8539ba.jpg #note1r97…nu0v

2024-09-25 12:11:04 GMT

To better understand Nostr, first better understand the Web. #note1p8r…6yhu

2024-09-25 11:04:15 GMT

- reply

If I understand correctly, its lack of an ID mechanism makes it more reliant on relays.

2024-09-25 10:16:12 GMT

Is the term 'gift-wrapped DM' clear to most people?
We think ‘each message updates the sending address' is easier to understand.

2024-09-25 02:10:40 GMT

AI companies offer a subscription plan to regular users, where you pay a fixed amount regardless of usage, such as $20 per month.
However, they offer a pay-as-you-go system to developers, where you pay based on how much you use.
As a regular user, if you prefer the subscription model, please reply with 1. If you prefer pay-as-you-go, please reply with 2.
Thank you for participating in this survey.

2024-09-24 09:46:19 GMT

- reply

We're also unsure how long it will take to become stable enough for the app store, but it shouldn't be much longer.

2024-09-24 05:09:38 GMT

- reply

We also do not understand why so many people want to use their existing Npub instead of the better option, seed phrase.👇
#note174e…v9mj

2024-09-24 04:45:35 GMT

- reply

Hi, thanks. The new version of Keychat supports nsec login, so it can use an existing npub.
#note1q3q…2r46

2024-09-19 12:59:05 GMT

Nostr app developers, please do not fear the "ecash sat postage stamp"—be brave. #note1pdr…2vkr

2024-09-19 10:26:01 GMT

Ecash sat is a universal access token for relay servers.
“Initially, we thought of having relays issue one-time anonymous access tokens that users could purchase and use for anonymous pay-per-use. Later, we realized that using Bitcoin ecash as postage for messages would be a better solution.” #note1h89…gaaz

2024-09-18 14:05:33 GMT

Keychat's new version for Android APK download : https://github.com/keychat-io/keychat-app/releases
The new version introduces a medium group feature, replacing the previous shared key group.
It also includes nsec login, allowing for the simultaneous use of existing nsec and seed phrases.
(Keychat is currently not stable enough, so early testers can only download it through the Android APK. We are working on making it stable, and then we will add it to the iOS and Android app stores.) https://image.nostr.build/fdedc1c365d88a9b425d89d5fb153088db0541a29063f2533ce81c0fe115ef48.jpg https://image.nostr.build/56d35d45a866547ac202c966b16510256da4cbe244e2124a3f7dbad2bc2663db.jpg https://image.nostr.build/29f633a9c7ac1d96beb9e9f8fe32c56db139a87960639f41d32875d03c4bb0a1.jpg https://image.nostr.build/6b4db2a764ab83ef4228a934a38d8eb0add3a0f5f4c9f37a9d2b2dbdfaf9209f.jpg #note1ah6…yq8y

2024-09-18 00:47:05 GMT

- reply

The first function of stamps is anti-spam. Messaging apps like Signal or WhatsApp require registration, and the sender’s address for messages is the user’s ID. Therefore, the server administrators of these apps can block IDs to prevent spam.
In the registration model, users do not have control over their own IDs.
Keychat users, on the other hand, do not need to register, as their locally generated npub serves as their ID. Furthermore, each message is sent from a constantly generated, unique address, rather than using the ID as the sending address. As a result, Keychat cannot block spam by blocking IDs.
The second function of stamps is to provide nostr relays with a sustainable source of revenue. Signal has been running at a loss, as discussed in this blog post: https://signal.org/blog/signal-is-expensive/
Keychat’s use of ecash sats as message stamps is primarily inspired by the postal system. Moreover, using ecash sats as stamps does not affect the metadata privacy of messages.

2024-09-17 09:42:03 GMT

Let's explore the concept of a medium group from an interesting perspective.
Suppose a medium group consists of three regular members, A, B, and C, along with one special member, D. Why is D special? Because the identity of D is shared among A, B, and C. When A sends a group message, it is effectively sending a message to D, allowing us to reuse Keychat's one-on-one chat functionality. Members B and C use D's identity to receive and decrypt the message sent by A.
However, D does not respond to messages, meaning that the messaging in the Medium group utilizes only one of the ratchets in the double ratchet algorithm (the symmetric ratchet), and not the DH ratchet. Therefore, messages in the Medium group have forward secrecy similar to one-on-one messages but lack backward secrecy.
How can we achieve some degree of backward secrecy? By changing D, for instance to E, which effectively resets the DH ratchet. When the Medium group adds or removes members, the special member is updated, thereby gaining some degree of backward secrecy.
If there's a need for more efficient and frequent changes of the special member, then we turn to the MLS protocol. #note1kmd…ycrx

2024-09-02 08:45:48 GMT

- reply

https://image.nostr.build/0017c92c043e37aa1ec445b7b20b3874fd15711e15e3807e5a4f7c5e803ec46d.jpg https://image.nostr.build/c90e5fbafd5dd999ed33140f70aa734f13ebfe00a6e6a52744f256d3e96a82cf.jpg

2024-08-31 06:02:42 GMT

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.

2024-08-29 08:07:18 GMT

“The Signal protocol is used by two parties to exchange encrypted messages based on a shared secret key.”
“Messaging Layer Security (MLS) is a security layer for encrypting messages in groups ranging from two to many.”
So, it might seem logical to conclude that "the MLS protocol is a superset of the Signal protocol, and the Signal protocol is a subset of the MLS protocol. Whether it's one-on-one private chats, small group chats, or large group chats, the MLS protocol alone could be used to implement them."
However, this seemingly logical conclusion is incorrect.
The MLS protocol is not as efficient as the Signal protocol for implementing one-on-one chats and small group chats.
Assume a two-person MLS group chat and a one-on-one chat using the Signal protocol, both achieving the same level of security.
In the MLS group, each message sent requires an additional message to update the encryption key (with forward secrecy and backward secrecy capabilities).
In contrast, one-on-one chats using the Signal protocol do not require this additional message to update the encryption key (with forward secrecy and backward secrecy capabilities). #note13hk…4nax

2024-08-26 11:37:06 GMT

- reply

7/n
The MLS (Messaging Layer Security) group's central feature is its efficiency in updating both group members and the shared root key, reducing the number of necessary communications from N individual chats down to log2(N).
Consider the MLS group as an evolution of the upgraded sender key group, with a similar mechanism for deriving encryption keys from a root key at the top of a hierarchy.
Imagine a scenario where a group member, A, believes their key has been compromised and needs an update. This would trigger an update of the root key. But the challenge is how A informs the rest of the group about this change.
In an upgraded sender key group, A would have to individually communicate with every other member, resulting in N-1 private messages.
The MLS group, however, is structured around a key tree. The leaves of this tree represent the group members—A through H—with the root key at the very top. A distinctive feature of this structure is that each child node has access to its parent node’s private key.
For instance, A can update E, F, G, and H by sending a single message encrypted with the public key of node 1. Since these members are the children of node 1 and possess its private key, they can decrypt the message.
Similarly, A can inform C and D by encrypting a message with the public key of node 2, to which they, being children of node 2, have the private key and can thus decrypt.
A directly communicates the update to B with one personal message.
In total, A needs to send log2(8) = 3 messages to update the entire group.
If the group size were as large as 1024 members, A would only need to send log2(1024) = 10 messages.
This efficient mechanism of updating members and the root key grants the MLS group the backward secrecy feature, an enhancement over capabilities found in the upgraded sender key group.
We are studying the MLS protocol and will implement the MLS group feature in Keychat later. https://image.nostr.build/da70b8c9dea1a8954e6bca4e9d8f60b74df87555e1944810e73c61c620b28494.jpg

2024-08-26 11:34:57 GMT

- reply

6/n
Keychat is on the verge of launching an updated model known as the upgraded sender key group, expected to be released this week and will be termed "medium group" in the new version.
Unlike the sender key group, where each member communicates their initial key, k0, to all other members, the upgraded sender key group has members sharing a common group key, k, akin to the mechanism used in the shared key group. Each member derives their personal k0 using a Diffie-Hellman calculation with their ID and the shared group key. They then encrypt their first message with k1 = kdf(k0), and subsequent messages with sequentially derived keys, like k2 = kdf(k1).
Other members decrypt incoming messages by sequentially deriving keys from the sender's k0. After use, these encryption keys are discarded. Thus, the upgraded sender key group maintains forward secrecy, meeting the third requirement, but does not offer backward secrecy, failing to meet the fourth requirement.
Efficiently updating the group key, k, would enable the group to meet the fourth requirement concerning backward secrecy.
If a member who has disclosed confidential chat information needs to be removed, a new group formation is necessary. The group admin must then individually share the new encryption key, k, with each member, where N represents the number of members.
This upgraded approach reduces the need for member updates from N*N individual chats in the sender key group to just N chats in the upgraded sender key group, significantly enhancing efficiency and maintaining forward secrecy.
Alternatively, this model could be described as an upgraded shared key group because, compared to the original shared key group, it offers forward secrecy and simplifies member updates to only N individual chats.
Yet, the requirement for N individual chats to update members remains a significant challenge for larger groups.

2024-08-26 11:28:02 GMT

1/n
Group chats with end-to-end encryption can be designed in many ways, each tailored for a specific number of participants and level of security.
If we regard the security of one-on-one chats in Keychat as perfect, scoring 100, and the security of large group chats without end-to-end encryption as nonexistent, scoring 0, we can map out where the five identified end-to-end encryption group chat models fall in terms of group size and security on a diagram as shown below: https://image.nostr.build/bf1fba2fd9576cb7f4f16c1d6b0722c51d6e8c628146330b0afd3eb42f6a545f.jpg

2024-08-26 10:10:11 GMT

The new version of Keychat, v1.16.3, is now available for download.
Keychat users can use more ecash sat issued by Cashu mints(v1) as message stamps.
https://github.com/keychat-io/keychat-app/releases

2024-08-25 13:40:57 GMT

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:
https://youtu.be/7uEeE3TUqmU
https://youtu.be/FESp2LHd42U

2024-08-14 15:57:58 GMT

We are very pleased that more and more people recognize the model of using ecash sat as message stamps.
We believe that this seemingly trivial 1 sat is like a butterfly flapping its wings, capable of producing an unexpected butterfly effect. #note12zd…znr2

2024-08-14 09:26:38 GMT

Simplex Chat is very popular in the Nostr community; whenever someone posts a note asking which chat app is secure, many people recommend Simplex Chat. We also think Simplex Chat is a great app.
So, many people ask what is the difference between Keychat and Simplex Chat? Is Keychat's security as good as Simplex Chat's? Is it really possible to create a chat app as secure as Simplex Chat on Nostr? Why not just use Simplex Chat? Why reinvent the wheel?
A common misconception in the Nostr community is that Nostr is not suitable for private things.
"Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all." — Signal Founder Moxie https://signal.org/blog/the-ecosystem-is-moving%C2%A0
This is because the encryption process is completed on the client side, and relays only pass the encrypted messages.
Keychat and Simplex Chat both use the Signal protocol to encrypt messages, so both meet the following security requirements 1-4:
Anti-Forgery
Anti-Forgery ensures that the sender of a message is verifiable and the message has not been tampered with.
End-to-End Encryption
End-to-end encryption ensures that only the sender and receiver can decrypt and read the message content, protecting it from unauthorized access by servers or other network devices.
Forward Secrecy
Forward secrecy ensures that even if the current key is compromised, historical messages cannot be decrypted, since each message uses a new encryption key, which is deleted after use.
Break-in Recovery
Break-in Recovery ensures that if the current key is compromised, future messages cannot be decrypted, and the system can recover from the attack. This feature is also known as backward secrecy.
Metadata Privacy
Protecting the privacy of communication involves more than just protecting the content of messages; it also includes protecting the identities of the communication parties and other data.
Regarding the fifth point, metadata privacy. The designs of Keychat and Simplex Chat are different.
Simplex’s metadata privacy protection scheme
"Simplex chat is the first messenger without user IDs."
“To deliver messages, instead of user IDs used by all other platforms, SimpleX uses temporary anonymous pairwise identifiers of message queues, separate for each of your connections — there are no long term identifiers.”
“Temporary anonymous pairwise identifiers
SimpleX uses temporary anonymous pairwise addresses and credentials for each user contact or group member.
It allows to deliver messages without user profile identifiers, providing better meta-data privacy than alternatives.”
We can understand this mechanism as, if a Simplex Chat user has 10 friends, they have 10 IDs, using different IDs with different friends?
Keychat’s metadata privacy protection scheme
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.
Which scheme do you think is easier to understand and better protects metadata privacy?
Finally, Keychat also uses ecash sat as a stamp for messages, with relays funded by stamp revenue to sustain operations.

2024-08-12 09:44:41 GMT

The new version of Keychat, v1.16.1, is now available for download.
Users can now generate multiple IDs with a single seed phrase.
https://github.com/keychat-io/keychat-app/releases https://image.nostr.build/e6e0ccfbeac4907bfb7d1863ef6adf7496da676791970b3d824864718dd1b3cd.jpg #note1ayu…ugnp

2024-08-08 05:40:52 GMT

Keychat not only draws design inspiration from the postal system but also from Bitcoin wallets.
1.
Bitcoin wallets use a seed phrase.
Similarly, Keychat uses a seed phrase.
2.
Bitcoin allows users to maintain multiple wallets, enhancing privacy.
Similarly, Keychat users can have multiple IDs, enhancing privacy.
3.
Bitcoin wallet users can use their own Bitcoin node.
Similarly, Keychat users can use their own Nostr relay.
4.
Bitcoin wallets do not reuse addresses and continuously update their receiving addresses for better privacy.
Similarly, Keychat continuously updates its receiving and sending addresses to protect metadata and enhance privacy.
5.
Sending Bitcoin requires a transaction fee, which prevents spam and increases miner income. Especially as block rewards diminish over time, transaction fees will become the primary source of income for miners, allowing mining operations to continue sustainably.
Similarly, sending Keychat messages requires ecash sat stamps, which prevent spam and generate revenue for relay operators, enabling long-term operations. #note16gv…583q

2024-07-29 23:18:56 GMT

Thanks for testing.
This time, we have ecash sat and Lightning Network sat as our weapons, so this is not a war we are destined to lose. #note15l2…zf4s

2024-07-29 13:41:20 GMT

- reply

> instant messenger with perfect forward privacy
Keychat uses Signal protocol ( X3DH+ Double Ratchet Algorithm) to ensure message encryption security and meta-data privacy.

2024-07-29 08:44:14 GMT

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. https://image.nostr.build/39b8d937a38f3809cf4f0fe13cf2c2d749b0b5f94b185b2c64df90a6fd7e2952.jpg

2024-07-26 18:30:20 GMT

The current version of Keychat uses a seed phrase instead of nsec. This has caused a lot of controversy, with many people believing that Keychat does not understand the spirit of Nostr: having a single Nostr ID that is universally used across all Nostr apps.
In fact, the first version of Keychat used nsec. Later, we intentionally switched to seed phrases. Why?
Just like when we use Bitcoin wallets, we now more often use seed phrases rather than private keys. Using a seed phrase is an improvement in user experience. Moreover, NIP-6 defines the basic key derivation from mnemonic seed phrases. A single seed phrase can derive countless Nostr IDs.
Using a single Nostr ID across various Nostr apps focused on public notes is reasonable because users are sending public messages, and they can better accumulate reputation.
However, for Nostr apps focused on private notes, users should use multiple IDs to achieve better privacy. For example, you could use ID1 for close friends and ID2 for work colleagues. Current chat applications provided by internet giants do not encourage users to use multiple IDs simultaneously because multiple IDs affect data mining, reducing the accuracy of user profiling and, consequently, advertising revenue. In this context, using only one ID is a bug, not a feature.
If you use your Damus ID to chat with others on a Nostr app that focuses on private messaging, do you want all those people to see the public notes you have posted?
A seed phrase that is universally applicable to all Nostr apps allows users to choose which ID to use in a particular app, with the ID generated from the seed phrase. This is far better than using a single Nostr ID across all Nostr apps.
Don't forget, there are not only Nostr apps focused on public notes but also those focused on private notes.
A reasonable chat app allows users to use multiple IDs simultaneously, whereas a microblogging app’s DM often has only one ID. This is just one of the differences between the two. When we say, "Designing a DM for a microblogging app is not the same as designing a chat app," we are not playing with words; we are not that bored.

2024-07-26 14:43:10 GMT

Designing a DM for a microblogging app is not the same as designing a chat app. #note1s9e…na9g

2024-07-26 14:40:21 GMT

- reply

Absolutely not. DMs prefer multi-device synchronization over forward secrecy. Chats prefer forward secrecy over multi-device synchronization.

2024-07-26 13:23:39 GMT

If you only have three minutes to learn about Keychat, there is no better resource than this brief introduction of just over a hundred words. #note16gv…583q

2024-07-26 12:00:20 GMT

Currently, Damus relay addresses spam issues by limiting the frequency of posting notes, while nos.lol uses proof of work to tackle spam.
Keychat relay uses "stamps" to solve spam problems and generate revenue.
If a user has a cashu sat balance, Keychat automatically attaches a stamp, which is 1 sat, to messages sent by the user.
The stamp is affixed to the event, and the relay is the first to receive the event. The relay then copies the cashu sat, accepts it, and forwards the message. #note15sz…vhc8

2024-07-26 09:48:55 GMT

The new version of Keychat, v1.15.6, is now available for download.
This update resolves the bug where the cashu balance does not display immediately after minting.
Please upgrade to the new version.
https://github.com/keychat-io/keychat-app/releases
Because we have reservations about NIP-17, this version has not yet adopted NIP-17 in place of NIP-4. #note17hd…7m9x

2024-07-23 10:04:48 GMT

The new version of Keychat, v1.15.4, is now available for download.
The update simplifies the friend-adding process, making it incompatible with the previous version.
Please upgrade to the new version.
https://github.com/keychat-io/keychat-app/releases
In the next version, we will replace nip-4 with nip-17. #note1hg4…sr6q

2024-07-17 16:00:27 GMT

Finally, we are confident enough to invite interested users to test Keychat.
Keychat code: https://github.com/keychat-io
Keychat Android apk: https://github.com/keychat-io/keychat-app/releases
This version inevitably still has many bugs, which we will continuously fix. We will also modify any designs that are not reasonable. Thank you for helping to test this early-stage application.
For now, do not store too many sat(<200 sat, about 13 cents) in Keychat.
If you need some ecash sat to test the postage feature, please add 👇.

2024-06-26 02:46:01 GMT

The MASQUE Proxy should be the final piece in the protection of metadata privacy at the network level.
https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque-proxy.html #note12ef…ceua

2024-06-13 15:51:31 GMT

- reply

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.

2024-06-11 12:57:56 GMT

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

2024-06-10 16:33:46 GMT

- reply

Yes.

2024-06-10 14:15:53 GMT

- reply

Relay model.

2024-06-07 10:23:26 GMT

For current Bitcoin holders, we first possess on-chain sats, then convert a small portion of those into Lightning Network sats, and subsequently turn a small portion of the Lightning Network sats into ecash sats.
For new users who are not yet Bitcoin holders, they might first acquire ecash sats. Once they accumulate enough, they can have self-custodial Lightning Network sats, and as the amount grows further, they can then own their own on-chain sats.
The order of acquiring sats is potentially reversed for new users compared to existing Bitcoin holders. #note1wet…ylgl

2024-06-07 10:05:23 GMT

Transfer the sat from the non-self-custodial eCash wallet to the self-custodial Lightning Network wallet. https://video.nostr.build/10e483491fc4ebfbeb23bc27b7decc7c63fe19f46c30b6621c3590f7383be40d.mp4 #note1w7a…av2v

2024-06-06 09:25:52 GMT

From the perspective of how long notes are stored on relays, it could be said that Keychat primarily uses Nostr as a communication protocol, while Damus primarily uses Nostr as a storage protocol. #note1fyp…q0gh