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. nostr:note16gv0dfkfaj2cvyujxlk9thckm4vy63r9vl0hpcn9473flca9qqqscm583q


Pubky is very aware that it is web. 👍 nostr:note1efjjdwv73843z2wlqsyu83w6zwdcsfl73rjvkcz69sn5pe8u5qnqswaud4


Great project. Using ecash sats for pay-per-use with Kagi Search.

The ChatGPT bot that Keychat is developing also uses ecash sats for pay-per-use queries. https://image.nostr.build/2229e44dfeeea83957c83a0e3d21a4310a7ce9e80bd8f8a5368f2295f76c48c3.jpg https://image.nostr.build/c64382ebd7edcadc807f2c98e9af02bcbf7a6a1f5095680e0ae54bcd55bc0b11.jpg  nostr:note1em36yafj3tcunrwl3n640chx6a7m7864tattzkrnzupq3fmyq63sshrwjq


We are doing something similar.

nostr:note14ndp3r9axyme36rd2gs85d2h407y59zlsewjkcf20kn04hyj04asu93jn7


Ecash sat stamp https://image.nostr.build/aadc4801e8327a23eb3598307f219624c839765401498804f11710dd1848f344.jpg


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.


I believe that almost all Nostr relay implementations support kind 4 DM notes by default.

which relay implementation do you use?


In fact, we don’t believe Keychat is less private than Simplex Chat. Please check the comparison note below. If we thought Keychat was inferior to Simplex in terms of privacy, we wouldn’t have started the Keychat project.

nostr:note1ucp7v2226d6kgqllq6pxuff89tzrcmr9x7xf0hyrhdzgjzy92nwqch80r2


All Nostr relays that support Nostr DM kind 4 are Keychat relays.

Long press on the message you sent, select “raw data,” and you can see which relays forwarded the message. https://image.nostr.build/1f94f97f83daadccc6375441ec9640e9b1200b81e1ac9fce16c42c88ce62d629.jpg


The Relay needs to support kind 4 notes.


> 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.


Thanks.

We have also compared the core mechanisms of Simplex Chat and Keychat. 👇

nostr:note1ucp7v2226d6kgqllq6pxuff89tzrcmr9x7xf0hyrhdzgjzy92nwqch80r2


Currently, we only support testing through Android APK downloads. Once it stabilizes, we will add it to both the Apple and Android app stores.

https://github.com/keychat-io/keychat-app/releases


Thanks for testing. https://image.nostr.build/aadc4801e8327a23eb3598307f219624c839765401498804f11710dd1848f344.jpg  nostr:note1tg42gw8k60jecv55tk9q3e8rcutptqrz22tym3rvj0qel7zfylysmx30gs


The designers believe that the real timestamp of a note can be hidden.

We also think this is not a worthwhile trade-off.


🙌

nostr:npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8


https://image.nostr.build/e194e1aa78b881c9c8fbf714ea092185a8dd06159032eb8dcdfa5ba9309fad76.jpg  nostr:note1jw0aqnnvc730h79tmhqw8lnrfk8g2wrqzlyx86xhd57dtsxtqe4s27uscj


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.


We are developing this feature for Keychat. https://image.nostr.build/27e24850fe417149b7f9fe1b7b480910183030626293e17c069c04309fcf1c11.jpg  nostr:note15jrlyfym77hv3tydpfagsx4xj2pk0rg5e6g7x2tx2jzk03p3zy9qrwkk37


Interesting perspective. nostr:note1w33cjnnjple9ufkspwyysju5m25h70wr0jf2439gkvz59segk5kqt42233


👍 https://image.nostr.build/502f7f3e39af2e28d6d8ea07b38e2325987e90251d0c025a21edb4e51e5b77df.jpg  nostr:note1zhej45sqftr5fl58ny6358p7m53gt2r29fgdg3334xdkcx8xtezqudepmz


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


Is the web browser a super app?


We estimate it will take 1-2 months.


Thank you for the feedback.


Yes.


I found out that this website was developed by nostr:npub1vp8fdcyejd4pqjyrjk9sgz68vuhq7pyvnzk8j0ehlljvwgp8n6eqsrnpsw  after checking the Zap page. It’s a really helpful tool, much appreciated 🙏.


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


Notifications have made WhatsApp what it is today.

“WhatsApp started off as an app that would display statuses in a phone's Contacts menu, showing if a person was at work or on a call.

In June 2009, Apple launched push notifications, allowing users to be pinged even when not using the app.

Koum updated WhatsApp so that everyone in the user's network would be notified when a user's status changed. This new facility was used by users to ping "each other with jokey custom statuses like, 'I woke up late' or 'I'm on my way.'"

Fishman said "At some point it sort of became instant messaging".

WhatsApp 2.0, released for iPhone in August 2009, featured a purpose-designed messaging component; the number of active users suddenly increased to 250,000.” nostr:note15j9mwp486mrdpgjh6fnejq4k9zjyr4rrph0w6f88nygr3we83tgq509je7


Yes, you can copy and paste ecash into chat app.

We believe that more and more clients will have built-in ecash wallets.


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


Information and currency are bundled together in a single data packet and sent out together. We’ve always been fascinated by this idea.


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.


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.


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


