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. View quoted note →

Keychat's relay charges using the stamp model, perhaps Damus's relay should charge using a rental model. View quoted note →

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. View quoted note →

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. View quoted note →

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. View quoted note →

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.

Thanks! @calle https://www.youtube.com/live/LMeNe1tBsr4?si=k0tyyJsMBtJNapmn&t=16551

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. View quoted note →

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. View quoted note →

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. View quoted note →

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. View quoted note →

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. View quoted note → View quoted note →

Users can add their trusted mints. Each mint is like a card. View quoted note →

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. View quoted note →

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.

GitHub

nips/11.md at master · nostr-protocol/nips

Nostr Implementation Possibilities. Contribute to nostr-protocol/nips development by creating an account on GitHub.

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. View quoted note →

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

@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. View quoted note →