nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-22 16:35:52 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

add further possibilities.

Browse Source
This commit is contained in:
fiatjaf 2022-07-20 21:29:03 -03:00 committed by William Casarin
parent 95cec2b8a7
commit 86c9de4970
1 changed files with 10 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
21.md
View File

@ -58,3 +58,13 @@ Although all these proposals solve the issue in some way of another, and it can
[^5]: https://github.com/nostr-protocol/nips/pull/17 [^5]: https://github.com/nostr-protocol/nips/pull/17
[^6]: For example, even with ephemeral keys, if the general public still have access to all the events some time-analyses and other heuristics can be used to try to track chat activity between Nostr users. [^6]: For example, even with ephemeral keys, if the general public still have access to all the events some time-analyses and other heuristics can be used to try to track chat activity between Nostr users.
[^7]: Another example: even with ephemeral keys, it can be assumed that relays will know at least the IP address of the clients that are using it for the kind-4 messages, so they will have almost as much metadata as before -- which brings us back, again, to some level of trust on these relays to not reveal this metadata to the public, as in the current proposal. [^7]: Another example: even with ephemeral keys, it can be assumed that relays will know at least the IP address of the clients that are using it for the kind-4 messages, so they will have almost as much metadata as before -- which brings us back, again, to some level of trust on these relays to not reveal this metadata to the public, as in the current proposal.
Further possibilities
---------------------
Some random things that can be optionally done based on this NIP:
1. If relays can now get the public key of a client that is using it for direct messages, it can also give read reports to the ones who sent the messages (because it will know when the other side of the conversation have requested and received each message in the chat). This is a UX improvement that can't be achieved otherwise.
2. Clients can obfuscate the global view relays would have from their metadata by using multiple relays and only sending direct messages to one (or a few) at a time. Thus, if two peers share relays A and B, they can send 50% of the messages through relay A and 50% through relay B.
These possibilities can be specified better on further NIPs.