Signed Filters

[vitorpamplona]

This is a much-needed approach for Push Notification systems. Push Servers connect to many, if not all, relays on behalf of the user to download events that cite the user and push them down to applications.

The goal here is 2 fold:

• Allow subscriptions for multiple users in the same connection.
• Get rid of the user auth round trip since the user might/will not be online.

The same approach can used by the user's inbox or personal relays to query other relays in the search for events they are supposed to have but don't.

I don't know if this is the right way to do it, but it is what I am testing at the moment.

Read here

[fiatjaf]

I don't like this, I think AUTH achieves the same thing in a simpler and more flexible way.

Allow subscriptions for multiple users in the same connection.

I don't know if this is a problem. You can always open multiple connections, and what are the use cases for having the same process listen to things on behalf of many users? A custodial Nostr server of some sort?

Get rid of the user auth round trip since the user might/will not be online.

If a user is delegating listening to relays to a third party it is better to come up with a way to tell that relay that the third party will be allowed to subscribe to the user's events. Incidentally this also fixes the previous point as the third party can be allowed to subscribe to multiple users' events.

[vitorpamplona]

I think AUTH achieves the same thing in a simpler and more flexible way.

This is not a replacement for AUTH. It's a way to use AUTH by a third party.

I don't know if this is a problem.

This is a problem. Amethyst Push System has to authenticate for ~145,000 active users of the notification system. There is no way we can open 145K connections to each of the 3000 relays out there.

If a user is delegating listening to relays to a third party it is better to come up with a way to tell that relay that the third party will be allowed to subscribe to the user's events.

This is how we tell them.

[fiatjaf]

This is a problem. Amethyst Push System has to authenticate for ~145,000 active users of the notification system. There is no way we can open 145K connections to each of the 3000 relays out there.

It sounds like you're doing something very wrong here.

This is how we tell them.

This is a very bad way of telling them. A single event published by the user saying something like "consider AUTH from <amethyst-server-pubkey> as if it was mine" is much better.

[vitorpamplona]

It sounds like you're doing something very wrong here.

Well, I have been doing it since Feb last year, so...

A single event published by the user saying something like "consider AUTH from as if it was mine" is much better.

No that is terrible. It grants too much power/trust to the server. You want to give access to a very specific filter set and not a generic delegation.

[mikedilger]

I'm not against this proposal. It is a form of delegation, and being more specific about what is being delegated is a good thing IMHO so that as Vitor says, the middle-man can only do what the user authorized them to do.

Amethyst Push System has to authenticate for ~145,000 active users of the notification system. There is no way we can open 145K connections to each of the 3000 relays out there.

It would be far easier for the phone to pull from a small set of inbox relays. But you do you. This isn't a nostr feature I will be using.

[vitorpamplona]

It would be far easier for the phone to pull from a small set of inbox relays.

Yes, but it assumes everyone implements the outbox or the inbox model. Right now majority of the notifications are not on people's inbox relays. If one single client decides to not forward the notification to the user's inbox relays, that notification won't be shown. To me, that is a bug. Since I can't control all clients, a method like this is a necessity.