relay-based event access-control with the ["-"] tag
#1030
Conversation
|
So, relays and clients that don't yet support this tag will receive and rebroadcast the event everywhere as usual. And the relays that do support it, will have to find a way to know what
Doesn't that mean that, in a group, a user would only be able to download their own messages? |
| Protected Events | ||
| ---------------- | ||
|
|
||
| `draft` `optional` |
There was a problem hiding this comment.
| `draft` `optional` | |
| `draft` `mandatory` |
There was a problem hiding this comment.
I like the simplicity, but it's gotta be widely adopted for it to be useful.
There was a problem hiding this comment.
maybe the requirement that relays reject events with "-" tag by default should actually be added to NIP01, and then this NIP would define when events with "-" tag can be accepted (when the author matches authenticated user). that would suggest that rejection of events with "-" tag is expected behavior, while making it optional to accept them under very specific parameters.
Yes, but this NIP only works if it gets mass adoption by relays, which I think is not a large ask once most people are convinced of its usefulness.
No. This would fit other schemes, like #566, and reuse the authorization scheme already described in those. It could also be relied upon by an encrypted DM or group chat scheme that would rely on relays not leaking metadata to anyone. |
|
Also remember that in most cases, specially if a group is small enough, there will be no incentive for receivers of these protected events to go around searching for a rogue relay to which publish the data against the will of the original author. And also most normal users wouldn't also download a special client that knows what are these rogue relays and uses them specifically to download the events leaked from groups that would otherwise be private. A normal NIP-29 client, for example, would never even try to download events from groups to which it doesn't belong. Exceptions are not the rule. |
Those two things are mutually exclusive. The Clients can use this tag to not automatically re-broadcast the event and require choosing relays when the user tries to re-broadcast. However users might not know where the event should go to make the choice themselves. It feels very abstract/general. Which is unlike you @fiatjaf |
|
Handy NIP to make an event be hosted just on relays that support NIPs/behavior the author needs. |
|
love this. very simple but powerful (but as with all nostr policy, only as powerful as its adoption). honestly surprised me that this hasn't already been done. I kinda think this should just be added to the NIP42 generally, right? if so, my next question is what use case are you envisioning where we would have authenticated writes but not authenticated reads (which would need this separate NIP)? if not, what use case would have authenticated reads but not benefit from authenticated writes? |
|
NIP-29 groups, both private and public, would benefit from authenticated writes. DMs would benefit from authenticated reads and writes. Just kind1 notes would benefit from authenticated writes/unauthenticated reads when the user wants to have some control of what they have posted and a little more assurance that deleting notes would be possible, for example. |
|
@vitorpamplona the reason I think it's ok to be generic here is that I just expect all relays to implement this with a two-line check: |
|
What do you think of using a tag like |
|
But this requires changing the code: Most relays will not even realize that this PR is a thing. The default relay behavior of folks who do NOT implement this PR is to accept, not to reject. That's why I proposed changing the serialization: to reject by default on current relays and make it backward compatible (relays don't need to change) and they shouldn't be working with "protected" events without implementing this or the other PR. |
|
Same for all clients: The default behavior for those not implementing this PR is to accept the protected event as a regular event and re-broadcast at will. |
but there's nothing stopping a relay from updating its serialization (which is easy if they are using a nostr library that keeps up with nips) without actually implementing the auth in the PR. so still doesn't accomplish the goal of forcing non-supporting relays to protect these events. |
Nothing will ever force relays to auth correctly. That's not the point. If relays want to fuck around they can do it in a lot of ways. The only point of the serialization change is to make sure only clients and relays that have seen NIP-42 and are minimally aware of the difference between public and protected events can receive and rebroadcast these events. Otherwise, if protected events are just being treated like public events by a majority of clients and relays, nothing in this PR makes any sense. |
yes agree. my point is you can update your nostr library dependency (which has accounted for new serialization) without being explicitly aware of the difference between public and protected events. most aren't writing their serialization code themselves (I think). |
|
Agree. My hope was that libraries requested an extra param (isAuthed: Boolean = false) to the serialization function which fails if the relay is not aware of NIP-42 |
I know. This is obvious and is my base assumption! I don't know why every time I mention this proposal to someone they have to point this out, but I guess I'll rewrite this proposal to make this more explicit.
I'm not sure about that. There are like 3 or 4 big relay implementations. If they implement this, which they can very easily, we give the network a couple of months and suddenly this change is in effect mostly everywhere. I think it's worth trying. If it fails then it fails, we don't lose anything. Changing the serialization would achieve the same result at the end, but at a much bigger cost. It would make writing basic Nostr event creation libraries and using these libraries much more cumbersome for everybody forever. |
I think that is the main difference between our experiences. I don't expect the current public relay codebases to be the same as the relay code that will work with the protected events. In fact, I don't want to change the public relay's code at all.
The difference is subtle but it's real. In this approach, there will be public relays, protected relays, and the ad-hoc relays that don't know the difference between the two because they have not read this PR yet. Those ad-hoc relays will re-broadcast everything protected. Same for clients. There will be clients that deal with the public events, clients that can deal with the protected events and those who don't know about this and will just scatter protected events everywhere. The proposal to change the serialization minimizes the existence of 3rd set of both relays and clients, better protecting events that should be protected. |
agree this is the case. I think where we disagree is whether the better protection is enough to warrant such a drastic change to protocol fundamentals. IMO its not bc the network is always going to be vulnerable to malicious relays that don't follow the rules anyway, and this is the subset I am more concerned about. non-malicious actors that are ignorant of this NIP and accidentally spread protected events will diminish over time. I'd rather wait for that slow process to work itself out than force it with changes in serialization. |
|
I wanna see pull requests adding the |
Don't get me wrong. I think the idea of changing the serialization is crazy as well (as I wrote in the PR itself). I don't think it is a change in fundamentals. To me, it is the start of a second Nostr relay network that is designed for private events (medical information in my case) while not forcing users to centralize in the hospital's or country's private relay. The public network shouldn't change to stay as simple as possible. I would love to find a way to add to the serialization process a step where the relay has to prove one of the pubkeys was authenticated and in order to verify the event. In Clients, the client must prove it has access to the private key of one of the pubkeys listed in the event. That would be a dream. I would allow the event to be verified only on relays that are being used by the listed keys and those listed keys could move the event to any relay or client they want. But that is very far out. |
Working on that. |
fiatjaf
changed the title
["protected"] tag["-"] tag
Co-authored-by: monlovesmango <96307647+monlovesmango@users.noreply.github.com>
70.md
Outdated
|
|
||
| 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). |
There was a problem hiding this comment.
A protected event is an event that can only be published to relays by its author
What if optionally the "-" tag can have a list of pubkeys that are allowed to (re)publish the event (which may have been authored by someone else)?
It would be in line with for example a gift wrap that is authored by a random key but is meant to be "owned" by the receiving user (set on the p tag).
There was a problem hiding this comment.
That would leak a lot of metadata if used with gift wraps, defeating the entire purpose.
Edit: I suppose with the p tag it would be ok. But if the recipient has the message I'm not sure why they would need to re-broadcast it.
There was a problem hiding this comment.
only users authed by the p-tag should be able to download GiftWraps. Anyone can upload.
There was a problem hiding this comment.
What if optionally the "-" tag can have a list of pubkeys that are allowed to (re)publish the event (which may have been authored by someone else)?
I thought of this too actually, I think it would work well. but figured that this NIP can always be extended to add this feature in the future so maybe just shelve it until theres an actual use case. most important thing right now is making rejection of events with "-" tag the default behavior.
There was a problem hiding this comment.
I thought that with e.g. ["-", "<author-pub>", "<receiver-pub>"] the receiver could rebroadcast it to backup for example a local copy to another relay.
But yeah for gift wraps it doesn't make much sense as the receiver could re-wrap the seal. Just an idea but yeah haven't give it much thought.
There was a problem hiding this comment.
Adding authorized pubkeys to the - tag makes sense. Not all use cases of protected events require privacy at that level. And for GiftWraps, the p-tag is already visible anyway and AUTH on the p-tag is what could/should be required for GiftWraps.
|
Implemented here -- with the necessary |
|
how about "Publication Protected Events"? or "Publish Protected Events"? |
|
Whatever is fine for me, but I would prefer a smaller but meaningful name. A single word. |
|
Simple enough and should be useful if relays adopt it. We will add this tag for subscriber-only events on creatr.nostr.wine. |
|
+1. Simple enough to get implemented everywhere quickly. Implemented in chorus here: |
Co-authored-by: monlovesmango <96307647+monlovesmango@users.noreply.github.com>
|
This is by far the simplest solution to the problem, anyone who disagrees is probably a statist. |
|
Strfry PR: hoytech/strfry#100 |
"a simple change can maybe fix the world." Link: nostr-protocol/nips#1030 * fiatjaf (2): implement NIP-70, protected events. update supported nips list.
|
This is live on the damus relay! I will also make a nip70 strfry plugin for https://github.com/damus-io/noteguard |
This adds support for protected events Link: nostr-protocol/nips#1030 Signed-off-by: William Casarin <jb55@jb55.com>
|
NIP70 has been added to noteguard, so you can enable it on an unmodified strfry instance now. |
|
This is implemented in Khatru, Chorus, nostr.wine and relay.damus.io. |
|
Shouldn't the default behavior of dropping events (without auth) be mentioned in nip-01? |
Read about it in the NIP body: https://github.com/nostr-protocol/nips/blob/protected-events-tag/70.md
This is inspired by #1029, there is more discussion there.