- instant messenger with perfect forward privacy

We already have an instant messenger with perfect forward privacy. nostr:note1pyemsagay7ph43vf76m568x32r078r9ctrgvc4nya064mj2pqlxskq83s3


> instant messenger with perfect forward privacy

Keychat uses Signal protocol ( X3DH+ Double Ratchet Algorithm) to ensure message encryption security and meta-data privacy.


Yeah, it needs to wait until Keychat becomes more stable.


Keychat users can choose which relays to use. They can also choose not to use Keychat relays at all.

Relays can charge for stamps, but they can also operate for free, although free relays often have other restrictions, such as proof-of-work requirements for messages and frequency limits.

Relays decide which ecash sats issued by mints can be used as stamps.

If a user uses ecash sats issued by a mint that the relay trusts, the relay receives the ecash sats and forwards the message.

When a relay accumulates a certain amount of ecash sats, the relay requests the mint to convert these ecash sats into Lightning Network sats.

If a user uses ecash sats from a mint that the relay has not previously encountered, the relay first receives the ecash sats and then attempts to convert them into Lightning Network sats.

If the conversion is successful, the new mint can be temporarily considered trustworthy, and the message continues to be forwarded.

If the conversion is not successful, the new mint is added to a blacklist, and the message is not forwarded. https://image.nostr.build/39b8d937a38f3809cf4f0fe13cf2c2d749b0b5f94b185b2c64df90a6fd7e2952.jpg


The relay decides which mints' issued ecash sat it will accept as stamps.

A mint can set up a whitelist, and the relay will accept sats from mints on this list.

If a user uses a new mint, the relay can first verify whether this sat can be redeemed for ln sat. If it can, the new mint will be added to the whitelist.


You can use free relay.


We are still developing the import seed phrase feature.


Thanks for testing Keychat.


Outer kind4 from: random public key, inner kind4 from: sender ID.


It’s OK. Just a note.


Thank you for recommending Keychat.


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

1. Anti-Forgery
2. End-to-End Encryption
3. Forward Secrecy
4. Break-in Recovery
5. Metadata Privacy


Why does Keychat use [ecash sat] as message stamps instead of [Lightning Network sat]?

nostr:npub1m2mvvpjugwdehtaskrcl7ksvdqnnhnjur9v6g9v266nss504q7mqvlr8p9  gave a very good answer. nostr:note1nkmvyetnemzf24p4dgdpmfkjm07atrecw9vdcawtmmtvn77m7pps9ms5fa


Hope these two notes can help you.

nostr:note1ffgsgvkltl96wzwe6lakv2ntjfkq2u48msx57mrvnnhtyde5s2js8antlr

nostr:note1afkmm89qpje2dzyrfclq80np7enas2l3s2g4pl5suezstfxt9thqwcg3wc


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


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


What do you think about our following viewpoint?

nostr:note174em9hd7vpdud3nf0m2jnpgxc38pgfwghtu9hz7ya4gq6pt2hu2qzav9mj


Thanks for testing.

Regarding point 3, we believe that future relays will add support for storing multimedia content, as Cashu sat can solve the issue of storage payment. nostr:note1wcnuevdjk2x26pevw8z8jmktvmeycs9n0360gljqfta966ju4unq9g6v32


I'm afraid the current Nostr relays don't handle the pushing of events with random timestamps correctly. For example, Alice and Bob are chatting using NIP-17, and both of their chat apps are active. Alice sends Bob a message with a random timestamp from 48 hours ago. The relay not only pushes this message to Bob but also re-pushes all the messages that Alice sent to Bob within the past 48 hours. Alice then sends Bob another message with a random timestamp from 24 hours ago. The relay not only pushes this message to Bob but also re-pushes all the messages that Alice sent to Bob within the past 24 hours.


It works now.


Cc nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg


Yes. When we first tested using sats as stamps, only the 8333 relay was available for testing. We have been using it since then. We will add more mints in the future.


I think it’s just the Lightning Network part that’s offline.


Oh, sending and receiving work fine, but minting seems to be offline.


I can use it normally now.


Here, Damus refers to all microblogging-like Nostr apps. Yes, the term "kind 0" is more precise.


Some people have already put their Keychat ID in their Damus profile. It's best not to use your primary Keychat ID for this; using a secondary ID would be better.

This is one of the advantages of being able to use multiple Keychat IDs simultaneously.


With a 12-word seed phrase, you have countless self-controlled IDs.

Additionally, this ID seed phrase is also the seed phrase for your Cashu wallet. nostr:note1crs27znt68rry3m8eh7q6s6wf2v26vxj6zw4drs6z98kfmn2anhqf8uhy8


Thanks.


If I understand correctly, you want Keychat to support importing nsec, which would increase the complexity of Keychat. We will consider this issue once Keychat reaches a stable version. We recommend not using the same ID for Damus and Keychat.


If you check the NIP-4 GitHub page now, you will see "deprecated in favor of NIP-17."

So, let's analyze the kind-17 using the following thought framework.

Kind-17 separates the sending address from the ID, making the sending address random and hiding the sender's real ID, thereby improving metadata privacy.

https://github.com/nostr-protocol/nips/blob/master/04.md

https://github.com/nostr-protocol/nips/blob/master/17.md nostr:note1zkkxvfetp5entw9aq3s3jn2e0s5p3kurz0zudprz8ygtaagek64shahcv2


OK, let’s continue.

kind1059(kind13(kind14)) VS kind1059(kind1)

In the kind1059(kind13(kind14)) model, if the recipient discloses the encryption key, not only will the sender's messages be visible to everyone, but the recipient's own messages will also be visible to everyone. This is disadvantageous for the recipient and advantageous for the sender. In the kind1059(kind1) model, if the sender discloses the unencrypted kind1, everyone can see the messages sent by the sender. However, the sender can also proactively disclose the messages previously sent by the recipient. Furthermore, the sender can identify who disclosed the messages, which is a good thing. In both cases, the sender can determine who disclosed the messages.

Finally, regarding the issue of app bugs causing kind14 leaks, it would require extremely poor code quality for this to happen. If you must consider this risk, why not directly encrypt the content using NIP-44? Using kind4(kind4) would be simpler than kind1059(kind13(kind14)). Please note that the kind4 mentioned here uses NIP-44 encryption, not NIP-4 encryption.


Thank you for your understanding.


It's hard to believe for us.


Thanks


Hi, Keychat's current notifications require Google Play services.


The current version of Keychat uses a seed phrase instead of nsec. This has caused a lot of controversy, with many people believing that Keychat does not understand the spirit of Nostr: having a single Nostr ID that is universally used across all Nostr apps.

In fact, the first version of Keychat used nsec. Later, we intentionally switched to seed phrases. Why?

Just like when we use Bitcoin wallets, we now more often use seed phrases rather than private keys. Using a seed phrase is an improvement in user experience. Moreover, NIP-6 defines the basic key derivation from mnemonic seed phrases. A single seed phrase can derive countless Nostr IDs.

Using a single Nostr ID across various Nostr apps focused on public notes is reasonable because users are sending public messages, and they can better accumulate reputation.

However, for Nostr apps focused on private notes, users should use multiple IDs to achieve better privacy. For example, you could use ID1 for close friends and ID2 for work colleagues. Current chat applications provided by internet giants do not encourage users to use multiple IDs simultaneously because multiple IDs affect data mining, reducing the accuracy of user profiling and, consequently, advertising revenue. In this context, using only one ID is a bug, not a feature.

If you use your Damus ID to chat with others on a Nostr app that focuses on private messaging, do you want all those people to see the public notes you have posted?

A seed phrase that is universally applicable to all Nostr apps allows users to choose which ID to use in a particular app, with the ID generated from the seed phrase. This is far better than using a single Nostr ID across all Nostr apps.

Don't forget, there are not only Nostr apps focused on public notes but also those focused on private notes.

A reasonable chat app allows users to use multiple IDs simultaneously, whereas a microblogging app’s DM often has only one ID. This is just one of the differences between the two. When we say, "Designing a DM for a microblogging app is not the same as designing a chat app," we are not playing with words; we are not that bored.


The biggest difference is that Keychat's one-on-one chats have forward secrecy, meaning that if your key file is compromised, hackers cannot decrypt your past or future messages. In contrast, 0xchat's default message encryption (Gift-Wrapped DM) does not have forward secrecy.

“0xchat Secure DM

Currently, we support three types of direct messages (DMs), Please review the provided links for a deeper understanding of each DM type:

NIP-04 DM
NIP-04 DM is the most widely used DM type in nostr, but it is not our recommended option currently because NIP-04 is not private in terms of DMs. Even though the content is encrypted, it leaks a lot of metadata. We do not use this DM type by default but are compatible with NIP-04 DM from other nostr clients.

Gift-Wrapped DM
Gift-Wrapped DM is our default and recommended DM type. By using Gift-Wrapped for event messages, it minimizes metadata leakage. Not only is the message content encrypted, but the sender and the timestamp are also concealed. Moreover, the encryption algorithm employed is the latest audited NIP-44 algorithm.

Secret DM
Secret Chat is our third DM type, an extension of the Gift-Wrapped DM. Since Gift-Wrapped DM does not support forward secrecy, if a user's private key is compromised, all DM messages could be recovered. Therefore, we added a NIP-101 key exchange protocol to ensure each message session uses a different receiver key, securing forward secrecy. Additionally, we have incorporated the option to select a fixed relay for these sessions, allowing messages to be transmitted through a single trusted relay for both parties.”

https://github.com/0xchat-app


Thank you for your response. What do you think about our concerns regarding NIP-17? 👇

nostr:note1fy2yam6h0cm628rjlyzra06t5azxuru0q88hegjxtpz5uwstztnqmy0csl


Additionally, many people are paying for so-called free chat apps with their private data. There's no such thing as a free lunch in the long run.


Yes, of course.


The scenario you envision is that a user does not receive messages without stamps, but the messages they send also do not have stamps? Keychat can control relays more precisely. For example, users can separately set the sending relay and the receiving relay. They can set the receiving relay to a paid relay and the sending relay to a free relay. Of course, this also requires the consent of your chat partner.


Users just need to disable the free relay on the settings page, and they will not receive messages without stamps.


Statistics show that, on average, a person sends 50 messages per day, requiring 50 sats. Currently, one cent can buy 16 sats, so it costs 3 cents per day, and 90 cents per month. Another point is that each message in Keychat is independent, so it is not possible to block someone.


1、yes, of course.  see below note.

nostr:note15sza0s4yrxzx35cn3cs5xarxd48h7tgc5eyy4x0ml98jqfrk92gswyvhc8

2、 see below note

nostr:note186wfn3zdrds9g3k2rgqxtzxxr3azfzr3vz6aa68c52kns7wqpduspmk2hh

3、yes, two kinds of group.

nostr:note1927pnd00l22umju9xldyjc3xsrhn28tk0rxczn50pygwaft5h8kqcex9y9


I frankly like a lot nostr:nprofile1qqsth7fr42fyvpjl3rzqclvm7cwves8l8l8lqedgevhlfnamvgyg78spz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3qamnwvaz7tmwdaehgu3wwa5kuegpz4mhxue69uhk2er9dchxummnw3ezumrpdejqj9swg4 and I have a lot of hope in it. For the estamp I think it is a clever idea and it will be applied to other things, like public notes and data-blobs.
Another thing I expect is that the estamp-to-message feature will be useful to give some sort of priority to our important chats and messages but that the not-so-important messages will flow mostly free across relays, like most of interactions with notes on nostr arent economic transactions.


Designing a DM for a microblogging app is not the same as designing a chat app. nostr:note1s9ea86fp9llg5dmpfzg5sp8ywlcxjuzleanlhkd8pasj6varavqq84na9g


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


Under that post, I discussed extensively with one of the contributors to NIP-17, who is also a developer of 0xchat. You should be able to see the results of our discussion.


Keychat's goal is not to serve as a DM for a microblogging app; it is focused on being a chat application. DMs and chat apps are different; DMs are designed to serve microblogging platforms.


Designing a Nostr app focused on public notes is different from designing one focused on private notes. nostr:note1hhjryxvpfq959yg4w8ejn2e0vzhlntpxy76nw7577z96n97e0q9qydemzq


You should directly address our concerns about NIP-17, rather than assuming we are deliberately not complying with NIP.

nostr:note1fy2yam6h0cm628rjlyzra06t5azxuru0q88hegjxtpz5uwstztnqmy0csl


Please wait a little longer, as the current version does not yet support importing seed phrases. This will be supported in future updates. It is still an early version.


Keychat has implemented a seed phrase using NIP-6.

For applications focused on public notes, such as Damus, it is more beneficial for a user to use a single Nostr ID because it can accumulate more reputation. However, for apps focused on private notes like Keychat, using multiple IDs can provide better metadata privacy. A seed phrase allows users to have multiple IDs while only needing to save one seed phrase.

Another point is that the double ratchet algorithm used in the Signal protocol is stateful and cannot be used on multiple devices with the same ID simultaneously. The double ratchet algorithm provides enhanced encryption security but sacrifices some multi-device synchronization capabilities. This is an issue that apps focused on public notes do not encounter.

https://github.com/nostr-protocol/nips/blob/master/06.md


Keychat uses a seed phrase instead of an nsec. Later, users only need to save one seed phrase to have multiple IDs. At the same time, this seed phrase also serves as the user's cashu wallet seed phrase. https://image.nostr.build/e331e408b251c5c29ed40fdcc913cbe05db5e025c38b502ea2cc249a15a254ed.jpg


If you only have three minutes to learn about Keychat, there is no better resource than this brief introduction of just over a hundred words. nostr:note16gv0dfkfaj2cvyujxlk9thckm4vy63r9vl0hpcn9473flca9qqqscm583q


Thanks!


The QR code contains a Nostr ID Key, three Signal-related keys, and some digital signatures. nostr:note13hkk5cx082fmsasas0f4e47xxtuqqgkv457fsk3epnn343an7lkq2u6jwq


The current version is still unstable, and there are incompatible updates forthcoming. The current version is suitable for users who are eager to try new things. Waiting for a more stable version before adding it to the store would be more appropriate.


Nos.lol has recently added PoW; you can remove it. We will support more mint-issued ecash sats as stamps in the future. I will send you some sats via Damus DM.


Keychat does not support the proof of work (PoW) feature, so it cannot use the nos.lol relay. Do you have a cashu sat balance of 8333 mint?


We will consider adding the functionality to import existing npub private keys in the future. Currently, Keychat uses a seed phrase instead of nsec. However, we still recommend using different IDs for chat applications and microblogging applications.


Long press the message you sent, then select "raw data." https://image.nostr.build/3d42e62766ac18be2d1f25e794c4a667d60c53316bcfb3ecb824f48b3c5e8647.jpg


Cashu sat is the best estamp.

Stamps are made of paper, and so are envelopes, which makes it convenient for stamps to be attached to envelopes.

cashu sat is a piece of data, and the encrypted message is also a piece of data; the two can easily be combined together. nostr:note1m0pm0n73wf7nllwah0jwrs3q3wepasve5h64t6tdx5ttkmv6h8dsal2aez


Cashu sat used as a note stamp is a universal solution that all Nostr applications can utilize.

It can also be used for public notes, not just limited to private notes.


If you are running a Nostr relay and would like to test the stamp collection feature, please check our GitHub at https://github.com/keychat-io. nostr:note1jml0uxh2fwhdyuh997j0fux454t9ya7s30yw40fn38rvayvs80qq9458pm


Hello, can you receive the DM I sent? I used Damus to send it.


Currently, Damus relay addresses spam issues by limiting the frequency of posting notes, while nos.lol uses proof of work to tackle spam.

Keychat relay uses "stamps" to solve spam problems and generate revenue.

If a user has a cashu sat balance, Keychat automatically attaches a stamp, which is 1 sat, to messages sent by the user.

The stamp is affixed to the event, and the relay is the first to receive the event. The relay then copies the cashu sat, accepts it, and forwards the message. nostr:note15sza0s4yrxzx35cn3cs5xarxd48h7tgc5eyy4x0ml98jqfrk92gswyvhc8


Users post their cashu sat in the event, and the relay is the first to receive the event. The relay copies the cashu sat, then receives it, and then forwards the message.


Cashu sat used as message stamp.


We agree with your statement. This is our first time delving deep into NIP-17, so we initially posted an explanation of our views on NIP-17.


Users can choose which relay to use, as long as their conversation partner agrees to use the same one.


Cashu sat as message stamp.

Ecash—>Estamp


Cashu sat as message stamp.

Ecash—>Estamp nostr:note15sza0s4yrxzx35cn3cs5xarxd48h7tgc5eyy4x0ml98jqfrk92gswyvhc8


These are our concerns regarding NIP-17. We are not sure whether to modify NIP-17 together or if our concerns are misplaced.

nostr:note1fy2yam6h0cm628rjlyzra06t5azxuru0q88hegjxtpz5uwstztnqmy0csl


Multiple IDs on the same device cannot add each other as friends due to some limitations of the double ratchet algorithm.


The current version of Keychat supports creating multiple IDs, but each ID is generated from a different seed phrase.

We have listened to user feedback, and in the future, we will enable generating multiple IDs from a single seed phrase. Therefore, if you are currently trying to create multiple IDs, consider that IDs beyond the first one may no longer be supported in a future version.

By the way, the seed phrase for your ID is also the seed phrase for your cashu sat. nostr:note1wwncj374ddd2nw2tfqugct2hrwqmje5mpllch9dy0pd2tstfut5q5ym6ck


Thanks for testing.

Please note, this is still in the early stages. We will later make an incompatible upgrade to the shared key group, replacing NIP-4 with NIP-17 or a modified version of NIP-17. nostr:note124e9zffvqjg0uzpc97leses8fgzfk669j8px0m72rpza5eecd9uqa8xdrx


Keychat use seed phrase, not nsec.


When you want a friend to add you on Keychat, you have two options: tell them your QR code or your Npub. We recommend using the QR code because once someone knows your QR code, they can send you messages encrypted with Signal directly, and the QR code is only valid for 24 hours. If you use your Npub, after someone knows your Npub, the first message can only be encrypted with NIP4 or NIP17. Only after they reply can messages be encrypted with Signal.


FYI, the Keychat QR code has a validity period of 24 hours, which is a privacy protection feature we designed.


If you use Keychat to send a message to a non-Keychat user, the first message is a friend request, and this message is end-to-end encrypted. Keychat does not support sending messages in plaintext.


The new version of Keychat, v1.15.6, is now available for download.

This update resolves the bug where the cashu balance does not display immediately after minting.

Please upgrade to the new version.

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

Because we have reservations about NIP-17, this version has not yet adopted NIP-17 in place of NIP-4. nostr:note17hdpm290vkwnpxthlkxx74r3dmhvfm3cq2smgy6ufkg469tku98s397m9x


What do you think of our opinion on NIP-17? nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:note1fy2yam6h0cm628rjlyzra06t5azxuru0q88hegjxtpz5uwstztnqmy0csl


The recipient can calculate the encryption key for kind13 using their own private key and the sender's public key.

They only need to disclose this encryption key, not their own private key, to prove that the message was written by the sender, right?

I'm not a cryptography expert, so I'm not 100% certain.


However, the sender has signed with their private key in kind13. Therefore, the recipient can step by step prove to the public that the message was written by the sender.

"Not your sig, not your event. This is how Nostr works." I don't understand what you mean by this. https://image.nostr.build/ef4f50793e286a501390fcdb7f8c7f9ffa4d6fbb34ac7c4d3f25de0b7a370248.jpg


If the recipient of the message or someone else maliciously publicizes the sender's message, even the kind1059(kind13(kind14)) structure cannot prevent it. This is because they could write a post step by step proving that kind14 was written by the sender.


“A rumor is a regular nostr event, but is not signed. This means that if it is leaked, it cannot be verified.”

In what scenarios would only the innermost event be disclosed?


Since we are considering using NIP-17, we delved deeper into it. So, let's revisit your question, "What do you think of NIP-17?"

NIP17 defines a message structure as kind1059(kind13(kind14)). We are puzzled as to why it is necessary to apply NIP44 encryption twice.

Kind13 (seal) is responsible for digitally signing and encrypting the message. Since kind1059 has already encrypted the message, there is no need for kind13 to encrypt it again. Therefore, the only role left for kind13 is digital signing. We wonder why the digital signature cannot be directly incorporated into kind14. A digitally signed kind14 would effectively be equivalent to kind1. Hence, we believe that kind1059(kind1) would be a simpler implementation.

Moreover, changing the timestamp of kind1059 messages to a random time from the past two days could lead to relays repeatedly pushing notes to clients, potentially burdening both clients and relays. We are uncertain if this tradeoff is justified.

https://github.com/nostr-protocol/nips/blob/master/17.md https://image.nostr.build/3adb9c871474866d80651ba8c12e3c18311d231a81fb91e70289c7a674e2d822.jpg https://image.nostr.build/efd502001675422031621d3fdfcf1a5a314355fc82c82b22b992f1e6f992c060.jpg


Sorry for the inconvenience. In the next version, we will optimize the balance display.


Yes


Please restart the app, and you should be able to see the balance.


Sorry for the bug. We are investigating the issue. We will get back to you later.


The new version of Keychat, v1.15.4, is now available for download.

The update simplifies the friend-adding process, making it incompatible with the previous version.

Please upgrade to the new version.

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

In the next version, we will replace nip-4 with nip-17. nostr:note1hg4mkfq2ujgf0g8rh3wjj0nlmskfxrd0lraqngfpnxzlshhdzp0qkksr6q


Sorry for the bug. We have released a new version, please download it. We will re-add you as a friend using a different ID. Thank you for your testing.

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


Keychat relay will support more ecash sats issued by other mints as stamps in the future.

BTW, the 8333 mint is not operated by us; it is the earliest Cashu mint, so we have been using it consistently.


If the user doesn't have ecash sat, the message will only be sent through the free relay.

Long press the message you sent and select raw data. https://image.nostr.build/3a8c419b8005f272aeefb939515d5f72a615f81fa75a68daa9237c60ae266942.jpg


