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

nprofile1qqsth7fr42fyvpjl3rzqclvm7cwves8l8l8lqedgevhlfnamvgyg78spz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3qamnwvaz7tmwdaehgu3wwa5kueg5uedgv

Publishing to

relay.damus.io

nostr.wine

eden.nostr.land

Author Public Key

npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8

Show more details

Last Notes

2024-09-18 02:47:05

- 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 10:50:48

- reply

Thanks!
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-06 17:49:22

- reply

#note1ucp…80r2

2024-09-04 19:04:59

- reply

Thank you for testing Keychat.
We are adding nsec login functionality and plan to release a new version this week or next.
According to statistics, the average user sends about 50 messages per day, costing around 50 sats. With one cent currently buying approximately 16 sats, the daily cost is about 3 cents, and the monthly cost is about 90 cents. We believe that a pay-per-use model is more reasonable than a subscription model.

2024-09-03 17:38:44

- reply

#note1lsc…y29d

2024-09-01 14:12:34

- reply

https://heptabase.com/

2024-09-01 12:00:16

- reply

Thanks.
Users can also send ecash sats in the chat page, just like sending a picture. https://image.nostr.build/f2ec4e75a712335fbf63c20b5b56a300fe810750df1811153a4e5223269159c5.jpg

2024-08-31 13:07:38

- reply

Yes, we will use MLS to implement large groups later.
#note1guz…mq8y

2024-08-31 12:02:11

Designing a DM for a microblogging app is not the same as designing a chat app.
A chat app opts for better security while accepting poorer multi-device synchronization capabilities.
A DM opts for better multi-device synchronization capabilities while accepting weaker security.
We need to determine what our primary goal is, make trade-offs, and recognize that there is no perfect solution.
As reflected in the note below, the advantages and disadvantages of NIP-17 are two sides of the same coin. #note1lsc…y29d

2024-08-31 11:34:30

Many people want it. #note153k…cs79

2024-08-31 08:02:42

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-30 11:13:36

- reply

Yeah

2024-08-30 07:16:53

- reply

Once Keychat reaches a stable version, we will launch it on the iOS and Android app markets. Please wait for some time.

2024-08-29 16:58:51

- reply

However, Jeff has abandoned the Signal protocol and is now focusing on the MLS protocol.
#note1ryv…20js

2024-08-29 16:08:55

- reply

Hi, it works for my Tor browser now.

2024-08-29 15:53:53

- reply

The Signal app integrated MobileCoin, which is really unfortunate.

2024-08-29 15:51:23

- reply

Combining the Signal protocol with the NOSTR protocol is a very intuitive thing to do, and it almost doesn't require any major modifications to either protocol.

2024-08-29 15:49:45

- reply

In terms of message encryption, Keychat uses the Signal protocol to encrypt messages, thus it possesses both forward secrecy and backward secrecy capabilities. On the metadata privacy front, Keychat distinguishes between IDs and addresses, with addresses being continuously updated.

2024-08-29 15:43:55

- reply

Fedi sats as message stamps are far inferior to Cashu sats because they are more complex. We speculate that users will prefer to store larger amounts of sats in self-hosted Lightning Network wallets rather than in Fedi. Once users have accumulated enough Cashu sats, they can open a Lightning Network channel.

2024-08-29 15:22:07

- reply

We feel that Fedi is in an awkward position, caught between Cashu and self-hosted Lightning Network wallets.
An app could be built from various protocols, each handling different functions. For instance, in Keychat, the nostr protocol could handle ID and relay duties, while the Signal protocol takes care of encryption. Cashu would manage the stamping function, creating an app where the user retains control.

2024-08-29 12:23:21

- reply

In Keychat’s design, each message requires an ecash stamp, which solves the spam problem and addresses relay income issues.
For the user, there’s a clear distinction between needing one stamp or two.

2024-08-29 10:07:18

“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-27 22:17:41

- reply

#note1w2v…gjfj

2024-08-27 21:46:01

The Signal protocol, primarily known for its double ratchet algorithm, is used for end-to-end encryption of messages by the following chat applications and protocols. Many users are unaware that they are already benefiting from the security offered by the Signal protocol.
Chat Applications:
Signal app
WhatsApp
Skype: only available in the "Private Conversation"
Facebook Messenger: only available in the "Secret Conversations”
Simplex chat
Keychat
Chat Protocols:
XMPP
OMEMO is an XMPP Extension Protocol (XEP) for secure multi-client end-to-end encryption. It is an open standard based on a Double Ratchet and PEP, which can be freely used and implemented by anyone.
https://conversations.im/omemo/
Matrix
Olm (libolm) is an independent Apache-licensed implementation of the Double Ratchet cryptographic ratchet in C & C++, which also includes the new Megolm group ratchet as used in Matrix.
https://github.com/matrix-org/olm #note1ffg…ntlr

2024-08-27 16:23:24

- reply

#note13hk…4nax
note1x9jxtqje8fd0ut8wgtauchnr9ja7zh6kyq3tly6c3ntqrwzcselq6pdcvnn

2024-08-27 16:04:07

- reply

#note13hk…4nax
#note1x9j…dcvn

2024-08-27 15:59:41

- reply

#note13hk…4nax
#note1x9j…dcvn

2024-08-27 15:52:04

- reply

#note1x9j…dcvn

2024-08-27 12:15:47

- reply

However, we need to consider that in large group chats, such as those with 1000 participants, updating the key tree results in 10 updates per message.
Therefore, achieving the same frequency of updates as in one-on-one or small group chats is quite challenging.

2024-08-27 11:57:48

- reply

#note1ffg…ntlr

2024-08-27 11:51:36

- reply

We haven't mixed nostr and xmpp because they are two different network architectures.
We believe that the relay mode, where servers do not communicate with each other, is more suitable for chat applications than the federated mode of XMPP where servers communicate with each other.
#note1063…vv7w

2024-08-27 11:27:08

- reply

Right. Encryption protocols can only ensure security from a technical perspective; they fundamentally cannot address the issue of malicious actors within the group.

2024-08-27 10:32:24

- reply

The seed phrase generates many key pairs, which can be exported and then used in other apps. However, we still think that other apps should also consider using seed phrases, just like Bitcoin wallets use seed phrases.

2024-08-27 10:30:14

- reply

It’s possible.

2024-08-27 10:22:30

- reply

Our current version is as follows:
#note18fv…k2ky
Does this align with your idea? We have studied the method used by Bitcoin wallets to generate different key pairs from a seed phrase.

2024-08-27 10:10:22

- reply

#note1qzm…vn7l
#note174e…v9mj

2024-08-27 10:07:47

- reply

We haven't started studying the MLS group yet; we're still developing another type of group chat that's simpler than MLS. The MLS spec is over 100 pages long. 🙃
https://messaginglayersecurity.rocks/
#note1qu6…pvdk

2024-08-27 09:25:16

- reply

#note13hk…4nax

2024-08-27 07:03:16

Have you ever been curious about how the group chats are actually implemented?
Or have you assumed that group chats are as secure as one-on-one chats? #note1qu6…pvdk

2024-08-26 15:45:33

DM apps and chat apps are not the same.
DM apps favor synchronizing messages across multiple devices over ensuring forward secrecy.
Chat apps value the forward secrecy of messages more than their synchronization across multiple devices. https://image.nostr.build/c251ef23a3024288be2ae2c353076ada11fd9a7573d66981b5cc45725d77ee4e.jpg

2024-08-26 13:37:06

- 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 13:34:57

- 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 13:32:58

- reply

5/n
The "sender key group" is the protocol currently employed by the Signal app. Previously, Signal utilized the "pairwise group" model. We argue that Signal should have retained the pairwise group alongside introducing the sender key group, offering users a choice between the two.
In a sender key group, new members communicate their initial encryption key, k0, to the existing members. They use this key to encrypt their first message with k1 = kdf(k0), with subsequent messages encrypted using a succession of keys derived from the previous one, k2 = kdf(k1), and so on, where kdf is a one-way key derivation function. Other members decrypt messages by sequentially deriving keys from k0. These encryption keys are deleted after use, ensuring forward secrecy (meeting requirement 3), but failing to ensure backward secrecy (failing requirement 4).
Removing a member who has compromised the group's secrecy effectively requires forming a new group. This necessitates each remaining member conducting N*N one-on-one chats to share their new k0, where N is the total number of members in the new group.
This is the primary challenge of the sender key group: inefficiently updating membership. Both the "upgraded sender key group" and the "MLS group" seek to address this by enabling efficient membership updates. Achieving efficient updates of k0 would fulfill requirement 4, providing backward secrecy.
Keychat bypassed the sender key group in favor of developing the upgraded sender key group model.

2024-08-26 13:31:12

- reply

4/n
Keychat's second implementation of encrypted group chat is termed "shared key group," which will be discontinued in the next release.
Within a shared key group, a single encryption key is shared among all participants. Members encrypt their messages using this common key before sending, and others decrypt using the same key upon reception.
This setup fails to meet the third and fourth requirements previously outlined.
If a member who has compromised the group's confidentiality needs to be removed, fundamentally, a new group must be created. The group administrator must individually communicate the new shared key to each member of the new group, denoted as N, the number of participants. This illustrates a significant drawback of the shared key group: the inefficiency in dynamically updating its members.
Visualizing the five types of end-to-end encrypted group chats as a spectrum, the pairwise group occupies the most secure position, while the shared key group is positioned at the least secure end.
Initially, Keychat tested both extremes of this spectrum before proceeding to explore the intermediate options. https://image.nostr.build/70994a1f9e8ba57bafd0a295f47be278df72be85382f0fc629d34080767dc293.jpg

2024-08-26 13:29:43

- reply

3/n
Keychat's initial encrypted group chat implementation, known as "pairwise group," will be rebranded as "small group" in the forthcoming version.
In this setup, when a group member sends a message within the small group, they are effectively sending a separate one-on-one message to each other member, creating a group chat through multiple individual chats. Thus, this model nearly completely retains the security features of one-on-one chats, fulfilling the five previously mentioned requirements.
However, it supports only a limited number of participants and operates on an expensive "one stamp per message" basis. https://image.nostr.build/c898221292eaa597b992d5fe9acd94a4f1f4fb3ac52935f2eac184e237f89f2f.jpg

2024-08-26 13:28:26

- reply

2/n
Keychat's one-on-one chats fulfill the following five requirements：
#note18h4…7v5z

2024-08-26 13:28:02

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 12:10:11

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-26 10:36:02

- reply

OneSignal, this third-party service, does indeed collect user data, and we will abandon it in favor of developing our own messaging notification service. We apologize for this.

2024-08-25 17:16:21

- reply

Yes, from this perspective, it's similar to email. Both Matrix and email require registration on a server, and messages can only be sent and received through that server. They both utilize a federated server architecture. This is different from Nostr's relay model.

2024-08-25 16:54:55

Oh No 😂 #note1pws…svq9

2024-08-25 16:54:10

- reply

Oh No 😂
#note1evp…wc50

2024-08-25 15:43:50

- reply

#note13hk…4nax

2024-08-25 15:42:18

- reply

The iOS and desktop versions will need more time; currently, only the Android APK test version is available.

2024-08-25 15:40:57

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-25 14:09:01

- reply

If you’re asking about the spec for Keychat’s one-on-one chats, we haven’t written it yet. However, the code has already been open-sourced. Regarding one-on-one messages, we want to emphasize that although the nostr protocol and Signal protocol use different encryption suites, when we encrypt messages using the Signal protocol, we do not alter any encryption suites.”

2024-08-25 14:05:15

- reply

🤝
The reason we emphasize the additional message in MLS is because we use postage to solve spam issues, so an extra message means users have to pay for an extra stamp.
The MLS protocol is very complex, and we need a lot of time to understand it; we haven’t started working on MLS groups yet. Next week, Keychat will support both small and medium groups. Perhaps the medium group will eventually be replaced by a large group based on MLS. Much of what we are doing now is experimental, since Keychat hasn’t been added to the app stores yet, and we can continue to experiment.

2024-08-25 13:12:19

- reply

Fact 1 :
In one-on-one chat mode, the Signal protocol does not require an additional message (regardless of what it is called, to the relay it's just a note) to operate the DH ratchet and achieve backward secrecy of messages.
Fact 2:
MLS protocol requires such a message (regardless of what it is called, to the relay it's just a note) to update the ratchet tree to achieve backward secrecy of messages.
Our opinion:
We believe this is a key difference, especially from the relay's perspective, as Signal is more efficient in one-on-one chat mode.
Signal protocol is designed ofor one-on-one chats, whereas the MLS protocol is designed for large-scale group chats.

2024-08-25 12:31:38

- reply

#note1ucp…80r2
Regarding Nostr + MLS, it is suitable for large-scale group chats.
For one-on-one chatting, the Signal protocol is superior to MLS.
For the P2P mode in Keet, one challenge is likely where your text messages reside when the recipient is offline, and how they can be retrieved when the recipient comes online. (We are not familiar with the specific mechanisms of Keet. ) This issue does not exist during real-time voice or video calls because both parties are online.

2024-08-25 11:38:58

- reply

Perhaps medium groups and large groups can be combined in some way.

2024-08-25 08:40:57

- reply

No, MLS is suitable for large-scale group chats but not for one-on-one chats and small group chats.
If MLS is used for one-on-one chats, in order to achieve forward secrecy and backward secrecy, MLS requires a special message to update the group key, and then the normal message can be sent.
However, in the Signal protocol, the content needed to update the encryption key is attached to the normal message.

2024-08-25 07:14:20

- reply

We plan to support three types of encrypted group chats: small group, medium group, and large group.
When a member sends a message in a small group, they are essentially sending a one-on-one message to every other group member.
This group chat mode offers the best security, but it supports fewer group members.
This was the approach used by Signal for group chats a few years ago, and we regret that Signal has abandoned this model to accommodate more members. Signal should have retained this model and added the current sender key group mode as well.
Next week, we may release a Keychat version that supports medium groups. Compared to small groups, it will lose some backward secrecy capabilities, but it can support more group members.
Later, we will consider using the message layer security protocol to build large groups.

2024-08-22 15:50:18

“Anonymous systems require payments. But all current forms of small electronic payments harm your privacy.”
“Ecash fixes this” #note1ehk…ygd0

2024-08-22 15:47:36

- reply

Does this video link not work for you? https://image.nostr.build/7950fb1563783090a02412d769125b3164247d4d7c7abf7315655055ba6a0de4.jpg

2024-08-22 15:38:11

@npub12rv…85vg Calle's speech starts at 55:40, a fantastic presentation.
https://www.youtube.com/live/Zv766SV840k https://image.nostr.build/e272efd03ccedfd34dbb7b7053605c92bfe31136320f30ef88fb84ae3321e993.jpg https://image.nostr.build/6e8a824c692c36bcd118578cd0312c801e14f17b7108fa1b5032dc887af00d58.jpg

2024-08-21 15:44:51

- reply

BTW, Keychat users can also use free relays, like the Damus relay.

2024-08-21 15:42:04

- reply

We will be more optimistic because we believe that more and more people will own Bitcoin.

2024-08-21 05:58:55

- reply

👍
Private Nostr is equally important as public Nostr.

2024-08-15 18:58:46

- reply

In Keychat, users can set up multiple IDs. For example, ID1 could be used for chatting with family, ID2 with friends, and ID3 with colleagues. It's important to note that IDs and sending/receiving addresses are different; addresses change frequently, while IDs are static. When two people meet in person, they can add each other as friends by scanning a QR code. Online, they can exchange QR codes via other messaging apps. They can also publish it on their nostr profile. Since IDs are static, it’s easier to remember which ones you have used. See the screenshot below. https://image.nostr.build/e6e0ccfbeac4907bfb7d1863ef6adf7496da676791970b3d824864718dd1b3cd.jpg

2024-08-15 15:48:18

We hope more people can have their own Lightning Network channels, enabling them to have self-custodial LN wallets.
If new users (who doesn't yet have their own LN channel) needs to receive LN sats, but the amount is not sufficient to open a LN channel (due to the need to pay an on-chain transaction fee), they can use the LN channel of a trusted ecash mint to receive them.
The ecash mint gives them ecash sats. Once they have accumulated enough ecash sats, they can open their own LN channel.
Ecash sat is a bridge to self-custodial LN sat. https://image.nostr.build/50bd0b7e8effb85400d209bc2bf4d106cda2c1049ed31b80e907a4de23168b12.jpg https://image.nostr.build/187d53e559c2293318fdd64316c36878866508e43695e80e2786b01a4bd22c2d.jpg #note1cp6…a8xt

2024-08-15 14:42:44

One of the pursuits of a good chat application is to simulate face-to-face conversation in cyberspace, just like in a physical space, where sound waves travel from one person's mouth to another's ear and then dissipate forever. Only these two people know the content of the conversation. #note1sln…vv60

2024-08-15 14:41:13

- reply

🤝
#note14fz…kdx3

2024-08-14 19:29:57

- reply

You can have both an nsec and a seed phrase at the same time.

2024-08-14 19:08:42

- reply

I think it’s not easier than just supporting nsec login.

2024-08-14 18:37:09

@npub12rv…85vg wrote a perfect note that ties everything together.
#note1cjq…vhj9 #note1gnu…qjey

2024-08-14 18:28:19

- reply

Yes. In a healthy market, not every user needs to be a supplier; market mechanisms will filter out quality service providers. Overall, it's better than just having so-called "free" apps.

2024-08-14 18:23:19

Perhaps the stamp mechanism will restore a healthy market model with many suppliers and demanders, rather than just a few giants offering "free" chat applications as it is now.
The price mechanism comes back into play.
(It's just an intuition, not an argument.) #note1kta…cm2p

2024-08-14 18:12:03

Can ordinary users afford the stamps?
#note1psh…sz32 #note1kta…cm2p

2024-08-14 17:57:58

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 17:49:19

- reply

That’s strange, it’s the first time a user has encountered this situation.
Can you see the DM I sent you? I sent it using Damus.

2024-08-14 17:45:10

BTW, we didn't expect so many people would want to use their own public IDs (like those generated on Damus) to log into the unstable version of Keychat. After all, these IDs are precious because they have built up a reputation. #note1qzm…vn7l

2024-08-14 17:37:17

Currently, Keychat can only be tested by downloading and installing the android APK.
Once Keychat reaches a stable version, we will strive to make it available on iOS and Android App Store.

2024-08-14 17:35:08

- reply

Hi.
Currently, Keychat can only be tested by downloading and installing the android APK. Once Keychat reaches a stable version, we will strive to make it available on iOS and Android App Store.

2024-08-14 17:33:21

- reply

Can you receive my Keychat message?

2024-08-14 17:12:26

- reply

Make sense. Thanks
#note1qzm…vn7l

2024-08-14 17:06:39

- reply

Thanks, Calle.
We hope users can verify Keychat's design at a macro level.
#note12nj…526r

2024-08-14 16:48:41

We have received a lot of feedback about adding nsec support.
Now we believe that users will assess the risks and use IDs appropriately, so we will support it later.
Thank you for the feedback.

2024-08-14 16:41:26

- reply

https://image.nostr.build/fe821ab3546920b2cfd067e7b3a8af0df4b4d9313e22ab767affbcb019207e49.jpg https://image.nostr.build/69d1f251af8c5b26cf6d75d17e8681dfd791e0300fff6047dda6654ae40137e7.jpg

2024-08-14 16:19:51

- reply

Thanks for testing Keychat.

2024-08-14 16:18:01

- reply

Hi, the push server needs to know the user's receiving address and device ID in order to send push notifications to the user.

2024-08-14 16:11:24

We have received a lot of feedback about supporting nsec, and we will consider adding nsec later. We still recommend using a seed phrase. #note174e…v9mj

2024-08-14 16:10:50

- reply

Thanks for testing keychat.
We have received a lot of feedback about supporting nsec, and we will consider adding nsec later. We still recommend using a seed phrase.
#note174e…v9mj

2024-08-14 11:56:29

- reply

The import seed phrase feature is still under development.

2024-08-14 11:33:37

- reply

https://signal.org/blog/the-ecosystem-is-moving/

2024-08-14 11:31:33

- reply

Using sat to pay for encrypted data storage services is indeed a good use case. We are currently preparing an AI bot.
#note1qw3…5f8a

2024-08-14 11:26:38

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-13 06:49:13

- reply

Yeah

2024-08-12 11:44:41

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-10 17:38:48

- reply

What would happen if every Nostr user used their own relay?
If I followed 200 people, my phone would need to establish 200 network connections with 200 relays.

2024-08-10 17:29:08

- reply

This is because private notes are not stored on the relay for long.
#note1fyp…q0gh