Although Signal is open-source, the Signal app is centralized, and only they can run the servers. We cannot interconnect with Signal.


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.


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


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.


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


Microblog DM

VS

Standalone chat app nostr:note1j9umyh06g79t54hzkhpwqz4mrjpxehpa0pf0r8ywt4y3m3dcsvms6tve25


Keychat also draws design inspiration from web browsers. nostr:note1czxcgnc2xhryh8y9tlsdku3rq5s46t0k5jcd7n5x4z2gh78ejlesny8kp9


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


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


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


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


cc nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg nostr:npub178umpxtdflcm7a08nexvs4mu384kx0ngg9w8ltm5eut6q7lcp0vq05qrg4


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. nostr:note1mqwnfu7rrmvqd00jyhkkrlrxqhtyk4c5k2pfvulun8hyupx9t7nsqwma05


👍

PPE relay uses a prepaid, pay-per-use model.

Wouldn’t using the ecash sat stamp mode be simpler and more straightforward? nostr:note1c4qg93jgrjwn7j6s7efpqynu83snkkyfcpgnk8hh52ffm37u6rqqlzfclk


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. nostr:note14x4ftwu38xm3ajund24r0a4emj0m88j7e0gtewclcsdanev6s5cs53jcz4


Disembedding from the system/	Matrix. nostr:note1h895va2vdwscyl3r339pdwnvy83kdu0cl646dnal69ws2n2s6p2qx2gaaz


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.


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.


👍

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


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.


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


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.


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.


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.


You are mixing up issues from different layers.


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.


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.

nostr:note1ck7kjmlmcfwjl6cp4wwne9nneg2nzw484w4l3gwrjjhlysjvcxjq5tx62j


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.


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.


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.


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.


1. better Signal on Nostr

VS

2. better Telegram on Nostr.

Which one do you want, 1 or 2? nostr:note1evp20kv0meyqmcfhyvr8hs6v3w6xkx26uzsmw8uyt37pda07xzfqzmwc50


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.


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


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.


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


A picture is worth a thousand words. nostr:note1lkgvtwy7m26uy5afpw79zen6fqlkvhky0ncnvvtpeyua4hcqnqcq00nxnw


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. nostr:note10mmy7ru7perkhe9lavl7rlvpqd9a0knvz8ukhx7hhlc8zqtrhceqsaxxjm


In practice, when we fill out an envelope, we don’t need to include the sender’s information; we only need to write the recipient’s address, and there’s no need to write the recipient’s name. As long as the recipient’s address is precise enough, the letter can be successfully delivered. Not needing to write the sender’s information is equivalent to being able to write any random address. https://image.nostr.build/a35db954e4d60128e31eb244a487b8108878dbce5e345e6792846827ea35e1b2.jpg  nostr:note13pu0ntgaywtjgfx0lpqlgk4sxxqcnq5aw9fcgrd88jhmuk9ytzcsy46q2c


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


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?


feature ✌


https://image.nostr.build/b498ce30f2a7147603a5e8f13bc4c7c3765ba98028db4dd2eb9fdfb97c8539ba.jpg  nostr:note1r972lfyhhsdlxnh9gvezu2fauwnfn64fzfv57gn3sydxh0w3v80qr2nu0v


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


To better understand Nostr, first better understand the Web. nostr:note1p8raevewytfe9jk9mmxy3ejeyz22pgxz0hhjyl7jewefu5m2fclqhx6yhu


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.


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. nostr:note196jlftc3man9k92xzkugclzgqtu56mz9ht36szlk65hapt00c3fq0zrene


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


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


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.


But what he said is wrong.


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.

nostr:note1q3qtlppdpxzh0yp7l20sze60rjnnwvr8tc2z94uupll5c02zh3xqmn2r46


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.


Is the term 'gift-wrapped DM' clear to most people?

We think ‘each message updates the sending address' is easier to understand.


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


The "ecash sat postage stamp" will become a unique and powerful weapon for Nostr app developers. nostr:note1mgs6l2zuda8rtcz6afycltelv4a7srpqqh06xnsaflv4mzrwrqpsp5mch8


Simple and reliable.

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


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


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.”

nostr:note1h895va2vdwscyl3r339pdwnvy83kdu0cl646dnal69ws2n2s6p2qx2gaaz


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


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.


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. nostr:note1z3fcj76l7zkldafqvvzjxs643q9xz53pg3ur7n56xg8ek2c235fs8dpu32


Glad to see more and more people are coming up with the ecash sat postage stamp solution. nostr:note1xusp5w92mzw8jg4yny5c7ev7vx0ke54p6wgx9h2patwrl4387vds50fukz


Thanks 🫂


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


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


Simple and reliable.


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/


Using a Nostr ID to log in to the web is very important and has been underestimated. nostr:note1uceamf3v2yvht6v6lrpuelszlx3u608q7pc5jmc7vkufwz4299es7mk724


The "ecash sat postage stamp" is underrated; it should receive as much attention as Zap, if not more. nostr:note1p6z38dpg030da09uycmyx8dt5lle8mu5ey0f72kz69zrl6n5cw0s9vz3w5


Thanks


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.


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


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.


Using a Nostr ID to log in to the web is very important and has been underestimated. Thank you for your contribution.


Correct, but we still hope that ecash sat becomes the most popular ecash.

Mint could even issue ecash discount coupons and ecash credit.


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.

nostr:note1ua60g8th7kguquz94m5s4teaar50xlczu2my30heq27d3vucl5aslsfxew


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.


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

nostr:note174em9hd7vpdud3nf0m2jnpgxc38pgfwghtu9hz7ya4gq6pt2hu2qzav9mj


I'm not sure if I understood your question correctly. Initially, Keychat only supported seed phrase, using one seed phrase to derive multiple Keychat IDs. Later, many people wanted to add nsec login. They wanted to use the same ID Npub on both Keychat and Damus.


Time will tell. nostr:note1lh56er7xfw8w3vgygx8cuvc56kyawgemw3tk0t0hs4q4xpgtzxhqa4cujs


Hi, thanks. The new version of Keychat supports nsec login, so it can use an existing npub.

nostr:note1q3qtlppdpxzh0yp7l20sze60rjnnwvr8tc2z94uupll5c02zh3xqmn2r46


When we first heard the name Simplex Chat, we were curious about why it was called that. Later, we understood the explanation given by its founders.

Perhaps we can more accurately say that in Keychat, both the sending address and the receiving address are constantly changing, while in Simplex Chat, both addresses do not update.


For Keychat users, the mechanism of updating the receiving address for nearly every message is also an effective means of preventing spam. nostr:note1waj5jdken73uh3mdcn03n3gmcdst32vtkdejptmzh2cqyx0l9ydqstv4a3


Yes, but the Keychat relay does not accept public notes (kind 1).


Keychat relay requires ecash sat stamp.

Users can also choose free relay. https://image.nostr.build/27854099097f3fbd2f1649f7efe0948993b02a9d34be0cbacd5583d2692cb2fc.jpg


To our knowledge, there are currently no Nostr clients that reuse npub as a Bitcoin address. There are already clients that use a seed phrase, such as Keychat.


A seed phrase can derive both the public and private keys for Bitcoin addresses, as well as Nostr's npub and nsec. Npub and nsec can be understood as public and private keys in a customized format, which can be converted between the two formats.


If Nostr clients use a seed phrase, this will become more apparent. BTW, Keychat uses a seed phrase.


Alice and Bob use the Signal protocol to derive a key chain, sequentially using keys to encrypt/decrypt messages, and delete each key after use.

Alice        Bob

k1             k1
k2            k2
k3            k3
k4            k4
k5            k5
k6            k6
k7            k7
k8            k8
k9            k9
k10          k10
k11           k11
…….         …… nostr:note1afkmm89qpje2dzyrfclq80np7enas2l3s2g4pl5suezstfxt9thqwcg3wc


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 app stores.


Time will tell.


The "ecash sat postage stamp" is a form of payment, while Zap is a form of tipping. nostr:note1g6mkalt4hnu36x0km3rhj0q98kv2s3xje46w8yyf9wtx93cj96lstd0xu4


The "ecash sat postage stamp" is underrated; it should receive as much attention as Zap, if not more. nostr:note1p6z38dpg030da09uycmyx8dt5lle8mu5ey0f72kz69zrl6n5cw0s9vz3w5


The "ecash sat postage stamp" will become a unique and powerful weapon for Nostr app developers. nostr:note1mgs6l2zuda8rtcz6afycltelv4a7srpqqh06xnsaflv4mzrwrqpsp5mch8


Nostr app developers, please do not fear the "ecash sat postage stamp"—be brave. nostr:note1pdrs4wk774u6e0dcmvm96lwj07zsdsfywfztpzelad2tklk0tcls6y2vkr


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.” nostr:note1h895va2vdwscyl3r339pdwnvy83kdu0cl646dnal69ws2n2s6p2qx2gaaz


It also supports group chat.


Later, we will write a note explaining the two ways to add friends in Keychat: through QR codes and through Npub, which involves the Signal protocol. nostr:note1fheh3qx46469ku5s7y4ywl8w49g6srcup6es0stglafy6spupumq5j6msc


If you’d like, you can try adding this QR code as a friend.


We are also not entirely sure whether "ID key" or "Npub" is more suitable. "ID key" is easily understood by everyone, while "Npub" has a bit of a learning curve. We are open to which term is more appropriate, and we can make adjustments later if needed.


👍

Thanks for listing Keychat.


Keychat aims to organically integrate Nostr and Bitcoin.


https://image.nostr.build/364634d64f51c37d8c4f6d8992366d8cc5f3fccce08105eace3541a8279a15a5.jpg https://image.nostr.build/a4dc8260055c53c8b77c501f56ff34e3d679484bb0032f85fe38f2f9ea2b753b.jpg


I’m getting convinced that the only way against spam is keychat ecash stamp for each post

1 sat/post


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  nostr:note1ah6kqr3wdd7fjghdrnua44dzrjal69z39ddl6ltz2cj9ft50dmsqrzyq8y


Sat will become more and more popular, and ordinary people will be able to obtain sat more and more easily.


Wen relay that requires stamps for kind 1 events? 1 nut per note. nostr:note1zfstv00j65zd2767gg0nzdm8mfw8ata8cc5ky84v54qm0xwy07wqgeqf2x


👍

We have always encouraged users to use multiple Keychat IDs, with different IDs for different scenarios.


Why does Keychat need stamps (ecash sats as message stamps)? nostr:note1zfstv00j65zd2767gg0nzdm8mfw8ata8cc5ky84v54qm0xwy07wqgeqf2x


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.


Thanks for testing.


Hi, Keychat updates the encryption key for each message and deletes it once used. Even if a relay retains the ciphertext, no one can decrypt it again.

Regarding meta-data privacy, the sending address and receiving addresses in Keychat messages are almost disposable, continuously updating the sender and receiver addresses for each message without using the user’s ID.


https://x.com/simplexchat/status/1835393532250530132

As they later explained in their tweet, if 'privacy' specifically refers to meta-data privacy, then this statement can be considered valid.

However, if it does not specifically refer to meta-data privacy, the statement does not hold. Clearly, censoring a Keychat note is much more difficult than censoring a Damus note.


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. nostr:note1kmdgtupw8gdh2zzhyfvd2zjjflnl2k5y3l3cv3rwgv3kcndp8l6qlrycrx


There is no TestFlight version yet, only an internal developer iOS test version.


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.


nostr:note1qu6hf92ju8esurtt40du6y3tye38jvstyp58tzs89m8mgjjgawpsq4pvdk

“add more people to a group chat once the group chat is created”

The biggest challenge for end-to-end encrypted group chats is member changes, as the encryption key needs to be updated after such changes. However, this is not an unsolvable problem. Both the existing group chats in Keychat and the group chats currently under development allow for adding and removing members.


You can try adding the following account as a friend. 👇

H4sIAAAAAAAAExXPuY1gQQgA0VzG/gb3EcdGAA1EMPlrNX7pSfXzr35/vu/cJZFKtHMnWxenA5Swx6Kcazs9EUYkfOdpQrRoCeJKvA80rcMHVXfh5WN/r9/zUhQ8CKGs4gE1R7EHj4kNsqyBxwb0E3ND90a+rc2ZxLa7LlTVVatWQNJWzD5odhf7KzJGsG4+BQ9mUvpAb1lnB9I4tcFDdKMdWPRsyCaqkRvwPR6uoB6IcrQH8Br6Eyx+wmF4Shs54ebcPh4emTFpDDB9rjVJvIfm0iseWVbBxU2W8aK2IE5mwSnyBlIdCjDfBiyIGES6uakfdsATcYAPWUFYxf52cC3Lri5c2DWTU6ZO48lpQOQ1toTKVNKJbVbs2rqK95p/6GQERIiK+XleJ1G8WaIoO/Dslp6SPAQMcktiv+4uH2/NiUfdpQzLkwrhYjq0EWpml7cSQ7itf4qu4niz4S7N5LoSXXNvW2z8B2yz6dl2AgAA https://image.nostr.build/4e15f50b2631d8a2e4bc106815f496dcfbea94b23d888e57de2983683913d5a1.jpg


After you add a friend, the page will switch to the chat interface. Before adding a friend, the default page will remain as shown in the image. https://image.nostr.build/d9ceef3ce852994b2d633fb064ff1b2334df733e4cf63ec1331dc5a1356db4b0.jpg


Both WoT (web of trust) and the ecash sat postage stamp are methods to prevent spam.

The relationship between WoT and the ecash sat postage stamp is somewhat similar to the relationship between credit and money. Credit and WoT are based on trust and have a limited scope, whereas money and the ecash sat postage stamp are more universal.


Ecash sat postage stamp is Keychat’s PoW.


Yes, but the core codebase that the Signal app is using hasn't adopted it yet.

https://github.com/signalapp/libsignal


No, Keychat uses the same libsignal codebase as the Signal app.


I think so.

https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html


Simplex chat also uses the Signal Protocol for end-to-end encryption of messages.


Scatter ecash Sats across the whole internet.


- Proof of work was invented to prevent spam.
- Satoshi used PoW to rate-limit block production.
- Blocks create scarce Satoshis.
- Cashu puts Satoshis into bearer ecash tokens.
- KeyChat (privacy messenger) uses Cashu tokens as stamps to prevent spam.

Full circle  nostr:npub1qg8j6gdwpxlntlxlkew7eu283wzx7hmj32esch42hntdpqdgrslqv024kw.


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.


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 believe that the difference between Keychat and 0xChat is still quite significant. Keychat is a native messaging application, while 0xChat is a direct messaging (DM) tool. Especially when viewed from the perspective of forward secrecy and backward secrecy, the distinction is even more apparent.

nostr:note1es8cvyqh5y6yrvqwteu5frw6r30gwr0gnz28kd88v2xauvakhd2qfulc4m


Session was previously based on Signal Protocol before replacing it with their own in December 2020. Session Protocol does not support forward secrecy and backward secrecy.


Every message in Keychat is sent from a unique address, rather than using the ID as the sender's address, thereby better protecting metadata privacy. Therefore, relays cannot confirm the sender's ID, which also prevents the use of a subscription fee model. Apps like Damus are able to use a subscription model because public notes are sent from user IDs.


Of course. You can add as many cashu mints as you like.


Yes. Keychat automatically stamps messages, so it requires the wallet to have an ecash sat balance.


We believe that the early users of Keychat are likely to be Bitcoin and Nostr users. A Bitcoin user can guide a few people around them on how to use Keychat and transfer some ecash sats to them. The ecash sats are already quite sufficient now. Additionally, users can also choose to use free relays.


Keychat uses cashu sats as stamps for messages, so it has integrated a cashu wallet. https://image.nostr.build/30f5a76ac48483092f6130f9e45501d16a16010ceb5d57ed3bd17b0bf490663d.jpg


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.


People who want to obtain ecash sat stamps would choose to run a relay.


The biggest difference between servers and personal computers or smartphones is that servers can be online 24 hours a day. Using P2P for voice or video calls is a good choice because both parties are online at the same time. Therefore, WebRTC is widely used for voice and video calls. However, when sending text messages, it is difficult for the recipient to be online as well.


Yes.


The QR code contains not only the npub but also keys related to the Signal protocol. These keys are necessary to initiate the Signal protocol.


When someone wants to add you as a friend, the best way is to give them your QR code. Then, you can use the Signal protocol to encrypt your messages.

If you only know someone's npub, when you add them as a friend, you send them an enhanced Nostr DM. With your QR code in the DM, they can then send you messages encrypted with the Signal protocol. https://image.nostr.build/4b61014428165698ae63b88526aab70f53e6337eeddca60125b8bdf62a60fc37.jpg


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


Using continually updated sender addresses instead of sender IDs better protects metadata privacy.

This privacy mechanism requires a stamp to function effectively, as stamps address the issue of spam. https://image.nostr.build/c3e6f4160e17e687600674822c94f24810da5c4ca70d831d2a73b434d1b613c7.jpg  nostr:note1f6vw6cvnp0mt4s3nwakahffwf3qvh4z49kvt93l9gmqy9jpwd2ksfggmq6


Apps that assume users are foolish can move quickly.

Apps that assume users are smart can go far.


Thanks.

After the recipient claims the sat, the sender still sees the same status as before. This is because a sat is essentially a note, which lacks state and cannot display whether it has been claimed or not. You can only check if it has been claimed on the wallet page.


NIP-44 is just a part of NIP-17; it only handles encryption and is not a complete DM spec.


We are very grateful to those who repost our notes; it is the most crucial way for our ideas to reach more people.

We write explanatory notes to help more people understand what makes a good chat app and can verify Keychat's design for themselves. nostr:note1lscq8kz2huwnzngtdfqs22r7wlrasjy7uavcq22gjzxu8zawknqsvjy29d


Yes, we believe that the early users of Keychat are likely to be Bitcoin and Nostr users. A Bitcoin user can guide a few people around them on how to use Keychat and transfer some ecash sats to them. The ecash sats are already quite sufficient now. Additionally, users can also choose to use free relays.


Thank you for your feedback. We will add more default mints in the future. Currently, we are not running our own mint.


Maybe someone might wonder why the Session app wasn't listed in the note below.

Session was previously based on Signal Protocol before replacing it with their own in December 2020. Session Protocol does not support forward secrecy and backward secrecy. nostr:note1w2vtwrfzm77kf6vgrznfzuu0x0kc5040mwmqunw69lfwrqf5m20syqgjfj


Thanks.

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


Session was previously based on Signal Protocol before replacing it with their own in December 2020. Session Protocol does not support forward secrecy and backward secrecy.


Keychat version 1.16.3

https://github.com/keychat-io/keychat-app/releases


Could you please send me a screenshot of the issue page? This will help us resolve the bug. I just re-downloaded Keychat and successfully minted 123 sats, so I couldn't replicate the problem. https://image.nostr.build/86d84e2f9bf1965d15e2d8d8f2f0752283a5439efa024920419a04442e405a9f.jpg


Sorry for the problem. You paid the LN invoice, but didn't receive the ecash sats, right? Could you please send a screenshot of the problem page? https://image.nostr.build/96a200a2c43100e0f40a458542a20579c8e8f4397ff439d1d1f6c7f52dc92faa.jpg


We think that private messaging on Nostr is feasible. For concerns about metadata privacy, please see the note below.

nostr:note1lscq8kz2huwnzngtdfqs22r7wlrasjy7uavcq22gjzxu8zawknqsvjy29d


“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.”


Keychat uses Bitcoin ecash as stamps and Nostr relays as post offices.


Yes, we will use MLS to implement large groups later.

nostr:note1guzracdd3rfyussrfxjt63h3seela9a0jyzx5hd7gjmzhxsx7efs57mq8y


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. nostr:note1lscq8kz2huwnzngtdfqs22r7wlrasjy7uavcq22gjzxu8zawknqsvjy29d


We are still fixing bugs in the medium group, so we need to postpone the release of the new Keychat version until next week. nostr:note1kmdgtupw8gdh2zzhyfvd2zjjflnl2k5y3l3cv3rwgv3kcndp8l6qlrycrx


Compression algorithms can save a lot of storage and bandwidth costs.


Many people want it. nostr:note153k4xpkfvjgwnq58xylraajkylhkvfnktg7cd8z38fd7djtshduqh6cs79


We are using signal protocol to encrypt one-on-one chat and small group.


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.


Yeah


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


