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

nprofile1qqsth7fr42fyvpjl3rzqclvm7cwves8l8l8lqedgevhlfnamvgyg78spzpmhxue69uhkummnw3ezumrpdejqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcr9j8du

Publishing to

nostr.land

relay.damus.io

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-29 03:29:27

- reply

We’re still working on higher-priority tasks. Since it’s still a test version, you can try generating a new seed phrase for testing.

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 08:21:55

- reply

H4sIAAAAAAAAEx3PyY1YQQgA0Vzm/A/sSxyOABqIwPnLGt9LKr2fP/X35/vOXRKpRDt3snVxOkAJeyzKubbTE2FEwneeJkSLliCuxPtAtV5PM6KcLYaqqOLZRu7cWcwgAVLhyrw4Duc1fzubOYDzibmheyPf1uZMYttdF6rqqlUrIGkrZh80u4v9FhkjWDcfAwkiqMgHCk5cQkNp/VTBcP8j6uDWp8SGCpSl2I1OU7q6d/DlXbN+TzqJ10BTd1/OvKFn7Z2EzsY2kbn9+tzdcbC98Rhv6ExroWTZNWB5IaDj3vKgtsVkXqZtEcC0lEyFZp00iyDRWvRHGAoqivaBOrDzGFUTObXahCo/yVADgmT/pU0sinth4QIqzksSm/P90ClDRCQR6Yv2HjFQpOwHfNMybzv5jOk1WBHkw0WMZkYYJn2a4djcs1YoShFAxDODQyFhIUDupDGyo7FBkNrvsQr+zlJaI0Sb/wG/BmqwdwIAAA==

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-14 00:51:32

- reply

👍 https://image.nostr.build/942854f0cec53910f42b3cf7a62f328e8102830b2384254d0e12897bee15d5a1.jpg

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

- reply

Yes.

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:44:42

This is a great Nostr search website.
If you want to search for certain topic posts published by Keychat, we recommend using it.
https://advancednostrsearch.vercel.app

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:31:52

- reply

The primary reason Keychat includes a built-in ecash wallet is to support ecash sat stamps.
Over time, we’ve come to appreciate the Breez SDK’s approach of integrating Lightning Network wallets into various apps. We plan to explore using this SDK in the future.

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:53:59

- reply

It’s possible that a relay receives the stamp but does not forward the message.

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 07:53:38

- reply

We haven't written the spec yet; it's still in preparation.
I want to emphasize one point: apart from adding the functionality to update the recipient's address using the Signal protocol, we have almost 100% reused libsignal without modifications. Although Nostr and Signal use different cryptographic suites, as long as we treat the Nostr public key as an ID (serving the role that a phone number does in the Signal app), the Signal protocol will only be responsible for encrypting the message, so there is no need to unify the cryptographic suites of the two.

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:22:16

- reply

#note1ffg…ntlr

2024-09-30 11:21:21

- reply

#note1guz…mq8y

2024-09-29 02:29:10

- reply

#note1ryv…20js

2024-09-29 02:27:30

- reply

#note1lsc…y29d

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:49:33

- reply

If we can solve an issue on a specific layer, such as the metadata privacy of recipients and senders at the application layer, that is definitely progress.
IP issue is a network layer issue and needs to be resolved at the network layer.
Moreover, the solution to the recipient's metadata privacy issue is the same as the solution for the sender's metadata privacy issue: both are addressed by continuously updating addresses.

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:54:48

A picture is worth a thousand words. #note1lkg…nxnw

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:35:19

- reply

#note174e…v9mj

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