👍

Add the following account as a friend.

nostr:npub17a6fz2j9h8kekhsahqzjr0tg5uawh9u3p4zg0mw9jz95tfq3ujxq7a7x39


Keychat use seed phrase model not private key.


Sorry. Please delete that chat room. Then add me through this npub :

nostr:npub17a6fz2j9h8kekhsahqzjr0tg5uawh9u3p4zg0mw9jz95tfq3ujxq7a7x39


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

nostr:note1f6vw6cvnp0mt4s3nwakahffwf3qvh4z49kvt93l9gmqy9jpwd2ksfggmq6


Now


Finally, we are confident enough to invite interested users to test Keychat.

Keychat code: https://github.com/keychat-io

Keychat Android apk: https://github.com/keychat-io/keychat-app/releases

This version inevitably still has many bugs, which we will continuously fix. We will also modify any designs that are not reasonable. Thank you for helping to test this early-stage application.

For now, do not store too many sat(<200 sat, about 13 cents) in Keychat.
If you need some ecash sat to test the postage feature, please add 👇.


Keychat is built on the shoulders of giants: Nostr protocol, Cashu protocol, and Signal protocol.

Thanks, giants! nostr:note16gv0dfkfaj2cvyujxlk9thckm4vy63r9vl0hpcn9473flca9qqqscm583q


>Notice that so far you haven't even given a hint of what you're doing, just marketing claims of some wonder tech that is soon to be here.

This is not a fair assessment. So far, we have posted many notes explaining how Keychat is designed. Because the design of Keychat is very simple and intuitive, even users without a technical background can understand it.


DM (a subsidiary feature of microblogging) and chat apps (primarily focused on chatting) are not exactly the same, and they face different tradeoffs. A chat app needs to consider end-to-end encryption with both forward and backward secrecy, as well as the ability to conceal the IDs of both the sender and the recipient.


In terms of metadata privacy, NIP-17 is better than NIP-4. NIP-17 provides better protection for the sender's ID, but it does not sufficiently protect the recipient's ID. The visibility of someone continuously receiving messages is also a metadata privacy issue. For a DM (a feature subsidiary to microblogging), this might be an acceptable tradeoff, as users can receive and decrypt messages on multiple clients. However, for an application using Nostr for a chat app, privacy should be a priority.


By the way, we don't intend to make Keychat a closed application.

Users have the option to choose which relay to use and which Cashu mint to use.

After the code is open-sourced, we will write a NIP so that everyone can develop applications that are compatible with Keychat.

We want Keychat to become a chat browser. nostr:note13lum703ckzrcuel0ajy36m88gmw0s0cz9sua3njlfwxf0lajmgvs6j55xx


Our approach is code first, NIP second.

We do not aim to limit users to only one choice.


More user-friendly


We are considering trying out "pay to chat."

Imagine you created a special ID solely for chatting with bots. You add an AI bot as a friend on Keychat, and it first informs you that asking a question costs 2 sats. If you agree to this price, every message you send to the AI bot will automatically include 2 sats (Cashu token). The AI bot collects the sats and then returns an answer to you.

No registration, no subscription. Pay per use anonymously.

Anyone can run such an AI bot, and it can be various types of bots.

Think of it as chat bot as a service. nostr:note1lwxandhd9m3ha3l0g96jnfkrur226fxrp756w3d82cpcnpujjygqmyem58


By the way, we will open source Keychat and release the Android APK this week, if nothing unexpected occurs.


No.

Please check this note 👋

nostr:note18ef8r2naprhyv956syrjyaapc3pqngef7n6ax36ku7g8djfesltqhx6m8s


Yes, we understand that. However, at present, NIP4 is supported by more relays. We will try using NIP4 first, and later we will consider switching to NIP17.


Very cool and interesting project - privacy conscious messaging app using nostr, signal protocol and ecash in a novel configuration https://www.keychat.io/


This week.


Perhaps users should consider posting to the relay as renting a billboard for display, with the user deciding whether to continue paying for the display.

It is essential to save the note locally, as the relay is merely a display medium. nostr:note1klzd09tqmmprc862r2vr6sl6z7n8kc65jwppy5yu02dy36us7ytq62fulw


Without secure hardware, software security is unattainable.


Exactly, spammers are more skilled at pow than ordinary people.


Yes, that's exactly what Keychat is doing.


Use ecash sat as a stamp for notes.


👍

Use ecash sat as a stamp for notes.


Compared to the PoW solution, the stamp solution not only solves the spam problem but also generates income for relays.

This allows relays to operate sustainably. nostr:note1dlll08xzrygdw9jhw3gql24mgsh79ncq3d45e0fmklcy007257hs0hchux


One major difference between email and mail is that email doesn’t use a stamp, while mail uses a stamp. nostr:note1dlll08xzrygdw9jhw3gql24mgsh79ncq3d45e0fmklcy007257hs0hchux


Use ecash sat as a stamp for notes. nostr:note1fhyd5wajc53pk2892fssv28rj5jg6skky702n02ca8xyu3tssl5s656fph


Keychat uses the Signal Protocol's Double Ratchet algorithm to implement end-to-end encryption, giving it forward secrecy capabilities.

nostr:note1zgmh2rsf9pju3wkltevwm7mu0wxfq2hp0hyw3kdmp7ztrgyk52gsmmv5j8


A common misconception in the Nostr community is that Nostr is not suitable for private things. nostr:note1qrmcntn00ss0tkdvqh6r26m8j543wpczhz7dv0q985mh92dlgjespnfrju


We can create a better end-to-end encrypted chat app on Nostr than Signal.

You might be interested in Keychat.👇

nostr:note16gv0dfkfaj2cvyujxlk9thckm4vy63r9vl0hpcn9473flca9qqqscm583q


Npub.pro brings a space-based structure to Nostr.

Thanks nostr:npub1xdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wscmntxy  nostr:npub1pr4du5xl28dy5sh4msz9uddnwxgzupkk4qzjzklv84edc6ruevzqlxmkzp

The Keychat website on Npub.pro is:

https://keychat.npub.pro/ nostr:note1draa8zsly7d7jmdsgz3taytul8hxadczuydrlkt2lhhezj6mzshsvwkq7p


The privacy leakage of metadata in encrypted messaging can be divided into two levels: application level and network level.

At the application level, using registered accounts as addresses makes it easy for server to know who is messaging whom. A better practice would be to use different and updated sending and receiving addresses for each message.

At the network level, metadata privacy is compromised when the user's client connects to the server, as the server can identify the user's IP address. Network level issues can only be solved at the network level. MASQUE Proxy holds great promise for addressing network level metadata privacy issues. nostr:note1qz744fvm5am30kq9075rjhyj46kfpy2f9lcm6kr5g6w8up7xuhnq0mfhts


Yeah, the stamp mode can be used for all nostr notes, whether they are public or private notes.


The Cashu protocol will support currency units smaller than 1 sat, such as 0.01 sat.

nostr:note1exjy7radjlfy8lhk8ulqk08p5fcvjll85yl706s5jt6zwvqjgw9se7dzcx


Maybe spending 90 cents a month shouldn't be too expensive?

nostr:note1pshpwanp7xy6whxxvxzdehl3dgsm24p5zl7t9szt6cjvxv6nxkuslusz32


You might have misunderstood. I meant that ecash sat can be used as a postage stamp.

Relays receiving the stamp can verify it is a real sat by redeeming the ecash stamp at the mint for LN sat, and then forward the message. https://image.nostr.build/a3d47fbbbca8b074b3bab8899e77947f6eb2c0d8f088e2c729103d5b05c9ecf3.jpg


Check this note

nostr:note1lnlj2q0p72svwjtgcj2ruacr6hpqg4u73l95sy5e422d2pyl32jq3geuem


“Ecash is the purest/leanest form of money as data. It can probably not get any leaner than just a text string.”

So Ecash sat can be used as a stamp. Centralized wallet sats are just database records and cannot be used as stamps.


Maybe we should write an NIP-1840: using cashu sat as a note stamp.

The first stamp was issued in 1840.

https://en.m.wikipedia.org/wiki/Penny_Black


Phoenix and Breez are my most frequently used Lightning Network wallets. Today, I started using Phoenix's BOLT-12 feature.

We're not sure if we need to integrate an LN wallet into Keychat. Would you like having an LN wallet integrated into Keychat?


Ecash sat can be used as a stamp for messages.

nostr:note10zauld0jwk0dd6h7ff60ykha6axknhhgdnt2gg82lx2fmkg89awqkrt7nm


The MASQUE Proxy should be the final piece in the protection of metadata privacy at the network level.

https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque-proxy.html nostr:note12efx0sark9qhdnstu7ucacv399j60juz3ukjvzztvpzg2avtnr0qd5ceua


Just like how we used to check if we had our keys and wallet before leaving the house, Keychat is the keys and wallet of our online world.


If the sender is a Keychat user and the recipient only accepts LN sats, the sender can choose to send LN sats directly on Keychat.


On Keychat, after you receive ecash, you can send it to your own Lightning Network wallet.

nostr:note1gjk6wmdq7puay5uk7pqkxvg5cwdcln6vmdk4ef4lfvlljh0h2t3sflu75u


👍

Perhaps we can now design a new internet application. nostr:note10f0c8jnmv7xtqrqmtrw3s3xpepazzu4t6h7l6k7j73fr7mq6vnkq2lymwk


The ThreadChat mode in Damus is quite interesting.

We have envisioned a ChatThread mode for Keychat group chats to make discussions more focused. nostr:note1w3ctfexy997fl5j56j5xwd0lv66sdjpcduram5f6vj4ftgxyg6kq4qudt6


From the perspective of user control, having a Nostr public key and publishing notes on several relays is akin to owning several personal websites. The relays function more like cloud servers.

This is entirely different from registering an account on a social media platform.

The Nostr public key is the core entity, while the relays are the medium. nostr:note1xyrgrk3tekwax873xvepjjdm4jlhy7v4k6rkzmv7pfsmwkusj6ps3qurqm


Nostr is superior to the Web in many ways, such as having public keys and digital signatures. However, Nostr lacks the space-based structure, and users only receive information through time-based feed.

“The space-based web we currently have will gradually be replaced by a time-based worldstream.

This lifestream -- a heterogeneous, content-searchable, real-time messaging stream -- arrived in the form of blog posts and RSS feeds, Twitter and other chatstreams, and Facebook walls and timelines.”

We need space-based structure and search on Nostr.

https://www.wired.com/2013/02/the-end-of-the-web-computers-and-search-as-we-know-it/


We consider Keychat as a chat browser also because, just like anyone can create a website, anyone can create a chat bot, such as an AI bot or an RSS bot. All Keychat users can choose an ID to add bots as friends, pay per use with ecash sat for bot services, without the need for registration.

Ecash sat prevents spam and allows bot creators to earn income, moving away from the traditional reliance on advertising revenue like websites. nostr:note1d09njd8cs995m5zhev6l247uaq9vgrlnvv94vlrz0xa05xcywsvs8afpee


Yes, ecash sat is used as a stamp for messages, paid to the relay. Just like stamps and the post office.