However, Jeff has abandoned the Signal protocol and is now focusing on the MLS protocol.

nostr:note1ryvs85az9tarr6t4sfdl04kvpej3cth7g047x8uvj4vrg734470sjw20js


Hi, it works for my Tor browser now.


The Signal app integrated MobileCoin, which is really unfortunate.


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.


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.


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.


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.


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.


“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). nostr:note13hk6h6c9zrpndsvy08tr0xlvz45jfj2twfl3tp03jt08sv6kcxmqx34nax


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 nostr:note1ffgsgvkltl96wzwe6lakv2ntjfkq2u48msx57mrvnnhtyde5s2js8antlr


nostr:note13hk6h6c9zrpndsvy08tr0xlvz45jfj2twfl3tp03jt08sv6kcxmqx34nax

note1x9jxtqje8fd0ut8wgtauchnr9ja7zh6kyq3tly6c3ntqrwzcselq6pdcvnn


nostr:note13hk6h6c9zrpndsvy08tr0xlvz45jfj2twfl3tp03jt08sv6kcxmqx34nax

nostr:note1x9jxtqje8fd0ut8wgtauchnr9ja7zh6kyq3tly6c3ntqrwzcselq6pdcvn


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.


The signal protocol.


OMEMO is a variant of the Signal protocol’s Double Ratchet algorithm.


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.

nostr:note1063mar49nu5edjcr8zqlgjs8zl3dlve5p74twv43sv3s9ztaykhq38vv7w


If you only have one minute to learn about Keychat, take a look at this 50-word introduction.

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. nostr:note1hvq86q5cr37v4jr3x92d6xn65e28r50ynvkal29edcc5xz5ftp4s2adqy0


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


We haven't developed this feature yet; it will take some time as we are still working on other development tasks.


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.


It’s possible.


Our current version is as follows:

nostr:note18fvgc5teqktphhvms7yplxcgg3mxnkh2cwxye2c8gxm52flmaujshrk2ky

Does this align with your idea? We have studied the method used by Bitcoin wallets to generate different key pairs from a seed phrase.


nostr:note1qzm7zrald5vzvwrvgagyveaqqyc04uxmcpa9cjxjymd0etaqa87scxvn7l

nostr:note174em9hd7vpdud3nf0m2jnpgxc38pgfwghtu9hz7ya4gq6pt2hu2qzav9mj


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/

nostr:note1qu6hf92ju8esurtt40du6y3tye38jvstyp58tzs89m8mgjjgawpsq4pvdk


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? nostr:note1qu6hf92ju8esurtt40du6y3tye38jvstyp58tzs89m8mgjjgawpsq4pvdk


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


#keychat try out , public id:
nostr:nprofile1qqs2h93kv0x5lgxmczr2v7dw90azdtjzc622gkjn87w9fmg9mnv7m2s2cmjr8

feel free to add me


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


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.


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.


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


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


2/n

Keychat's one-on-one chats fulfill the following five requirements：

nostr:note18h4ntc97ce674hrjzqrvn83phc006u8phdx7y977855rflj2n2fqv47v5z


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


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


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.


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.


Oh No 😂 nostr:note1pwsgdj3kasnyvgd2gaugul597eavcze6fvcp6ztp2l24fa3z7kkq0hsvq9


Oh No 😂

nostr:note1evp20kv0meyqmcfhyvr8hs6v3w6xkx26uzsmw8uyt37pda07xzfqzmwc50


We should consider Telegram as a modern message board/forum app with a chat-like UI, rather than a secure and private chat application. They are different applications.


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


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


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.”


🤝

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.


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.


nostr:note1ucp7v2226d6kgqllq6pxuff89tzrcmr9x7xf0hyrhdzgjzy92nwqch80r2

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.


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


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.


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.


“Anonymous systems require payments. But all current forms of small electronic payments harm your privacy.”

“Ecash fixes this” nostr:note1ehksgum74c5atm4asjyw8jzpvzwfx900hh0hxex9j7kcgggamv3qdqygd0


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


nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg 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


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


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


👍
Private Nostr is equally important as public Nostr.


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


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  nostr:note1cp60u4kwglcr9f3phnfyn05akr7saw68rzkj5euyj6r9e85dsalqaaa8xt


I'll send some Cashu to the first 3 people who message me on Keychat.

nostr:nprofile1qqs8r8uezrh7pmhcp20s6nqnswkmpnsmvrzkcgu5ewp65jtwklnlylc6kpa7q


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. nostr:note1slnurmhqxhv562vr7rval832s5mtjkpry0jsxyxgee9glmq6dyjquevv60


🤝

nostr:note14fz9vwssq6ny8049zjxdw28cs7mjfw583uuluyumvcpyrhh6ldkq5gkdx3


nostr:npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8 takes Cashu integration to a whole new level by enabling monetization and spam prevention, and paving the way for paid nostr relays with ecash


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


nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg wrote a perfect note that ties everything together.

nostr:note1cjq2ucwkh83x43juvu7fs0nn5lwjz6a4vasxwz4478v04ql85f4s5dvhj9 nostr:note1gnuljh3nkw8eks86a5c20j5uzu99tvnznclha3sl49uw6gqlrwkqqvqjey


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.


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.) nostr:note1kta54vdhagauvp3gvyur350g7x804y04kyphefn8up7wf4veg4fqj8cm2p


