Here is a summary of several topics that I think are important to watch in Nostr development:

🔑 Key Management:

So far there isn't a way to transfer from an old key to a new key as part of the protocol. There are some proposals for key delegation with a root key, such as NIP-26. Another proposa (NIP-41 Draft, PR 158) is to use prior key commitments to be able to move to a new predetermined key. There could also be work towards using NIP-05 (DNS-based identifiers), combined with a method to revoke a key, to confirm moving to a new key.

📬 Direct Messages:

With the current implementation (NIP-04) everyone can know who DM each other and how many messages. However, the messages can only be read by the two parties. The encryption method is also being discussed with the possibility of moving to use AES-GCM. At this point, there isn't spam protection for DMs, outside of only using paid relays. Proof-of-work (NIP-13) or Zaps (NIP-57) could be used in an improved DM specification. Furthermore, a handshake request for DM with a negotiated secret "place" (perhaps with DH) to exchange messages, could help. There could be some concepts to learn from Signal messenger development.

⚡Lightning Wallets:

I expect to see improvements with 24/7 available non-custodial lightning wallets that can be setup quickly and require little channel maintainence, similar to today's non-custodial mobile wallets. These wallets could support NIP-57 (Zaps) as well as LN Addresses and BOLT12. BTCPayServer looks like a good option and there are others. It'll be useful to look more into it.

📡 Relay & Client Model:

There is discussion on how to best model the use of relays. Most clients currently rely on a general set of relays; clients need to share a relay to exchange notes. Instead, a client would share the relays they are using using NIP-05 and NIP-65 and other clients could request notes from those relays. Therefore, both clients do not need to share the same relay and can write to different ones and still receive notes. This is implemented in the Gossip client.

For reference and further reading of NIPs:

- https://github.com/nostr-protocol/nips

- https://github.com/nostr-protocol/nips/pull/158

- https://github.com/nostr-protocol/nips/issues/107

Reply to this note

Please Login to reply.

Discussion

With progress in a few key areas, I don't see a reason it shouldn't keep going.

#[2]

A view/list that priorities notes zapped/liked by the most number of follows, in a given amount of recent time, I think would be useful. I am thinking about taking a look at how to implement in Amethyst.

Also a solution for key maganement and improved DMs I think are also important, as decribed here:

#[3]