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

NIP-57 Address

opposedmouse41@walletofsatoshi.com

Profile Code

nprofile1qqsth7fr42fyvpjl3rzqclvm7cwves8l8l8lqedgevhlfnamvgyg78spz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmnymvpm86

Publishing to

relay.damus.io

relay.nostr.band

nos.lol

Author Public Key

npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8

Show more details

Last Notes

2024-10-29 14:02:03

- reply

We are doing something similar.
#note14nd…3jn7

2024-10-25 11:20:01

- reply

> you have to send messages to a central server every time you make a transaction.
This is not necessary. As long as the ecash wallet has enough coins of different denominations, the sender does not need to send a message to the mint server.
For example, Keychat’s ecash wallet will exchange a large number of 1-sat coins with the mint server at once, and these coins are then used as stamps. The sender doesn’t need to continuously send messages to the mint server.

2024-10-25 00:42:09

- reply

#note1lsc…y29d

2024-10-25 00:18:06

- reply

#note1j9u…ve25

2024-10-24 09:15:54

Thanks for testing. https://image.nostr.build/aadc4801e8327a23eb3598307f219624c839765401498804f11710dd1848f344.jpg #note1tg4…30gs

2024-10-24 07:52:01

- reply

🙌
@npub1h0u…rwx8

2024-10-22 08:30:42

https://image.nostr.build/e194e1aa78b881c9c8fbf714ea092185a8dd06159032eb8dcdfa5ba9309fad76.jpg #note1jw0…uscj

2024-10-21 15:43:48

- reply

Ecash sats are like stamps that can be directly attached to messages.
We want to see the formation of a bot marketplace, with AI bots being one of them.

2024-10-21 14:57:56

We are developing this feature for Keychat. https://image.nostr.build/27e24850fe417149b7f9fe1b7b480910183030626293e17c069c04309fcf1c11.jpg #note15jr…kk37

2024-10-18 03:39:38

Interesting perspective. #note1w33…2233

2024-10-14 00:52:59

👍 https://image.nostr.build/502f7f3e39af2e28d6d8ea07b38e2325987e90251d0c025a21edb4e51e5b77df.jpg #note1zhe…epmz

2024-10-13 15:06:25

- reply

We estimate it will take 1-2 months.

2024-10-13 01:10:09

- reply

Thank you for the feedback.

2024-10-12 07:54:57

- reply

I found out that this website was developed by @npub1vp8…npsw after checking the Zap page. It’s a really helpful tool, much appreciated 🙏.

2024-10-12 07:31:27

- reply

#note1lsc…y29d

2024-10-12 07:26:09

- reply

#note1ucp…80r2

2024-10-12 01:52:19

- reply

Since ecash is a piece of data, much like a photo, sending and receiving ecash in a chat may be the simplest method. https://image.nostr.build/b9fa666594550c82848ea59ede131aaee75b5cd20fb7c56b4cb2292094a51242.jpg

2024-10-12 01:35:07

- 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-12 01:21:02

- reply

👍
Changing Keychat’s UI to resemble email would turn it into Keymail, and it even has stamps.

2024-10-11 07:34:41

Apps like Signal and Telegram use an open-source peer-to-peer WebRTC solution for voice and video calls.
Why don’t they continue using a peer-to-peer solution for text messaging as well? Shouldn’t it be simpler?
The reason is that, for voice and video calls, both people are online at the same time, whereas for text messaging, users may not be online simultaneously.
Therefore, a constantly online relay is needed to temporarily store messages.

2024-10-11 03:59:02

- reply

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

2024-10-11 03:56:48

- reply

We are still working on developing MLS group chat, and after completing this task, we will evaluate Amber login. Since Keychat uses the Flutter development framework, it supports both iOS and Android versions, but Amber seems to only have an Android version. In any case, we will consider it.

2024-10-11 03:31:46

- reply

We believe that if IDs and receiving/sending addresses are differentiated, having an ID is an advantage and it does not affect metadata privacy.

2024-10-05 03:07:02

Keychat also draws design inspiration from web browsers. #note1czx…8kp9

2024-10-05 00:45:24

