nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-19 22:35:50 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

markdown formatting.

Browse Source
This commit is contained in:
fiatjaf 2022-07-21 06:42:32 -03:00 committed by William Casarin
parent c505dcc910
commit 51839d716f
1 changed files with 3 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
21.md
View File

@ -43,8 +43,7 @@ Ids and signatures omitted and pubkeys shortened for readability.
[^q1]: https://t.me/nostr_protocol/26059
Rationale
---------
## Rationale
[NIP-04](04.md) is flawed because its event contents are encrypted, but the metadata around it is not, and by the nature of Nostr as a protocol designed for public communication in general anyone is able to query relays for any event they want -- thus it's possible to anyone to track conversations between any other Nostr users, not _exactly what_ they're saying, but to whom they're chatting and how often.
@ -59,8 +58,7 @@ This NIP, if used in conjunction with relays that are trusted to honor it and no
[^1]: Not considering, of course, the million other features Telegram offers, that are irrelevant to this document.
[^2]: Not considering, of course, the cryptographic protocols that Signal uses to provide forward secrecy and other advanced functionality which are already not present in NIP-04.
Comparison with other proposals
-------------------------------
## Comparison with other proposals
Over the last months a number of other proposals were made to try to improve the lack of privacy NIP-04 provides[^3][^4][^5].
@ -75,8 +73,7 @@ Although all these proposals solve the issue in some way of another, and it can
[^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.
Further possibilities
---------------------
## Further possibilities
Some random things that can be optionally done based on this NIP: