nostr
/
nips
mirror of https://github.com/nostr-protocol/nips.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

simplify text.

This commit is contained in:
fiatjaf 2024-04-03 10:05:14 -03:00
parent fd50a422c2
commit 331e8d01ac
1 changed files with 5 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
70.md
View File

@ -8,7 +8,7 @@ Protected Events
When the `"-"` tag is present, that means the event is "protected".
A protected event is an event that can only be published to relays by its author. That allows the author to choose who can access their events (either by knowing in advance the relay policy with regards to reads or by means of an external relationship with the relay that is not specified here).
A protected event is an event that can only be published to relays by its author. This is achieved by relays ensuring that the author is [authenticated](42.md) before publishing their own events or by just rejecting events with `["-"]` outright.
The default behavior of a relay MUST be to reject any event that contains `["-"]`.
@ -34,26 +34,12 @@ The tag is a simple tag with a single item: `["-"]`. It may be added to any even
["OK", "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2", true, ""]
```
## Use cases
- private groups
- private feeds
- optimistic hiding of DMs or other encrypted material metadata
## Why
Many people want to restrict access to some of their data to a closed group: by having, for example, a private feed for paying subscribers.
There are multiple circumstances in which it would be beneficial to prevent the unlimited spreading of an event through all relays imaginable and restrict some to only a certain demographic or to a semi-closed community relay. Even when the information is public it may make sense to keep it compartimentalized across different relays.
Even though it's ultimately impossible to restrict the spread of information on the internet (for example, one of the members of the closed group may want to take an event intended to be restricted and republish it to other relays), most relays would be happy to not facilitate the acts of these so-called "pirates", in respect to the original decision of the author.
It's also possible to create closed access feeds with this when the publisher has some relationship with the relay and trusts the relay to not release their published events to anyone.
This NIP gives these authors and relays the means to know when a given event is not intended to be broadcasted to all and everywhere.
Even though it's ultimately impossible to restrict the spread of information on the internet (for example, one of the members of the closed group may want to take an event intended to be restricted and republish it to other relays), most relays would be happy to not facilitate the acts of these so-called "pirates", in respect to the original decision of the author and therefore gladly reject these republish acts if given the means to.
## How
The default behavior for relays will be to reject all events with the `"-"` tag. The only relays that should accept these events are those that have been explicitly programmed to enforce write access control for all events with the `"-"` tag.
Authors of protected events would have to have some kind of relationship with some specific relays -- for example, using [NIP-29](29.md) -- that would enable relays to know to whom these events can be served once they're published by the author.
If someone tries to copy the event and publish it to other relays that wouldn't enforce the rules intended by the author that won't work as these relays will reject the event.
In practice there may be relays that accept these "pirated" events, but that isn't different from what happens in the current internet.
This NIP gives these authors and relays the means to clearly signal when a given event is not intended to be republished by third parties.