ecash sat stamp🎯 https://image.nostr.build/aadc4801e8327a23eb3598307f219624c839765401498804f11710dd1848f344.jpg #note19ds…kxw4

2024-10-05 00:44:25

- reply

ecash sat stamp🎯 https://image.nostr.build/aadc4801e8327a23eb3598307f219624c839765401498804f11710dd1848f344.jpg

2024-10-03 12:56:07

- reply

#note14gr…rrzc

2024-10-03 11:42:44

- reply

Keychat is a chat app, built on Bitcoin ecash, Nostr protocol and Signal protocol.
Keychat uses ecash sats as stamps for messages. https://image.nostr.build/98d387b76f7433f3cf9b35f982d731f42570215bf6376497817f7015c5bed6b2.jpg

2024-10-03 09:53:11

- reply

cc @npub12rv…85vg @npub178u…qrg4

2024-10-03 09:51:43

The prepaid and pay-per-use models are already very close to the ecash sat stamp model, as both charge per use.
The prepaid model is an account-based model, where after recharging Lightning Network sats, only the corresponding account can spend the balance.
The ecash sat stamp is a cash model, without accounts. Users send Lightning Network sats to an ecash mint and receive ecash sat tokens. These tokens can be shared with others for use.
Both models involve third-party custody of LN sats.
The stamp model offers greater flexibility and privacy.
Under the prepaid model, the relay has to take on more tasks as it needs to keep accounts for various users.
In the stamp model, the client takes on more responsibilities, as it needs to attach the ecash sat token to the note.
We believe that more and more nostr clients will incorporate built-in ecash wallets. #note1mqw…ma05

2024-10-03 07:10:49

👍
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-03 04:44:55

How should we solve this metadata privacy issue?
There is a very intuitive and simple solution.
We need to differentiate between ID and address. ID and address are not the same thing, and IDs should not be used as addresses.
We should separate the sending address and receiving address from the ID, and then update the sending address and receiving address for each message as much as possible. #note14x4…jcz4

2024-10-03 02:56:26

Disembedding from the system/ Matrix. #note1h89…gaaz

2024-10-02 08:01:27

- reply

The Signal app only uses the Signal protocol for message encryption.
The spec we are going to write will be divided into two parts: the Signal protocol for encrypting messages and the Signal protocol for updating the recipient's address to protect metadata privacy.

2024-10-02 02:59:56

https://nostrlogin.org/

2024-10-02 00:07:34

- reply

#note1afk…g3wc

2024-10-02 00:06:38

- reply

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

2024-09-30 11:40:12

- reply

#note13hk…4nax

2024-09-30 11:38:54

- reply

#note1afk…g3wc

2024-09-30 11:21:21

- reply

#note1guz…mq8y

2024-09-29 02:29:10

- reply

#note1ryv…20js

2024-09-29 02:25:17

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-28 09:39:30

- reply

Correct, the sending address (which also signs the messages) can be random.

2024-09-28 09:32:44

- reply

Keychat's receiving addresses are created using the DH ratchet; each time the DH ratchet turns, the receiving address is updated accordingly.
Are you referring to the scenario where, after two people have used a receiving address, others send spam messages to that user's receiving address? Once there is a new address, the chatting parties no longer monitor the previously used receiving address. Additionally, Keychat uses ecash sat postage stamps.

2024-09-28 09:27:20

- reply

If Alice has two phones and Bob has one phone, and Alice's two phones have different Keychat IDs, when Alice chats with Bob, if she feels it necessary, she can create a pairwise group with her two Keychat IDs and Bob. This can achieve multi-device synchronization to a certain extent.

2024-09-28 08:42:34

- reply

You are mixing up issues from different layers.

2024-09-28 08:31:09

- reply

NIP-17 exposes the recipient's identity and lacks both forward and backward secrecy. However, its advantage lies in better multi-device synchronization capabilities. Because the encryption key and receiving address remain unchanged, users can receive and decrypt all messages simply by importing their nsec. NIP-17 is designed for DM in microblogging applications, not as a standalone chat application. It prioritizes multi-device synchronization over enhanced encryption security. This is not a flaw, as it has suitable application scenarios.

2024-09-28 08:26:21

- reply

The solutions you mentioned for mitigating the issue of NIP-17 exposing the recipient's identity do not completely solve the problem.
A better solution would be to automate the updating of the recipient's address.
#note1ck7…x62j

2024-09-28 08:11:19

- reply

For the second question, your answer is correct. The encryption keys derived from the double ratchet are deleted once used, and users can set to automatically delete messages that have been read. Therefore, a hacker can only access the most recent messages and cannot retrieve past messages.
When I said that deploying the double ratchet wouldn't be more difficult, I meant that we can directly reuse the open-source code, libsignal.
If one party in a chat sends multiple messages in succession, the symmetric ratchet will come into play. Moreover, the double ratchet algorithm maximizes the use of the DH ratchet, with the DH ratchet turning each time the chatting parties reply to each other, instead of changing the DH at set intervals.

2024-09-28 06:28:08

- reply

The advantage of the double ratchet is in the automated operation of the symmetric ratchet and the DH ratchet. However, "just periodically generating new keys" still involves how to generate and exchange new keys.
Moreover, implementing the double ratchet algorithm on Nostr would not be more difficult.

2024-09-27 03:00:02

- reply

Perhaps because mobile phone screens are much smaller than computer screens, discussions that originally took place on web forums have moved to Telegram, which has a chat interface, especially its groups with thousands of members. This is just my personal opinion.

2024-09-27 02:51:36

- reply

Telegram groups do not have end-to-end encryption, so you can join a group by clicking on a group link, similar to a forum. Signal groups are end-to-end encrypted, which conflicts with the forum concept.

2024-09-27 02:34:42

1. better Signal on Nostr
VS
2. better Telegram on Nostr.
Which one do you want, 1 or 2? #note1evp…wc50

2024-09-27 02:11:09

- reply

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.

2024-09-27 01:54:27

Keychat users can set their own receiving relay for each chat room.
If both parties in the conversation set different receiving relays, the sending relay and receiving relay will be different for the participants, which can enhance metadata privacy. https://image.nostr.build/9ae7c6f2f928824a4ee49c3cde4714d2eb39cb3ba14ebfc029ca8b5322905fc5.jpg

2024-09-27 01:33:01

- reply

Got your point.
Since the capabilities of relays are limited, they can't be controlled as precisely as centralized servers, which makes it a bit difficult. We'll look into it.
The limited capabilities of relays make it easier for users to freely switch between relays.

2024-09-26 05:15:10

- reply

#note16hm…tkvu

2024-09-26 05:14:38

- reply

#note13p9…t6qt

2024-09-26 03:23:02

- reply

Gift-wrapped DM only updates the sending address; the receiving address remains unchanged.

2024-09-26 02:51:17

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-26 01:41:26

- reply

#note1h84…gse4

2024-09-26 01:37:21

- reply

You are absolutely right. We associate 'from' with the sending address and 'to' with the receiving address. https://image.nostr.build/b498ce30f2a7147603a5e8f13bc4c7c3765ba98028db4dd2eb9fdfb97c8539ba.jpg

2024-09-26 01:30:56

- reply

Hi. We use the Flutter development framework, which allows us to output both Android and iOS apps simultaneously. We believe that early users of Keychat will come from the Bitcoin and Nostr communities. When you mention a referral button, are you referring to some usage tips?

2024-09-26 01:05:55

- reply

feature ✌️

2024-09-25 13:15:30

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

2024-09-25 12:13:19

- reply

This is to help users quickly understand how the sender's metadata privacy is protected.

2024-09-25 12:11:04

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

2024-09-25 11:49:23

- reply

The seed phrase login has not yet launched; this feature is being implemented along with backups. Since the Signal protocol encryption algorithm is stateful, backing up the double ratchet state files is also necessary.

2024-09-25 11:24:23

1. The first public test version of Keychat used seed phrases instead of nsec. This was because we believe seed phrases are more suitable for chat applications, as one seed phrase can derive multiple nsecs. It wasn’t our intention to create a closed system. Due to many people wanting to use their existing nsecs, we added nsec login in our new version. However, we still recommend using seed phrases.
2.Regarding the contact list, Keychat's contact list is stored locally on the client side and is not uploaded to the relay. Keychat's contact list and your following on Damus are different things.
3.We think it's reasonable to set Keychat relay as the default relay, just as Damus relay and nos.lol relay are default relays. Plus, users can remove the default relay. We insist on the stamp model because we believe there’s no such thing as a free lunch in the long run, and anything that's free indefinitely is more likely treating the user as the product.
4.Finally, 0xChat and Keychat/Simplex chat are vastly different; they are not the same type. Its default end-to-end encryption lacks forward secrecy and backward secrecy. Its optional secret mode's end-to-end encryption is also significantly inferior to the Signal protocol encryption. In the trade-off between forward/backward secrecy and better multi-device synchronization, it opts for better multi-device synchronization. #note196j…rene

2024-09-25 11:04:15

- reply

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

2024-09-25 11:01:32

- reply

A cognitive perspective: We all rely on metaphors to understand new things, comprehending the unfamiliar through the familiar.

2024-09-25 10:59:45

- reply

It's difficult to find a metaphor that matches 100%, and we must accept some imprecision.
In Keychat, the sending address and receiving address are also different.

2024-09-25 10:56:15

- reply

#note1fcs…uxw3

2024-09-25 10:45:45

- reply

But what he said is wrong.

2024-09-25 10:43:50

- reply

You haven't kept up with the updates of the new version. BTW, there's a huge difference between 0xChat and Keychat/simplex chat; it lacks both forward secrecy and backward secrecy capabilities.
#note1q3q…2r46

2024-09-25 10:21:04

- reply

We need to use the metaphor of letters to help users understand the mechanism of continuously updating sending address and receiving address.
Users understand that when sending letters from different places to a friend, different sending addresses need to be written. If a friend moves, a different receiving address is required.

2024-09-25 10:16:12

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 09:59:01

- reply

We're not sure yet; at least it's not a high priority.

2024-09-25 03:26:17

Simple and reliable.
Voice and video calls can use the open-source WebRTC solution, which Signal and Google Voice likely both utilize. #note1mep…k48x

2024-09-25 03:23:14

- reply

I guess prepay is also pay-as-you-go, deducting a portion from the balance after each use.

2024-09-25 02:47:03

- reply

Keychat's sending addresses are continuously updated as a mechanism to protect metadata privacy. This also means that Keychat cannot adopt subscription mode.
We are trying out the AI bot on Keychat , where you pay ecash sat per question.
“Lastly, Keychat addresses the issue of user payments and relay charges. Since each message is not linked to an ID, traditional payment models are not feasible. 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-25 02:42:57

- reply

Keychat's sending addresses are continuously updated as a mechanism to protect metadata privacy. This also means that Keychat cannot adopt a customized mode.
We are trying out the Keychat AI bot, where you pay per question.
“Lastly, Keychat addresses the issue of user payments and relay charges. Since each message is not linked to an ID, traditional payment models are not feasible. 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-25 02:31:29

A picture is worth a thousand words. https://image.nostr.build/8676bf135aa10fd6759933a1c6bbcd9e08c3ebf29f777f9a7cadcc20a5854229.jpg

2024-09-25 02:25:03

- reply

https://image.nostr.build/5cd0c55d1f032fdcadb20c5246d00511f0bfba12cad4067ce3fa04bf8e09ae79.jpg

2024-09-25 02:10:40

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-25 01:45:42

The Web lacks native user IDs and native money.
Bitcoin addresses both these issues.
Bitcoin is not only the native money of the internet, but it has also helped more people understand that public/private keys are the best form of user autonomy; these keys can be used to control one's own money as well as one's own ID.
Web + BTC = a better Web. #note1z3f…pu32

2024-09-25 01:21:17

Glad to see more and more people are coming up with the ecash sat postage stamp solution. #note1xus…fukz

2024-09-25 01:17:26

- reply

#note1zfs…qf2x

2024-09-25 01:16:48

- reply

#note1pdr…2vkr

2024-09-25 01:11:33

- reply

Everyone can create a bot on Keychat, such as an exchange bot. Keychat does not differentiate between humans and bots.