Can ordinary users afford the stamps?

nostr:note1pshpwanp7xy6whxxvxzdehl3dgsm24p5zl7t9szt6cjvxv6nxkuslusz32 nostr:note1kta54vdhagauvp3gvyur350g7x804y04kyphefn8up7wf4veg4fqj8cm2p


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. nostr:note12zdls4h8s49qrvem9zesjqnzfkd7t482uqtm6gn0645du2z7mgzs5vznr2


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.


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. nostr:note1qzm7zrald5vzvwrvgagyveaqqyc04uxmcpa9cjxjymd0etaqa87scxvn7l


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.


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.


Can you receive my Keychat message?


Make sense. Thanks

nostr:note1qzm7zrald5vzvwrvgagyveaqqyc04uxmcpa9cjxjymd0etaqa87scxvn7l


Thanks, Calle.

We hope users can verify Keychat's design at a macro level.

nostr:note12njdte3384d5czthynnxhagsr4hpv0wld8rqal862akg75fy93aqzn526r


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.


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


Thanks for testing Keychat.


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


We have received a lot of feedback about supporting nsec, and we will consider adding nsec later. We still recommend using a seed phrase. nostr:note174em9hd7vpdud3nf0m2jnpgxc38pgfwghtu9hz7ya4gq6pt2hu2qzav9mj


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.

nostr:note174em9hd7vpdud3nf0m2jnpgxc38pgfwghtu9hz7ya4gq6pt2hu2qzav9mj


The import seed phrase feature is still under development.


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

nostr:note1qw3dtp6ted8s0qahysp70emm4qe4ht87uxkpm7s7tsvx4uj3p2vqt95f8a


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.


Yeah


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  nostr:note1ayunjcu0vnmt6m4vkxunuc9m4znzr6eh8lhvkhr9gdky8d0jp0lsncugnp


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.


This is because private notes are not stored on the relay for long.

nostr:note1fypydwgve83pqkx9f7npavkttslje5jpkhga0rtxeqfu3uxwdrxsehq0gh


Could you give me a link to NIP 60/NIP 61?

Keychat is now focusing on private notes, but NIP 60/NIP 61 might be more suitable for public notes? We’re not sure.


Keychat has integrated Cashu wallet natively.

nostr:note18pfamtpmsv9wsem99fwqh75zusjx5qm7egkvqa3u9k9d9g2f9v2q9zm8uq


Bitcoin is the Internet’s native money.✌ nostr:note10wmgzjsx07nmdc0tw068xczewhxphgxm5e33gvk6c5evfgp2rcts68vvuu


Thanks for testing.

nostr:note16gv0dfkfaj2cvyujxlk9thckm4vy63r9vl0hpcn9473flca9qqqscm583q


Thanks


Thank you for recommending Keychat.


Thank you very much.

I've added my Lightning Network address to my nostr profile.

BTW, Keychat will support new service soon, and users can still pay per use with ecash sat.


keychat

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


If a user only saves their own notes, they don't need a local relay. A Nostr client just needs to provide a saving function.


Using ecash sat for anonymous micro-payments on a per-use basis is great.


the first epoch of nostr has focused almost exclusively on clients, but the clients have not hardly made the effort to enable relays as a paid service, and the big funders of nostr dev have not seen many relay devs because we are the hidden cinderellas , only relay devs who also do front end get any attention from anyone

this is going to changne in this second epoch... too many of the problems plaguing nostr now are relay related


There is an ongoing discussion about the sustainability of relay operations; here are our thoughts. nostr:note13k5h7928anypzntpvxzy2fvghx4z4ne6jdds3z87s9l8fpqdcqvsvspywl


Thank you.

We want to try a revenue model that relies solely on stamp income, without depending on donations. We believe this is a more sustainable and reasonable approach.


That's an interesting perspective. However, this analogy can help people better understand the Keychat mechanism.


I like what nostr:nprofile1qqsth7fr42fyvpjl3rzqclvm7cwves8l8l8lqedgevhlfnamvgyg78spz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3qamnwvaz7tmwdaehgu3wwa5kuegpz4mhxue69uhk2er9dchxummnw3ezumrpdejqj9swg4 is working on, regarding this. Exploring financial models for the relay network.


Do you mean you need a password to view the seed phrase?

When you add a new friend, you need seed phrase.


Perhaps we should consider how much budget the U.S. government allocates to the military each year compared to the postal system. Additionally, demanding both low prices and high quality is somewhat unrealistic.


Because it is monopolized by the government.


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. nostr:note16gv0dfkfaj2cvyujxlk9thckm4vy63r9vl0hpcn9473flca9qqqscm583q


Thanks.

1 stamp = 1 cashu sat now.

Nos.lol relay uses PoW to solve the spam problem.


Yes. https://image.nostr.build/d28be8d780501a1ce1387cb2d04daa7c5fb8c981c711b3d4bfada39e64891f70.jpg


Additionally, both small group and medium group support the use of multiple relays simultaneously.


Our app is developed using the Flutter framework, which supports both Android and iOS, and can be adapted for desktop use.

Once we reach a stable version, we will strive to get it on the app stores. Currently, it is still in an early, unstable phase.