https://signal.org/blog/pdfs/upload-moderation.pdf https://image.nostr.build/7738fa5b64262cfe23ee65c6043f163b270a0a33e7219720ec414ea4477a673f.jpg


You can take a look at Keychat's solution; it reuses the Signal protocol.

nostr:note16gv0dfkfaj2cvyujxlk9thckm4vy63r9vl0hpcn9473flca9qqqscm583q


The diagram illustrating how Nostr works also uses metaphors like post office and letter. Isn’t it just missing a small stamp?

https://github.com/nostr-protocol/nostr https://image.nostr.build/d19bcfa5ebedf58ed5eea8841e8945ee54555d941c6bcc4ee6ca87453af26784.jpg


Ancient letters are a remarkable invention, as they contain both information (the message) and value (the stamp). In contrast, modern emails and messengers only contain information, lacking value. Service providers can't solve the spam problem and must rely on registration systems. Letters, using stamps, solved this problem more elegantly without the need for registration. nostr:note16gv0dfkfaj2cvyujxlk9thckm4vy63r9vl0hpcn9473flca9qqqscm583q


The Lightning Network is the bridge between ecash mints.

If you want to swap ecash from Mint A to Mint B, you need to go through the bridge.

👇 https://video.nostr.build/b55f3b4f1663c215d488cb4a469621f7cf127aff7c4f35ea69892e7cd068a9b8.mp4


If you think Nostr’s user growth is too slow, take a look at this book. Web protocols also experienced the ‘gradually, then suddenly’ process.

https://www.w3.org/People/Berners-Lee/Weaving/Overview.html

https://www.goodreads.com/book/show/1308515


The current Nostr DM (NIP4)  integrates four capabilities into a single Nostr key—it serves as an ID, an encryption key, a receiving address, and a sending address.

In Keychat, the ID, encryption key, receiving address, sending address are separated, allowing the encryption key , the receiving and sending addresses to be updated continually. This achieves better encryption security (forward secrecy and backward secrecy) and metadata privacy.


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.


Keychat is a chat browser, in a sense.

Web browser can access all web servers. Keychat can access all Nostr relay.

In a web browser, there are many tabs arranged from left to right, each linked to a different web server. In Keychat, there are many chat tabs (or chat rooms) arranged from top to bottom, each connected to a different Nostr relay.


In the offline world, we clearly understand that IDs and addresses are not the same thing. However, in the online world, we often take it for granted that IDs and addresses are the same. It's really strange 🤔 nostr:note1lw2ffea5pecnjfqfk3n25uhm6wc23vasga8urckhdtngzn7pk0tsctrykr


We use the postal system analogy to explain this to new users. https://image.nostr.build/a3d47fbbbca8b074b3bab8899e77947f6eb2c0d8f088e2c729103d5b05c9ecf3.jpg


It is very easy to understand that IDs and addresses are different; think of letters.

Current chat applications use IDs as addresses because it is their solution to spam. However, if every message has an ecash sat stamp, there would be no spam problem.


To help users understand this design, tell them that the ID and address are different and that a fixed ID should not be used as a message address. The address should be updated continuously. nostr:note1yapwf0mlgfmrelcunfz7xn7l5x37yj60k53e3jkm5dgqgh8e3upql6wndd


Keychat's messages only use the kind 4 format, with encryption and decryption done using the double ratchet algorithm.


Additionally, we believe NIP-4 is the simplest and should not be discarded outright. It can complement other NIPs.


This should be a legacy issue because kind 4 was the earliest DM solution, and most clients and relays support it. We can change it later.


Users can choose which Nostr relay to use, as long as the relay supports NIP-4. https://image.nostr.build/f7753474119e394c7e2d7bc26d3e4124f07bd11c36550bb29bd8eebc0654de54.jpg


Yeah.

In extreme cases, Keychat can achieve the following:

changing the encryption key for each message,
changing the sending address for each message,
changing the receiving address for each message,
changing the sending relay for each message,
changing the receiving relay for each message.


Keychat reuses Signal protocol to update sending and receiving addresses for nearly every message.


I think so.

nostr:note1zkkxvfetp5entw9aq3s3jn2e0s5p3kurz0zudprz8ygtaagek64shahcv2 https://image.nostr.build/dccce14a1367cbba0f964302aa1d293c23d40cc543251527bf7451b6e80c4647.jpg


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.


This article is great: https://www.axiombtc.capital/stack. It would be even better if it included ecash.


We have essentially completed the development of features, are continuously testing and fixing identified issues, and are organizing the code. It should take a few more weeks.


Keychat follows this stack: BTC/LN/NOSTR/CASHU.👇 nostr:note186snmcumexm3q2a80qt9zqnwx8jrkz2u7yh0x2x3vuz9n44a8hmqthgsah


We will consider adding translations for other languages later on. Android versions from the past five years should all be supported.


We have redesigned the actions on the ecash wallet page.

Users will have a clearer understanding that they can use the ecash wallet to make Lightning Network transfers (previously known as melt action), and they can use the ecash wallet to receive Lightning Network transfers (previously known as mint action). https://image.nostr.build/7a656c73123cb9c86fff8a0308f9f75e2b34a7a00b9e677c349b3ea4f5af59eb.jpg https://image.nostr.build/cda394cc8e274f71af92106d52b2567370e7cc838d4e833af822e02bb7447b36.jpg https://image.nostr.build/66865355abd4c7808b46006d3722f45d5d3e3a1aaa7bb911e6394484ee448619.jpg


There are already hundreds of chat applications, so why are you making another one?

Because we are not satisfied with them. We want to make a better one. That's our starting point.


Yes, users don't need to know the details of various keys. This is our engineering version; the official release will omit these details.


Indeed, this term has been tainted. We are also hesitant.


The following screen recording demonstrates how a new user uses Keychat. https://video.nostr.build/3197c0a7dd9d539426fc3bd48a19b8192cf9d6e48875f3c8fbb36dc167f68d4a.mp4


Keychat is a very open chat application that makes no distinction between humans and bots; both are just public keys.

Developers can easily create an AI bot on Keychat, charging users ecash sats on a pay-per-use basis. Users can add the AI bot as a friend and start chatting and asking questions.

Conversational as a Service.

nostr:note1evydzwkym5n66rxz98fudc78dvnwqcmaqmrtseu8zfpneukjandqff2aps

nostr:note1d09njd8cs995m5zhev6l247uaq9vgrlnvv94vlrz0xa05xcywsvs8afpee


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


Yes.


Maybe the client should also allow users to save reposted or saved notes locally.

Just like a paper book is harder to delete once sold compared to online content that relies only on servers.

Anti-censorship should not rely solely on the relay; the client design should also take this into consideration. nostr:note1klzd09tqmmprc862r2vr6sl6z7n8kc65jwppy5yu02dy36us7ytq62fulw


Relay model.


In the previous version of the Keet website, it was mentioned that members of a room should stay online as much as possible, and offline members could sync messages from the always-online members when they come back online. This information has now been removed from the current website.

If the node hosts the data and the client downloads from the node, I'm not sure if this is a standard P2P network, at least not like the Bitcoin P2P network.


Thanks!

We believe that stamping messages is a more reasonable solution. https://image.nostr.build/a3d47fbbbca8b074b3bab8899e77947f6eb2c0d8f088e2c729103d5b05c9ecf3.jpg


The web architecture is also a relay mode where web servers do not communicate with each other. nostr:note1063mar49nu5edjcr8zqlgjs8zl3dlve5p74twv43sv3s9ztaykhq38vv7w


“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

We believe that the messenger in relay mode is superior to the messenger in federation mode and centralized mode.

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


Users should have a reasonable expectation of how long their notes will be stored by the relay, rather than expecting permanent storage.


Users should keep a local copy of their public notes.

For example, by paying 5 sats, a relay would commit to storing it for one year. If after one year, the user deems the note to be very valuable, they can resend it, essentially renewing it. Notes that the user considers not valuable do not need to be resent. nostr:note1sz3dl303ttzhlef8fuyhsyhjh8e288ghzsjhsd9ldq55g7qqnjwq7zghft


It won't be much longer, just a few more weeks.


Very easy 👇

nostr:note19kjj5dx2wk94gf7ahjzr6caf3lmuws0kkezrw2m3k8xuydu0z8qszmej37


When a user accumulates 8000 ecash sats（about 5 dollar), they can easily use Breez app to generate a self-custodial Lightning Network wallet.

It couldn't be simpler. https://image.nostr.build/aa56156c49cb2dd417541e5e9d924c0931fec97fe0589c575236b90f08b82e83.jpg https://image.nostr.build/9eef31e9e2de60a861c9feb3ec5e86abf33204b98156f9ec48c4570a43c97876.jpg  nostr:note1cp60u4kwglcr9f3phnfyn05akr7saw68rzkj5euyj6r9e85dsalqaaa8xt


If CashApp can generate an LN invoice, this feature can be used.


For current Bitcoin holders, we first possess on-chain sats, then convert a small portion of those into Lightning Network sats, and subsequently turn a small portion of the Lightning Network sats into ecash sats.

For new users who are not yet Bitcoin holders, they might first acquire ecash sats. Once they accumulate enough, they can have self-custodial Lightning Network sats, and as the amount grows further, they can then own their own on-chain sats.

The order of acquiring sats is potentially reversed for new users compared to existing Bitcoin holders. nostr:note1wet48xvad8uwx0zhuf05lamcmfnxt7dmqhlpaxhakmmr2vqfpj7s92ylgl


When we use credit cards, the bank provides credit to us.

When we use ecash, we provide credit to the mint.

Be cautious with providing credit.


Relay economy is the cornerstone of the creator economy. We need to first perfect the relay economy, ensuring that creators' works can be permanently stored by the relays and can be accessed and viewed. nostr:note1sz3dl303ttzhlef8fuyhsyhjh8e288ghzsjhsd9ldq55g7qqnjwq7zghft


Keychat's relay charges using the stamp model, perhaps Damus's relay should charge using a rental model. nostr:note1lker8z3448fp3gl5qaz4epsx7xttgnv3jenkh890nzcelc0eh23qpdcgnd


Hold on a little longer, we are still working on the development.


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


Running a relay for an app that sends public notes (such as Damus) is much more challenging than for an app that sends private notes (such as Keychat).

When a Keychat message recipient receives a message, the relay can delete the encrypted message, or at most store it for one month, resulting in minimal storage pressure.

However, a public note is intended to be stored for a long time so that future readers can access and read it, which significantly increases the storage burden on the relay. nostr:note14dl82tu7tgxve3fnsalg8kj4rvc595zl4udgmv5guh0netmkmm3qql9ec0


We are quite conservative about the member limit for the shared key group.

Currently, the member list is kept locally and is not uploaded to the relay, which significantly limits the maximum number of group members. https://image.nostr.build/df1b73937bb1f7fb09d106ebb928b75cd5f3efe4c6a7787d38fefd8742745585.jpg  nostr:note108utxkh59shwu4gueffy2pk24u4ktqcg3reczvd6rpe8luupu0ksmp6tvw


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.


Keychat also supports shared-key groups, where all group members share a public-private key pair. When a member sends a group message, they use this shared public-private key pair to send a Nostr Encrypted Direct Message (NIP4) to this shared public-private key pair. To outsiders, it appears as if they are sending messages to themselves. Other group members receive and decrypt the message using the shared key pair.

When a group member is removed by the group admin, the shared key is updated. The group admin notifies the remaining group members of the new group key by sending them a Nostr DM NIP4 message.

This is an end-to-end encrypted group chat, but it lacks both forward secrecy and backward secrecy. In terms of metadata privacy, outsiders can only see that someone is continually sending messages to themselves.

The overall security of a shared-key group is not as robust as that of a pairwise group. It might be better to consider it as a semi-public or public group.

If the shared-key group has many members, most of whom are strangers, we recommend participating in the shared-key group chat with a new ID, rather than using your primary ID.

Additionally, we are exploring sender key groups and Message Layer Security (MLS).

By the way, the security of all encrypted group chats currently does not match the security of one-on-one chats. nostr:note1927pnd00l22umju9xldyjc3xsrhn28tk0rxczn50pygwaft5h8kqcex9y9


When explaining Nostr to a friend, we start with the public key and gradually rebuild Nostr step-by-step.

**Public Key**

Having a public/private key pair gives you a completely controllable ID, which represents you in the online world.

If you want to publish a public note, you can use your private key to digitally sign the note, proving to readers that it was indeed written by you.

**Relays**

Next, you'll consider how to spread your public notes to others. This requires setting up relay servers, either operated by yourself or others. Then, you send your public notes to multiple relays. This is akin to having a personal website on various relays. Your readers can see your personal webpage on the relay by knowing your public key.

**Follow**

However, asking others to actively open your personal website to see notes might be too demanding. Therefore, it's essential to consider adding a follow mechanism. The client continuously queries the relay to see if any new notes have been posted by the public keys you follow. This creates a continuously updating timeline. nostr:note12fgl8h8jmtjy7rnstm7zyzsl0mfej7663emksc4pygdsv75xqj2swtpuh9


The current mechanism by which Nostr relays respond to Nostr client requests is designed for microblog applications. For example, a client can request a relay to send all notes it has received in the past hour. This is also known as Damus's Universe, where one can see all notes posted by everyone, not limited to those they follow.

Keychat's relay requires the client to specify which receiving addresses it wants to retrieve messages for. Additionally, Keychat continuously updates the receiving addresses, which are known only to the sender and receiver of the message. Combined, these two designs prevent others from accessing encrypted messages from the relay. This achieves better metadata privacy.


This is one of our core insights in designing Keychat. https://image.nostr.build/ec4ebb4c901c21fd2b835e42639110a64b8dc8dfe231189860df101cbfac8824.jpg  nostr:note1zkkxvfetp5entw9aq3s3jn2e0s5p3kurz0zudprz8ygtaagek64shahcv2


Hi, Keychat supports sending pictures and videos. We haven't implemented the overall data migration feature yet, but we will do it later.


We don't want users to have only one ID. For example, when joining a group chat with mostly strangers, we recommend using a new ID. https://image.nostr.build/80fb9d8a5fc43ba86f6c288017b6a09ea1b25d71f7dad58bdda0950b44a7484b.jpg  nostr:note1kgha0g0rt6ywkcx5xzj6s788ycjpwygre7q92szaek5e8g22p85qaatrwc


This feature has been developed.

The seed phrase for the first ID of a Keychat user is also the seed phrase forecash, which can be used to backup ecash, just like the seed phrase of an onchainn wallet.

nostr:note103pekl3q5wh275dw0zlqwgec2qy7lkp9d7xsk7nuy926xl9805lsj3w6ua nostr:note1cf906evj64t0rdxt7wn983r5t8cur7re5e2tq6yuwa7ggz05sg6qnjwrl6


Users can add their trusted mints. Each mint is like a card. https://image.nostr.build/744ad72b18b3cca924f70e5e43da2e84e002415e00c873b1f36b127d285a0bab.jpg  nostr:note1spv99eg2l4y4k59qghx8gqlq3hrtuze552n2s67jj9v84y0u8znqfyf0sp


When Alice and Bob use Keychat to chat, they can both unidirectionally use two relays, A and B, simultaneously.

Alice uses Relay A to send messages to Bob, and Bob uses Relay B to send messages to Alice. Alice receives messages from Relay B, and Bob receives messages from Relay A.

Thus, Relay A is Alice's sending relay and Bob's receiving relay. Relay B is Bob's sending relay and Alice's receiving relay.

This is the flexibility of the relay model. nostr:note1ye0zcafpykj8e26f34w5sdqh67mp5c0h08atq82allntz8ves3tqd9g4g9


Some Nostr relays are now charging users via a subscription model using Lightning Network sats. For example, a user might pay 10,000 sats for three months of relay service.

If these relays issue ecash, users can buy ecash with Lightning Network sats and then pay per use with ecash.

Under both payment models, the risk to the user is the same.

Compared to a subscription model where the same fee is paid regardless of usage, pay-per-use is a more precise billing method.

https://github.com/nostr-protocol/nips/blob/master/11.md#pay-to-relay https://image.nostr.build/ea2fafd0be776a459b35b582e738384a7084fed0bd517b47a99908776417f2ee.jpg


Why I care about ecash Sats, in one line of text.

「Ecash Sats enable small, anonymous and instant per-use payments. 」

For example, they can be used as estamps for messages, with a payment of 1 ecash sat per message.

Onchain Sats, LN Sats, centralized wallet Sats, shitcoins, Visa, PayPal, Apple Pay, and others cannot accomplish this. Only Ecash Sats can.

Currently, we are paying for many internet services, such as chat app, with our own privacy. Ecash Sats have the potential to change this. nostr:note1m9vem3xxhdvh4t0nfwpjdylkug4h0p8k2w4ep9tvjrddlckhq3ms0vn86d


Please wait, we need some more time.

You can first see if you like the design of Keychat through the notes we have posted.


We are still in development and will release the source code and Android APK. We want more people to understand the design of Keychat.


👇

nostr:note16gv0dfkfaj2cvyujxlk9thckm4vy63r9vl0hpcn9473flca9qqqscm583q


I guess Cashu now supports decomposition down to 1 sat, and may allow for less than 1 sat in the future.


This is a guess. Suppose many Nostr relays charge a fee, requiring users to pay 1 ecash sat for each note they send. At the same time, many mints issue ecash, and these mints are more likely to opt for a model that allows for redemption back into LN sats. Nostr relays would choose to accept ecash from many mints. Both Nostr relays and Ecash mints are service providers, making it unlikely for a monopoly to occur.


This statement should be more accurate and avoid misunderstanding: ecash is custodial and a bearer asset.


I think the latter is more likely.👇

nostr:note1xuv2l9e40vm2p05lk6prsn45tfmy4v4kgj6lxwewdxuysdr4wcrsrnva37


The mint I think.

Ecash is a unique voucher that cannot be retrieved if lost, much like paper money.


With ecash stamp , the idea from nostr:npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8 , we can solve many economic model for information structures


“Ecash is the purest/leanest form of money as data. It can probably not get any leaner than just a text string.”

👇 https://image.nostr.build/70f816ebc4461d3811e23544edd95cc7eb39770ad01945013b1817353b55307a.jpg  nostr:note124y2gkuruaw3qymq3tnghd6pmde2l4y3ut2hthxc6d0pw0f7vfysjnp3ja


Good question. Keychat uses ecash sats as stamps for messages. Users do not lose privacy due to payments, and relay servers no longer need to rely on advertising models to make money.

Onchain sats and LN sats cannot achieve this, making it the most suitable application scenario for ecash sats.

nostr:note1h895va2vdwscyl3r339pdwnvy83kdu0cl646dnal69ws2n2s6p2qx2gaaz


>You're giving up your Bitcoin to custodians for an IOU.

Yes, we know this. Check below note:

nostr:note1qj7egpvfxhdq5e857mn36v9g92tcyzz7wurkyww089yy3z2hcczskpwt9n

>The "Ecash is self-custodial" argument is a misdirection.

When someone says "Ecash is self-custodial," they are not denying the statement "You're giving up your Bitcoin to custodians for an IOU." What they mean is that if you lose your ecash, it cannot be recovered. This ecash is the unique proof, and there is no account that can restore it.


There seems to be a bot that reads all public notes on Nostr, and if there is ecash on a note, it will snatch it.


Satoshi Nakamoto is anonymous, but he also has a reputation.


@proofofsk8 refuted his argument on Twitter, and it deserves to be seen by more people.
👇

1) nyms gain reputation the same as anyone else, by earning it
2) this argument is so tiring. users custody the ecash tokens. the mint custodies the bitcoin. it's not that complicated
3) writing down 12 words is not hard
4) honest custodians have massive incentive to run ecash
5) ecash does not prevent self-custody, it encourages it
6) FOSS devs *can*, *should*, and *must* work on a variety of projects for this bitcoin thing to work. you don't get to pick what they work on, they pick. improving custodians is massively important. maybe the #1 priority. nostr:note1kh6t0phx2shpnkd2qljrw0lvwunyg478ugtaz5av97lqqpjgjeqspfjhgs


No double spend ✌


Perhaps ecash tickets are also more suitable than ecash sats for certain scenarios.


Yes, as long as there are buyers. However, using Ecash sats directly would be more efficient.


I think so.


Received


Enlarge the image and then scan it. Bots can’t scan QR codes yet. https://image.nostr.build/72e3a749e8df4cf9029f3450ca8589e396cddf6a23c3dcc79e76edc7b30e0742.jpg  nostr:note18scvkwyyy7mcedjkgutqtu2dpuk5h5zrq06lfvq3yss4uwkle2vqhel3eh


no


Got it. Bots also accept ecash sats.


LN tx fee


Scatter ecash Sats across the whole internet.


No, it’s not. For minting sats, minting USD, and minting stamps, the risk to the user is the same, which is why it was described repeatedly.


Keychat messages integrate information and value into one. https://image.nostr.build/2436faf43245831f7e9e133e0e6f46453b6dafda0b46beb50cce951cfbbdd4b5.jpg


It’s time to learn more about free banking.

https://en.m.wikipedia.org/wiki/Free_banking nostr:note1qj7egpvfxhdq5e857mn36v9g92tcyzz7wurkyww089yy3z2hcczskpwt9n


It great that I found bitcoin and keychat


The entire Nostr social network can be seen as consisting of first-degree friends, second-degree friends, third-degree friends, and so on. When you want to determine if a newcomer is trustworthy, you can do so by calculating how many degrees of separation there are between you and them.

This is our vague idea, but we are not sure how to create an intuitive UI for it.


I mean that the transaction fees for self-hosted Lightning Network transfers are much more expensive than ecash. https://image.nostr.build/d6edc170332abf678b9c693eb3505c2eac4a17a85810fc096a06717f7bd60679.jpg


Yes, we should at least try. We believe this is a simple and reliable revenue model, and that advertising models are unhealthy.


If users utilize a relay operated by Keychat, we will receive ecash sats.


If they wish, they can operate both a Nostr relay and a Cashu mint simultaneously.

We believe that relays will accept ecash issued by as many mints as possible.

nostr:note1xuv2l9e40vm2p05lk6prsn45tfmy4v4kgj6lxwewdxuysdr4wcrsrnva37


Yes, we are aware of the custodial risks associated with ecash. However, the transaction fees on the Lightning Network are high, comparable to those charged by Phoenix. Additionally, completing a payment on the Lightning Network involves multiple steps. The privacy offered by LN also does not match that of ecash. Therefore, we choose ecash as our form of postage.


Nostr relay operators and Cashu mint operators are independent. If a relay accepts ecash issued by a mint, users can obtain ecash from the mint and use it as postage on their messages. Once the Nostr relay receives it, it can be exchanged for LN sats.


When we started conceptualizing Keychat, we aimed to design a chat application that surpasses Signal. Our design process was divided into four steps.

First, Keychat addresses issues of user sovereignty. It opts to use Nostr public keys as IDs and Nostr relays for message transmission. Users fully own their IDs, which are not registered on any server. They can choose which relays to use.

Second, Keychat aims to solve the security issue of message encryption by implementing end-to-end encryption that ensures both forward secrecy and backward secrecy. Keychat implements the Signal protocol (X3DH and the Double Ratchet algorithm) on the client side without the need for a coordination server. Existing Nostr relays only need to handle the transmission of encrypted messages.

Third, Keychat tackles the problem of metadata privacy. A major issue with original Nostr DMs is that metadata is not only exposed to relay operators but also to other users. Keychat separates the sending address and receiving addresses from the ID, updating these addresses for almost every message. Thus, each Keychat message is nearly independent.

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.

Ultimately, we designed a chat application where users maintain sovereignty, messages are securely encrypted, metadata privacy is preserved, and the economic model is straightforward and reliable. nostr:note1kr8nvdlhz207rq6z300xy6qylf9mmpgjxgfq6925vkez4f3ej3gqh5f0te


We often use the concept of Six Degrees of Separation to explain the Web of Trust to friends, which leads them to visualize a social graph.

https://en.wikipedia.org/wiki/Six_degrees_of_separation


Your thinking is correct. As a user, if you receive an ecash payment, you can inform the sender which mints you accept ecash from. The exchange of ecash issued by two different mints is facilitated through the Lightning Network.


Users can mint ecash sats, ecash USD, ecash stamps, and more. Users would exchange Lightning Network sats for ecash sats, ecash USD, ecash stamps, etc.

Users can mint 10 ecash stamps at the mint with 1 LN sat. These ecash stamps are specialized, and the mint does not allow exchanging back from ecash stamps to LN sats.

For users, using ecash stamps rather than a subscription model can offer better privacy.

The mint only commits to users being able to use these ecash stamps to pay for services at any time, such as relay services.

The risk for users is that the relay service might stop before they use up their ecash stamps.

Users can mint 1000 ecash sats at the mint with 1000 LN sats. They can enjoy more private payments with these 1000 ecash sats, and the transaction fees are very low.

The mint earns a fee from these transactions. The mint commits to exchanging ecash sats back to LN sats on a 1:1 basis when users wish to convert their ecash sats balance back to LN sats.

The risk for users is that the mint may not have enough LN sats to fulfill the redemption, or may refuse to redeem.

Users can mint 7 ecash USD at the mint with 10000 LN sats. They can enjoy more private payments with these 7 ecash USD, and the transaction fees are very low; price stability might also be an advantage for some.

The mint earns a fee from these transactions. The mint commits to exchanging the ecash USD balance back to LN sats at the current market rate when users wish to convert.

The risk for users is that the mint may not have enough LN sats to fulfill the redemption, or may refuse to redeem. nostr:note1xuv2l9e40vm2p05lk6prsn45tfmy4v4kgj6lxwewdxuysdr4wcrsrnva37


We are still in development and will need a few more weeks. We will release the code and the Android APK.


But what if relays issue their own specialized ecash stamps? Users would purchase these ecash stamps from the relay using Lightning Network sats.

Isn't this similar to an App coin? It's inefficient for every app to issue its own specialized coin; we only need a universal currency: sats.

Relays should accept ecash sats issued by as many mints as possible and blacklist bad mints. nostr:note1re4sur0xjd8wxq0wqk8y5qjpp085kyqu7f5fe6zuz3p0e5kvrgfsxz4892


We are inclined to charge for our own relays, one satoshi per message. Users can add and use free relays on their own. We are curious to see what kind of situation this will create.


The term 'stamp' is a metaphor. What is affixed to Keychat messages is not a specialized stamp, but rather generic Bitcoin ecash.

Why does the traditional postal system require stamps? Why not just affix cash or paper money directly onto the envelope? It's likely because the cash could be stolen, and the glue might damage the paper money. nostr:note1g7v8x5dzy45q9jkxhug5h3sykrldl40zvpuyzfgnmsajuntxxcksgdzekc


Of course, we can work together to refine the Double Ratchet Algorithm used in message encryption.

Keychat not only incorporates the Double Ratchet Algorithm used for message encryption but also includes metadata privacy and ecash as stamps. Therefore, we might need an NIP that describes all aspects of Keychat’s design.

Furthermore, Keychat is an application focused on chatting, not just DMs. DM implies that it's merely an ancillary feature of a Twitter-like application.


Bitcoin is a value network based on public keys.

Nostr is a communication network based on public keys.

Keychat is a subset of Nostr and is a private communication network based on public keys. nostr:note1clqvasdpgjad60u4p6sg30ss0n6xdmapmwpzkrdkcn06jwn3s60q2a655a


Keychat will be open-sourced, and we hope to establish a community-recognized Keychat NIP. nostr:note1d09njd8cs995m5zhev6l247uaq9vgrlnvv94vlrz0xa05xcywsvs8afpee


Keychat will be open-sourced, and we hope to establish a community-recognized Keychat NIP.


The vast majority of Bitcoiners are not programmers, but they understand the various macro-level designs of Bitcoin. Therefore, we continuously write notes here to help more people understand how a good chat application should be designed. Understanding what constitutes good chat app design does not require you to be a programmer.

This is also a form of "don't trust, verify."

Good money is important, and good communication is also important. nostr:note1fvh6lxjhq07wlxtlrz89n4fh5tlentyvyk5sapknza9u73ylt4hqjg75hv


There is a type of solution that initially seems hard to conceive, but once disclosed, almost everyone can verify that it's a good solution. These solutions are not particularly complex; they are simply overlooked. This might be what is referred to as insight. We believe that Keychat's use of Bitcoin ecash as postage for messages and the separation of sending and receiving addresses from the ID, with continuous updates, are examples of such insights. They are easily verifiable because they are simple. nostr:note1f6vw6cvnp0mt4s3nwakahffwf3qvh4z49kvt93l9gmqy9jpwd2ksfggmq6


The stamp mode is a simpler payment scheme that requires no registration and is anonymous. It has been in use for almost two hundred years. nostr:note13l208rxcgrcwkp57kv5d25xammp3wt4w0ytprszfxmaarjlymfnsl2smpm


Release Date: May 27, 1994

https://chaum.com/wp-content/uploads/2022/01/05-27-94-World_s-first-electronic-cash-payment-over-computer-networks.pdf https://image.nostr.build/065d85910646d0a13b94169a9d5ab449e7029263790e8cacc979ab4cdd057315.jpg


Sats can flow bidirectionally among wallets at different levels.

The Lightning Network acts as a bridge connecting different ecash mints.

Suppose a user receives ecash issued by Mint A, but does not trust Mint A. If they have a self-custody Lightning Network wallet, they can immediately melt the ecash sats from Mint A back into Lightning Network sats.

If they do not have a self-custody Lightning Network wallet but trust Mint B, they can convert the ecash from Mint A to ecash sats issued by Mint B with a single click.

Behind this operation, they request Mint B to mint ecash, and Mint B provides them with a Lightning Network recharge invoice. Then, they request Mint A to melt the ecash and instruct Mint A to transfer the Lightning Network sats to the invoice issued by Mint B. nostr:note1w7agdjcmyufqt34y8c0p40tuvj7pf9es5k0ttjq975lwqm8em2zq37av2v


Hal Finney's idea and Bitcoin ecash will be increasingly discussed. https://image.nostr.build/7e8c2df2f130f2f458b75348269c60771f2fc6b7691867d9538a23ce039386b4.jpg  nostr:note1h4896wrkwvewrsr3de7tdgj88mmzu5ehxapwjwt9p3z64xhaukqs2ajsyt


The ability for sats to flow bidirectionally among the three types of wallets is something that other systems do not have.


That's feasible; we are also considering it.

“When the balance exceeds 100 sats, you can melt them back into Lightning Network sats. If the balance falls below 100 sats, you can mint some ecash sats from Lightning Network sats.“


1k sats as postage is sufficient; on average, a person sends 50 messages a day, and 1k sats can last for 20 days.


Our initial goal was to use Bitcoin ecash as postage for messages. Later, we thought about implementing various bots on Keychat, such as AI question-and-answer bots, where users can ask questions by paying ecash sats. Therefore, small payments might also be something users need. As a result, we are enhancing the functionality of the ecash wallet, and have already implemented Cashu v1.


If the amount is more than 1 million sats (approximately $700), put it in an onchain wallet. If it is more than 100,000 sats (approximately $70) but less than 1 million sats, put it in a Lightning Network wallet. If it is less than 100,000 sats, put it in an ecash wallet.

Everyone can set their own acceptable values.

How many sats would you put in an ecash wallet at most? You can distribute them across multiple ecash mints. nostr:note1w7agdjcmyufqt34y8c0p40tuvj7pf9es5k0ttjq975lwqm8em2zq37av2v


We are still developing the application; it will take a few more weeks to release the code and the Android APK.


Agreeing to mint fees, the free model is not sustainable in the long run. Moreover, if a mint cannot explain how it makes money, then it is suspicious. nostr:note1y3ewddl4waejglr88k9eagmy4kkw0rwyzud8q9dzt4apvpf59fhsfkhjkw


The discussion about Bitcoin ecash is quite popular on Twitter.

nostr:npub1fqn4fgzkk8nm2x3wd600n935c9tc7xgg9jhk5dfa0kuvrgvsyv7sgu536l  tweeted, "I think we are on a trajectory to go back to community and free market banking but on a much better technological base with significantly better guarantees about the underlying money and substantially better guarantees about individual bank solvency and transparency. Ecash or similar on top of bitcoin and lightning. Hal predicted this." "Satoshi wrote about the problem of central banks. Hal and Szabo wrote about ecash. You can be your own bank. And you can be your own ISP too. Some people will choose to be their own bank or ISP. Others will get those services from those people. A layered approach with base layer decentralization and upper layer scalability is necessary."

nostr:npub1a2cww4kn9wqte4ry70vyfwqyqvpswksna27rtxd8vty6c74era8sdcw83a  tweeted quoting, "What I envisioned for bitgold was a two-tier architecture. That you have bitgold as your settlement layer for large value transactions, and I was going to use chaumian digital cash which would give you privacy and efficient transactions at a retail level." -Nick Szabo, 2015.

Bitcoin allows us to have three types of wallets, not just limited to ecash wallets. nostr:note1w7agdjcmyufqt34y8c0p40tuvj7pf9es5k0ttjq975lwqm8em2zq37av2v


