ZapTok has been added to the Keychat Mini App list. View quoted note →

Similarly, on the desktop version of Keychat, you can also use multiple Nostr web clients simultaneously. View quoted note →

Theoretically, Keychat has currently achieved only 50% of the goal for the ID and Wallet application scenarios, which involves using them within Keychat's internal Chat and Browser (Mini App). The other 50% of the potential goal is to apply Keychat ID and Keychat Wallet to native apps outside of Keychat on the device. This would allow other native apps on the device to use Keychat ID for login and Keychat Wallet for paying Bitcoin Lightning invoices. (We have only made an initial attempt at implementing the function of native apps calling Keychat Wallet for payments, and it is still unstable. A better solution may be needed. You can view this in the settings at the top right corner of the Wallet page.) View quoted note →

🤔 View quoted note →

Is Keychat a Nostr app — or isn’t it?🤔 View quoted note →

The hardest part of developing group chats is managing members—adding and removing them—without relying on a centralized server. View quoted note →

If you’re planning to create a temporary group chat that’s partly public and partly private (for lack of a better term), perhaps you could consider a shared key group. Users who know the shared key can join by entering it, or simply by clicking a link. View quoted note →

Message notifications become more difficult when users are free to choose the relays.

Keychat emulates a postal system. Each message is a letter; the relay functions as the post office, and every message carries a postage stamp—an ecash sat. The Nostr public key serves as the user’s ID, while the sending address, receiving address, and encryption key are independent of that ID and rotate continuously. For one-to-one and small groups, these components are generated and rotated by the Signal protocol; for large groups, they are generated and rotated by the MLS protocol.

Evolution of Receiving Addresses in Signal, Simplex Chat, and Keychat A receiving address is indispensable to any chat application—just as an envelope needs only the recipient’s address. Because this address is exposed plaintext metadata, its design determines how much metadata privacy the user enjoys. Signal each user has a single receiving address that is also their ID. For Bob and Carl alike, Alice’s address is always the same—simply A—and it never changes. Simplex Chat Here, the receiving address (smp://<queueKey>@<relay-host>/<queueId>) is different for every contact. Alice has one fixed address for Bob, A(b), and another for Carl, A(c). Having separate—but constant—addresses for each contact is already a significant improvement over Signal’s single, global address. Keychat Keychat goes a step further: the address not only differs per contact but also rotates over time. Alice begins with A(b1)for Bob and A(c1) for Carl; after she replies, they become A(b2) and A(c2), and so on. Each time Alice responds to Bob, her address is refreshed. This dynamic, per-contact rotation provides even stronger privacy than Simplex’s static per-contact addresses.

You can clearly see how Keychat protects the privacy of message metadata. View quoted note →

Maybe it’s more appropriate to call Keychat users “Keychat customers.” Those who pay are the real customers. In most “free” apps, it’s the advertisers — not the users — who are the customers, while the users themselves are the product.

Prioritize app development in domains with the highest user engagement and adoption. View quoted note →

The latest version of Keychat is now available for download on Zapstore. Thanks @Zapstore