2024-09-25 01:09:28

- reply

Voice and video calls can use the open-source WebRTC solution, which Signal and Google Voice likely both utilize.

2024-09-25 01:02:00

- reply

Simple and reliable.

2024-09-25 00:57:07

- reply

A blog post by the Signal Foundation last year described their financial situation, indicating that they have been operating at a loss.
https://signal.org/blog/signal-is-expensive/

2024-09-24 09:53:03

- reply

Thanks

2024-09-24 09:50:10

- reply

We are experimenting with the Keychat AI bot (using the large language model API directly), where you pay per question with ecash sat. Anyone can create a Keychat bot.

2024-09-24 09:46:19

- 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 08:51:41

- reply

We aren’t sure how to name the QR code, so we still call it a QR code. This name can be misleading, as it might be mistaken for Npub.

2024-09-24 08:10:46

- reply

Correct, but we still hope that ecash sat becomes the most popular ecash.
Mint could even issue ecash discount coupons and ecash credit.

2024-09-24 07:47:28

- reply

We wrote a note explaining the Keychat friend-adding mechanism. We weren't sure how to name the QR code, so we still call it a QR code. This name can be misleading, as it might be mistaken for Npub.
#note1ua6…fxew

2024-09-24 05:30:42

In Keychat, there are two ways to add friends: via QR code (scanning or copy-pasting) or through Npub. We recommend using the QR code, with Npub as a secondary option.
Let's first review how Signal app handles adding friends.
In Signal, the phone number serves as the user's ID. When Alice adds Bob as a Signal friend, she enters Bob's phone number, and Signal’s server returns Bob's three public keys: IK(B), SPK(B), and OPK(B). Locally, Alice has two private keys: IK(A) and EK(A). Using the five keys (Bob's public keys and Alice’s private keys), Alice performs four DH (Diffie-Hellman) calculations to derive a shared key (SK). This SK is then used in the double ratchet algorithm, allowing Alice to generate an encryption key, k1. Alice encrypts her first message to Bob using k1, and her message header includes her public keys, IK(A) and EK(A), in plaintext.
IK(A): Alice's identity key
EK(A): Alice's ephemeral key
IK(B): Bob's identity key
SPK(B): Bob's signed prekey
OPK(B): Bob's one-time prekey
Bob similarly uses the five keys (his private keys and Alice’s public keys) to perform four DH calculations, resulting in the same SK. He then uses the double ratchet algorithm to generate the same k1, which decrypts Alice’s message. Bob’s keys (IK(B), SPK(B), OPK(B)) are stored on Signal’s server, with OPK being a one-time-use key controlled by the server.
DH1 = DH(IK(A), SPK(B)) DH2 = DH(EK(A), IK(B)) DH3 = DH(EK(A), SPK(B)) DH4 = DH(EK(A), OPK(B)) SK = KDF(DH1 || DH2 || DH3 || DH4)
The key difference between Keychat and Signal is that in Keychat, Bob’s keys (IK(B), SPK(B), OPK(B)) are only stored locally on the client and not uploaded to a relay.
When Alice adds Bob as a Keychat friend, Bob shows her a QR code (face-to-face or via email). This QR code contains Bob’s Nostr public key, IK(B), SPK(B), and OPK(B). The Nostr public key is Keychat’s equivalent of Signal’s phone number as an ID.
The QR code also includes a one-time-use receiving address, so Alice’s message is sent to this address, not directly to Bob’s Nostr public key.
(Why not store Bob’s keys on the relay, like in Signal? This could lead to metadata privacy issues, and relays currently cannot ensure that OPK is used only once. We are keeping an eye on this approach.)
Alice can now use the five keys (her IK(A) and EK(A) with Bob’s IK(B), SPK(B), OPK(B)) to proceed with encryption, just like in Signal.
However, if Alice and Bob are in the same group and Alice only knows Bob’s Npub, how can Alice add Bob as a friend? Alice sends a friend request to Bob using a method similar to NIP4, including her IK(A), SPK(A), and OPK(A). Once Bob accepts, they can exchange messages using the Signal encryption method.
If you can use the QR code to add friends, avoid using the Npub method.