The payment model of using Bitcoin ecash as a message postage stamp is not only very simple and user-friendly for the sender, as the stamping process is automated and requires no additional action from the user, but it is also very straightforward for relay operators to charge fees without the need to establish a separate accounting system for billing. nostr:note10jxy84xymvp7w20qhqzxwxn6x05ya83jzway86y66nypug990rnsfe46u9


Public key cryptography has been around for nearly 50 years, and we are finally beginning to build the internet using public keys as IDs—not only for social networks, not only for the web, but for the entire internet. nostr:note12fgl8h8jmtjy7rnstm7zyzsl0mfej7663emksc4pygdsv75xqj2swtpuh9


We call this "programming for the next message." nostr:note1ye0zcafpykj8e26f34w5sdqh67mp5c0h08atq82allntz8ves3tqd9g4g9


Keychat primarily uses public key cryptography to encrypt messages, while Damus primarily uses public key cryptography to sign messages.

Keychat is designed to allow private notes to be decrypted and viewed only by specified individuals. Damus is designed to allow more people to see public notes and to verify that the messages are indeed posted by the owner of the public key. nostr:note12fgl8h8jmtjy7rnstm7zyzsl0mfej7663emksc4pygdsv75xqj2swtpuh9


We haven't discussed this with relay operators yet, but adding a postage feature to relays is very simple. For chat apps, messages do not need to be stored for a long time; in the best case scenario, once the recipient has received the message, the relay can delete it immediately. For the Damus app, the issue of storage duration is more complex. Perhaps it will depend on competitive pricing in the relay market. We are not sure.


Keychat and Damus are both applications based on the Nostr protocol. What are the design differences between Keychat, as an application for posting private notes, and Damus, as an application for posting public notes?

In our view, the Nostr protocol has three main innovative points. First, it boldly allows users to use public keys directly as IDs. Second, it has chosen a relay model where relays do not communicate with each other. Third, it is equivalent to having built-in RSS.

For Keychat, it utilizes Nostr’s public keys as identities and the relay model but does not use the built-in RSS. Keychat’s contact list is only saved locally for better privacy.

Keychat has implemented three unique designs.

To address the issue of message encryption security, Keychat employs the Signal protocol to achieve end-to-end encryption.

To tackle metadata privacy issues, Keychat separates the sending and receiving addresses from the ID and continuously updates these addresses.

 To ensure that relays can operate sustainably, Keychat uses Bitcoin ecash as postage stamp for messages.


The app is still under development; we will release the code and the Android APK.


You might be interested in 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/


“Chaum’s approach to the protection of privacy can be thought of as having three layers. The first layer is public-key cryptography, which protects the privacy of individual messages. The second layer is anonymous messaging, which allows people to communicate via electronic mail (“email”) without revealing their true identities. And the third layer is electronic money, which allows people to not only communicate but to transact business via a computer network, with the same kind of privacy you get when you use cash. If you go into a store today and make a purchase with cash, no records are left tying you personally to the transaction. With no records, there is nothing to go into a computer database. The goal of electronic cash is to allow these same kinds of private transactions to take place electronically.” nostr:note1vjj55sjdzle6ez65p8lesq59nhjmxs8cg6hmlwaungcltkydnq3qyafwul


I'm very bullish of using ecash as "postage stamps" or any kind of access token because of its privacy properties. Hashcash, which Bitcoin's PoW is based on, was invented precisely to do that!


Sending and receiving ecash sats on Keychat is as simple as sending a picture.

It's the ideal channel for sending ecash sats. https://image.nostr.build/a14614d44a901e31d4944788916239a093eb00ad2c79f346485c2e01baa70e64.jpg


In Keychat, the contact list is only saved locally and does not use a relay to store the contact information. Contact lists in chat applications are important private data for users and should only be known by the users themselves. The contact list should not be used for so-called social graph mining.

The chat ID used for publishing private notes is different from the post ID used for publishing public notes. These two should be completely separate; a user can have multiple chat IDs and multiple post IDs.

For post IDs, it can be publicly displayed who is being followed and who is following them. This can help establish a web of trust.


Keychat is a very open chat application that makes no distinction between humans and bots; both are just public keys.

Developers can easily create an AI bot on Keychat, charging users ecash sats on a pay-per-use basis. Users can add the AI bot as a friend and start chatting and asking questions.

Conversational as a Service.

nostr:note1evydzwkym5n66rxz98fudc78dvnwqcmaqmrtseu8zfpneukjandqff2aps

nostr:note1d09njd8cs995m5zhev6l247uaq9vgrlnvv94vlrz0xa05xcywsvs8afpee


Keychat is using bitcoin ecash as message stamp. https://www.keychat.io/ https://image.nostr.build/5cd0c55d1f032fdcadb20c5246d00511f0bfba12cad4067ce3fa04bf8e09ae79.jpg


In a few more weeks, we will release the code and the Android APK.


Bingo


This is also our chain of thought. nostr:note1cjq2ucwkh83x43juvu7fs0nn5lwjz6a4vasxwz4478v04ql85f4s5dvhj9


If the members exceed 100, will the group chat first turn into a group listen, and eventually no one chats?


Only when a message fails to send will there be a notification. If the message is sent successfully, there will be no notification.


Bug or feature?

Keychat does not support message read receipts, typing indicators, or last seen functions.


Many people need three different levels of Bitcoin wallets: a self-custodial on-chain wallet, a self-custodial Lightning Network wallet, and a non-self-custodial eCash wallet. These three wallets work together for different scenarios. nostr:note120pqvtvysjj3j86ymd9umseps3vez4g5wesqttp5tgrcm40qsursk3dtse


Bitcoin silent payments have been maturing, and there are already wallets that support it, such as https://app.silentium.dev.

Silent payments are a type of payment that can be made to a unique on-chain address for every payment, even though the receiver has provided the spender with a reusable (off-chain) address. This improves privacy.

Keychat's continual update of receiving addresses is somewhat similar to silent payments, with the goal of avoiding address reuse to enhance privacy protection. Both use ECDH, but the difference is that Keychat's update of receiving addresses is interactive, while silent payment is non-interactive; the recipient needs to scan all transactions to find those that belong to them. Interactive updates are more suitable for chat scenarios, while non-interactive updates are more suitable for transfer scenarios.

https://silentpayments.xyz

https://bitcoinops.org/en/topics/silent-payments/

https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#user-content-fn-2-28a8767a0e337d8ff2949d11121e27b4 nostr:note1mzmdvjzfud0nnz94t5f2r3cl4hh692ytvaeks2e754nf4rvxdamsuafzdn nostr:note18ef8r2naprhyv956syrjyaapc3pqngef7n6ax36ku7g8djfesltqhx6m8s


From the perspective of users not familiar with the ecash minting principles, "deposits" and "withdrawals" are better terms. We are considering it. Thank you.


I personally think that the terms "deposits" and "withdrawals" imply that the sats have not changed, when in fact they have.


The Cashu protocol spec uses 'mint' and 'melt'. This may be a metaphor for minting coins from bullion and melting coins back into bullion. 'Mint' does not imply a change in supply, think about minting coins.


There will be market competition among relays, resulting in the market price of estamps.


Free cannot last forever. Relay operators need to pay expenses.


Relay operators need revenue to cover server costs and other expenses.

nostr:note12km4sp6nr7g8urcrxf5k2lueru9rrlntp8j93zags5nyeygajwhqkr6fct


Perhaps because you don't understand why Bitcoin is crucial, you find our constant discussion of it boring.


Pay with attention?


We face three choices:
pay with privacy,
or it cannot continue to operate,
or pay with Bitcoin ecash. nostr:note1xes595qh2z0wswyru078amzl5h3zalnswadktckknh242purhr9sgqshfy


I think so.


Not audited now.

We will release android apk and code later. Still in development.


Chat application network architectures are primarily divided into: centralized model, federated model, relay model, and P2P model.

Chat software developed by major companies primarily uses a centralized server network architecture, such as WhatsApp and Telegram. Signal App also follows this model. Only large companies can run their own servers and have the greatest control.

The XMPP protocol and Matrix protocol use a federated server network architecture. The most famous example of a federated server network architecture is Email. Users can choose which federated server to use. Servers communicate with each other, and users do not need to know which server their friends are using.

Keychat and Simplex chat use a relay architecture. Users can choose which relay server to use. The main difference from the federated model is that relay servers do not communicate with each other.

In the relay model, users find out which relay their friends use, adding user tasks but simplifying server operations. Each relay operates independently, simplifying network design and reducing maintenance. Since relays do not communicate with each other, this setup reduces data exposure risks and improves privacy.

Keet.io uses a P2P model. Keet may be more suitable for large-scale group chats, whereas it might be less appropriate for one-on-one chats or smaller groups. Keet requires chat participants to be online simultaneously, or at least one party needs to be continuously online.

(If there are any mistakes, please reply. Thanks) https://image.nostr.build/e528c4905afad5731f2cd2693980d46a2d1ebe0d307bdb469cfca01eb4751481.jpg https://image.nostr.build/88f61ec3d70a7e1f0f11ebfd0a69281fe949a205e0c9b5ad0c50f78476645e74.jpg


You got it. 👍


Smart client, dumb server.

Client master, server slave. nostr:note1kr8nvdlhz207rq6z300xy6qylf9mmpgjxgfq6925vkez4f3ej3gqh5f0te


If you are very committed to the standard of self-custody of sats and feel that ecash sats do not meet this standard, how about maintaining a balance of only 100 ecash sats?

When the balance exceeds 100 sats, you can melt them back into Lightning Network sats. If the balance falls below 100 sats, you can mint some ecash sats from Lightning Network sats.

This is why we added mint and melt operations here. nostr:note1spv99eg2l4y4k59qghx8gqlq3hrtuze552n2s67jj9v84y0u8znqfyf0sp


No, Signal collaborated with the issuer of the shitcoin.


We don't like that the Signal App integrated a shitcoin.

We hope that sats can be easily accessible and usable. https://image.nostr.build/e77661d61080371a3103f5aa2c334b597e5f4cdcf2ed9980e124264862134772.jpg  nostr:note1spv99eg2l4y4k59qghx8gqlq3hrtuze552n2s67jj9v84y0u8znqfyf0sp


Keychat has integrated a cashu wallet to enable the functionality of using Bitcoin ecash as message estamp.

Users can send and receive ecash sats. They can also mint ecash sats from Lightning Network sats and melt ecash sats back into Lightning Network sats. https://image.nostr.build/eefac68ec6c960b7a2852dc95b36371939cc9b57d5b44dfcb9cdc6effc04c1c8.jpg


Encrypted group chats are more challenging to implement than one-on-one chats.

Currently, there is no perfect solution for encrypted group chats, and different designs come with various tradeoffs. Keychat will support multiple types of encrypted group chats to meet different scenarios.

Keychat first implemented the pairwise group, which is designed for small groups of close friends. It offers the highest security, but can only support a limited number of group members.

When sending a message to a group, group member simply deliver a pairwise encrypted message to each member of the group. It simulates group chat using multiple one-on-one private chats. Therefore, it maintains the same forward secrecy and backward secrecy as one-on-one chats.

While certainly simple and secure, it’s not without costs. Instead of delivering one message, a client needs to deliver N messages and pay N ecash stamps. https://image.nostr.build/65f444c8097ff72997d57dc7f5a48c1ccb62cd03521bd9b7a89b82a9dcab5379.png


Agree. After open-sourcing the code, we will provide more detailed descriptions of various design details.


We handle message encryption and metadata privacy separately. The message encryption part uses libsignal directly, which means it only uses curve25519. Message metadata privacy is achieved by separating the sending and receiving addresses from the ID and continuously updating them. The sending address is generated completely randomly. The receiving address is derived from the key generated by reusing the DH, and it is in the secp256k1 format.


Alice sends a message to a new address A1, not to Bob's ID key. This new address is derived from the DH ratchet, known only to Alice and Bob. Bob pulls messages sent to A1 from the relay and then decrypts them.


Bob will send letter to Alice’s old address.

Alice will still listen to several old addresses in case.


Perhaps you can understand Keychat's continual updating of sending addresses as akin to Signal's sealed sender feature.

https://signal.org/blog/sealed-sender/

“When you send a traditional piece of physical mail, the outside of the package typically includes the address of both the sender and the recipient. The same basic components are present in a Signal message. The service can’t “see into” the encrypted package contents, but it uses the information written on the outside of the package to facilitate asynchronous message delivery between users.

While the service always needs to know where a message should be delivered, ideally it shouldn’t need to know who the sender is. It would be better if the service could handle packages where only the destination is written on the outside, with a blank space where the “from” address used to be.” nostr:note18ef8r2naprhyv956syrjyaapc3pqngef7n6ax36ku7g8djfesltqhx6m8s


>The idea with giftwrapping is that the relay/server can't know who the real sender is.

The approach of updating both the sending and receiving addresses can protect not only the sender but also the receiver of the message.


Similar to NIP4(NIP4).


Yes. We recommend adding friends by scanning QR codes or copying and pasting them. Adding friends through a method similar to NIP4 offers less privacy.


nostr:note18ef8r2naprhyv956syrjyaapc3pqngef7n6ax36ku7g8djfesltqhx6m8s

Keychat reuses the DH ratchet to update the receiving address. Suppose Alice and Bob are chatting using Keychat; only they know the receiving addresses generated by the DH ratchet, which allows them to track who is who.


I should have been clearer, it is not the standard NIP4; the sender's ID will be hidden.


The QR code mainly contains a Nostr public key, a Signal ID key, a signed prekey, and one-time prekeys, among others. All clients can generate such QR codes independently, without relying on Keychat.


If you are confused about Keychat changing the sending and receiving addresses for almost every message after reading the note below, let me give you a real-life example.

Suppose Alice is traveling in the UK and Bob in France. They each stay in a new hotel in a new location every day. They agree to write each other a letter daily, sharing their travel experiences. They only need to inform each other in the letter where they will be staying the next day, and they can successfully send and receive letters. The receiving address is used only once. nostr:note10aym80w2h0f2jda4fw59prerlpch8z7j9l526xzja8xcx5zku7qsxf5qvd


Why is it named Keychat?

Firstly, the user's ID, encryption key, sending address, and receiving address are all keys.

Secondly, the term 'Key' suggests something that is both crucial and secure.

Finally, We learned from the name 'Bitcoin'. We think the compound name 'Bitcoin' is excellent, made from two very common words, 'Bit' and 'coin'. Almost everyone can understand at first glance what it is about.

Keychat is also a compound word formed from two simple words, 'Key' and 'chat'. We hope everyone can grasp at first glance what it is about.

What do you think of the name Keychat?


This is a difficult question to answer; we don't believe the future is certain, whether it will be a success or a failure. What we can do is make Bitcoin ecash more widespread and popular.


This is a change of perspective.


Therefore, Keychat uses libsignal to handle message encryption without altering its original curve25519. The Nostr public key serves as the user ID.


Regarding metadata privacy protection, we find the NIP-59 approach unintuitive and the idea complex. We believe that the key to protecting metadata privacy is to separate the sending and receiving addresses from the ID and to continually update these addresses. Just like the Signal protocol separates the encryption keys from the ID and updates them regularly to achieve better message encryption.

“The current Nostr DM (NIP4)  integrates four capabilities into a single Nostr key—it serves as an ID, an encryption key, a receiving address, and a sending address.

In Keychat, the ID, encryption key, receiving address, sending address are separated, allowing the encryption key , the receiving and sending addresses to be updated continually. This achieves better encryption security (forward secrecy and backward secrecy) and metadata privacy.”

nostr:note1f6vw6cvnp0mt4s3nwakahffwf3qvh4z49kvt93l9gmqy9jpwd2ksfggmq6


In the first version of Keychat, we also adopted the method of replacing curve25519 in the Signal protocol with secp256k1 from Nostr. However, we later realized that this approach was not optimal. Making such changes to libsignal is a risk point and adds complexity. The current practice in Keychat reuses libsignal with almost no modifications. Just as a phone number is the ID for Signal App users, a Nostr public key is the ID for Keychat users.

nostr:note1fheh3qx46469ku5s7y4ywl8w49g6srcup6es0stglafy6spupumq5j6msc


This can be achieved.
But keychat doesn’t support it now.


Signal protocol uses curve25519. However, Nostr protocol uses secp256k1. Has NIP104 replaced curve25519 with secp256k1 in the Signal protocol?


yes of course .


When evaluating a chat application, we primarily use the following criteria:

1. Secure message encryption
2. Metadata privacy protection
3. User control with self-owned IDs and choice of server
4. Server's revenue model is reasonable and sustainable
5. Good user experience


Will reply later.


When we use search engines and AI, we send a query message to the server. Can’t this message be stamped with a Bitcoin ecash stamp? Compared to the current advertising revenue model, using Bitcoin ecash as a estamp would be a paradigm shift.


We will post a note later explaining how Keychat implements group chat.


A ratchet can only turn in one direction.

The double ratchet means two types of ratchets: a KDF ratchet (the small ratchet in the diagram) and a DH ratchet (the large ratchet in the diagram).

KDF stands for Key Derivation Function. A hash function is the simplest KDF because it is one-way. K1=hash(K0), K2=hash(K1), K3=hash(K2), K4=hash(K3)... K1 is used to encrypt the first message, K2 to encrypt the second message, and so on. Once used, the key is deleted. If an attacker obtains the latest encryption key K5, they cannot reverse-engineer K4, K3, K2, or K1, ensuring the security of historical messages. Thus, the KDF provides forward secrecy to the encryption protocol.

However, the attacker can derive K6, K7, K8..., which means there is no backward secrecy. This is where the DH ratchet comes into play.

The Diffie–Hellman (DH) key exchange is a mathematical method for securely exchanging cryptographic keys over a public channel. Alice, using her private key S1 and Bob’s public key P2, can compute a value. Similarly, Bob, using his private key S2 and Alice’s public key P1, can compute a value. These two values are equal.

Alice and Bob continuously generate new DH key pairs for new messages on the client side and attach the public key in plaintext to the message. The message recipient can then use this public key and their private key to perform the DH computation. This DH ratchet effectively resets the KDF ratchet with the DH ratchet. Because the attacker does not know the latest DH private key, they cannot derive future encryption keys, thus providing backward secrecy.

Therefore, in the double ratchet algorithm, the KDF ratchet ensures forward secrecy, and the DH ratchet ensures backward secrecy, together achieving both forward and backward secrecy.

We recommend the following video, which provides a more intuitive animation demonstration.

https://youtu.be/9sO2qdTci-s?si=BXLU33BRANWAJKMz

https://youtu.be/7uEeE3TUqmU?si=jpPOR_O61IppgJxl

(We hope users can understand the basic principles to judge for themselves which chat applications are good.) https://image.nostr.build/02cf8185e461b3ce03d84397debf4901724f5ed4d1198f83913fa2303e3a0214.png  nostr:note1ffgsgvkltl96wzwe6lakv2ntjfkq2u48msx57mrvnnhtyde5s2js8antlr


Keychat

Keymail


Keychat is a chat browser, in a sense.

Web browser can access all web servers. Keychat can access all Nostr relay.

In a web browser, there are many tabs arranged from left to right, each linked to a different web server. In Keychat, there are many chat tabs (or chat rooms) arranged from top to bottom, each connected to a different Nostr relay.


Below is the QR code for Keychat users. What is its purpose?

Let's revisit the Signal App. Alice and Bob register using their phone numbers, generating Signal key pairs (including ephemeral keys) locally, and uploading the public keys to the Signal server. When Bob wants to add Alice as a friend, he enters her phone number, prompting the Signal App to request Alice’s Signal public keys from the server. Bob’s Signal App uses these public keys and his private keys to initiate the X3DH and double ratchet algorithms, deriving an encryption key for the first message, which includes Bob’s public keys in plaintext. Upon receiving this message, Alice’s Signal App uses Bob’s public keys and her private keys to initiate the same algorithms, deriving the encryption key to decrypt the message.

Following the design principle of minimizing server power, Keychat does not use a server to store user public keys. The Keychat QR code directly contains the various keys needed to initiate the X3DH and double ratchet algorithms. By scanning the QR code or copying and pasting its content, users can add friends and start chatting.

The QR code also includes a Nostr public key. Just as a phone number is the ID for Signal App users, a Nostr public key is the ID for Keychat users.

Suppose Alice and Bob are both using Keychat, but Bob only knows Alice's Nostr public key and does not have the QR code. How can Bob add Alice as a friend? Bob can send Alice a Nostr DM (NIP-4) message to request the QR code. After receiving the DM, Alice can reply to Bob, enabling them to switch to Keychat mode.

Alice can choose to block all NIP-4 messages, allowing only those who know her latest QR code to add her as a friend, preventing spam. The QR code has an expiration date because ephemeral keys need to be continuously updated. Friends cannot be added using an expired QR code. Keychat will continuously generate new QR codes. https://image.nostr.build/cde093be663eacf6ef92b6fb2d29bad54e70f35fc7609cee972a7d15d55d4270.jpg


But why don’t current chat applications offer this function? It might be related to their advertising revenue model. Using multiple IDs makes it harder for these chat apps to mine user data, decreases the accuracy of user profiling, and thus affects ad targeting precision, ultimately impacting ad revenue.

To exaggerate a bit, the customers of these chat applications are the advertisers, not the users. Users are merely the product that the chat apps sell to advertisers. nostr:note1kgha0g0rt6ywkcx5xzj6s788ycjpwygre7q92szaek5e8g22p85qaatrwc


👏 Wow

Keychat is also developing this seed phrase backup feature by reusing the 12-word mnemonic originally designed for the ID.

Users only need to remember 12 words to gain control of both their ID and Cashu Bitcoin ecash. https://image.nostr.build/4e1ce7563fd2cba8dbed3ebbe2ffe6a8b565851c1d2a4cd2bc8f4eb871555eb0.jpg  nostr:note150ywd3rmpw086uwus22kyf45gvqk78r6dl8qm4rv65jem49hglts3um34a


yeah