Thanks.

PWA is on our radar for later; right now, the mobile app is our main focus.


3/N

By comparing the mechanisms of the small group and medium group, we can see that the small group, like one-on-one chats, fully utilizes the double ratchet algorithm of the Signal protocol (both the KDF ratchet and DH ratchet), while the medium group only uses the KDF ratchet.


2/N

We are currently designing and developing the Medium group. It supports more members than the small group, but at the cost of lacking Break-in Recovery and 50% Metadata Privacy.

Suppose the Medium group consists of three members: Alice, Bob, and Carl, along with a special member, David. Why is David special? Because his identity is shared by Alice, Bob, and Carl, meaning they all share David's private key.

When Alice sends a group message, essentially, Alice is sending a message to David. Bob and Carl, stepping into David’s identity, can receive and decrypt the message.

Similarly, when Bob sends a group message, essentially, Bob is sending a message to David. Alice and Carl, assuming David’s identity, can receive and decrypt the message.

The messages Alice sends to David are still encrypted using the Signal protocol, but since David never replies to Alice, the Medium group messages only utilize the Key Derivation Function (KDF) ratchet of the double ratchet algorithm and not the Diffie-Hellman (DH) ratchet. Thus, the encryption key for Medium group messages is continuously updated, providing Forward Secrecy but not Break-in Recovery.

Moreover, Medium Group messages obscure the sender's identity but not that of the recipients. Hiding the identity of the recipients requires the use of the Diffie-Hellman (DH) ratchet.

If the members of the Medium Group periodically update David by refreshing his public and private keys, they could significantly improve their Break-in Recovery capabilities.


Only E2EE is not enough.


1/N

Keychat's one-on-one chats meet the five requirements mentioned in the note below.

When designing its group chat features, Keychat prioritizes meeting these same five requirements as much as possible, rather than focusing on supporting a larger number of group members.

Keychat now offers a "small group" feature, which is intended for a limited number of participants.

When a group member sends a message within a small group, they are essentially sending an individual one-on-one message to each participant.

This method simulates a group chat through multiple one-on-one private chats.

Consequently, it almost retains the security features of one-on-one chats and meets the aforementioned five requirements. nostr:note18h4ntc97ce674hrjzqrvn83phc006u8phdx7y977855rflj2n2fqv47v5z


Secure messaging needs to meet these five requirements as much as possible:

1. Anti-Forgery

Anti-Forgery ensures that the sender of a message is verifiable and the message has not been tampered with.

2. 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.

3. 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.

4. 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.

5. 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. nostr:note1ma6ja6fc6nd7ux82z3qsx94k4lgcjwpz2jkjw2sf3vt8ptnef5ushmldyj


1. Anti-Forgery

Anti-Forgery ensures that the sender of a message is verifiable and the message has not been tampered with.

2. 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.

3. 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.

4. 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.

5. 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.


🫡 nostr:note1hq4tf2nkzjclhvl4jjrg4frp3qels0aqy7twjkj8tyg70qmzd4gq92mzwh


If you are testing Keychat, press and hold the message you sent and select ‘raw data.’ You will see the ‘postage stamp’. https://image.nostr.build/d0c82ba3383f562006342bc7950a734443dbbe859e86ab373aeb398a620dd06a.jpg https://image.nostr.build/4eb31b399b536442ed4a4728cf935c7a673c034f35db953e1948f4388920e3b7.jpg


Who will pay the bill, the relay operator or the user? nostr:note1enchgy8a655txpjl977hlwfw5ckukq2xwrej5fruv87k2xy9ez9qt5m6gh


Keychat encourages users to use as many trusted Cashu mints as possible.

Users can add an unlimited number of Cashu mints on Keychat.

Keychat encourages relays to accept as many trusted Cashu mints as possible. https://image.nostr.build/0374908ee73c47ceddbd71fca2205ba9d917fd04016f008546c8fc1d5831d0e3.jpg  nostr:note1qxcac8kfk0jjr8anv5scmr7m38ukszuw8gjuu3ye7redrfwws8cqs464fz


Thanks for testing 👍


It is indeed quite challenging.

But ecash sat and LN sat give Keychat superpowers that other chat app do not have, allowing it to provide services that other chat app cannot achieve.

We are still in development. nostr:note1nmhftp2hrmhplgqzv2eucmnfwtnyluuy4lcn4wt8yz3vzex46x3sg7njf8


It is indeed quite challenging.

But ecash sat and LN sat give Keychat superpowers that other chat app do not have, allowing it to provide services that other chat app cannot achieve.

We are still in development.


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. nostr:note15l2yd89eal84gpumua3n7y6ayc24ttyed7x6lugyxncaqfvg8npsh4zf4s


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.


Simplex is also a relay model, but there should be far fewer Simplex relays compared to Nostr relays.


Thanks for replying.

Hope those two signal protocol notes can help.

nostr:note1ffgsgvkltl96wzwe6lakv2ntjfkq2u48msx57mrvnnhtyde5s2js8antlr

nostr:note1afkmm89qpje2dzyrfclq80np7enas2l3s2g4pl5suezstfxt9thqwcg3wc


Do you just distrust the Signal app, or do you also distrust the Signal protocol?