Don't let NIP-26 delegatee publish old events

[arthurfranca]

I imagine that delegator doesn't want delegatee to publish old events (long after the created_at condition is over).

[arthurfranca]

The text is probably longer than it could be. What I wanted to says was this from @jb55: prevent delegatee from publishing backdated events. The exception would be authenticated delegator (not delegatee) moving old events from one relay to another.

[vitorpamplona]

Only relays should have this protection? What if Clients receive the event from non-NIP-26 supported relays? Should they also apply the rule? Otherwise, the Client that receives through non-supporting relays is not consistent with the Client that used the NIP-26 supported relays.

The exception would be authenticated delegator (not delegatee) moving old events from one relay to another.

You should add the exception to the text then. Ups, it was already there.

[arthurfranca]

What if Clients receive the event from non-NIP-26 supported relays?

They won't receive. Non supporting relays seeing { authors: ["<delegator>"], kinds: [1] } won't add delegatee's events to the response.

[vitorpamplona]

They won't receive.

They will if they are following the delegatee, or if they are on Global, or if the chat group includes one, or if the Community includes one, or if it's on a notification (a like by a delegatee representing the delegator), or if it is a quoted post, or a following a hashtag, geohash, list-based feeds, etc.

[arthurfranca]

Yes. I guess the more relays supporting NIP-26 the better it works. Imo in the cases you mentioned the client should accept the delegated events as valid.

[vitorpamplona]

I guess the more relays supporting NIP-26 the better it works.

It also means that it only takes one relay to create false positives: breaking revocation rules many brands could rely on.

False negatives (when the client doesn't implement NIP-26 and thus the delegatee is never shown as speaking on behalf of the delegator) are fine. People will miss things, but they will never be misled.

False positives (when the client does implement NIP-26 and wrongly shows the delegatee has the authority to speak on behalf of the delegator) are not fine. People will be misled by somebody that the delegator clearly specified to not have that authority anymore.

[arthurfranca]

Imo the question when looking at this PR should be: Does NIP-26 gets better with this addition?

Your comments sounded to me more like "We should deprecate NIP-26 cause it is flawed" instead of "No" to the question above.

[vitorpamplona]

I don't think it is better because it creates false positives. It creates expectations that cannot be met by clients and inconsistencies that are just bad for Nostr.

[arthurfranca]

I will try another approach