Add notifiers nip

[staab]

This is a generalization/update of https://github.com/0xchat-app/0xchat-core/blob/main/doc/nofitications.md with the following differences:

• It uses parameterized replaceable events, which allows for multiple subscriptions to exist at the same time
• It uses NIP 44 encryption rather than NIP 04
• It uses filters rather than ad-hoc targets
• It uses delegated authentication in order to gain access to gated relays
• It uses a different mechanism for pausing notifications and auto-expiring pauses

[vitorpamplona]

Very cool!

Shouldn't bunker_url be encrypted to the service's pubkey?

[vitorpamplona]

Oh.. sorry my bad. I didn't noticed that it is all encrypted.

[water783]

Cool!

• I have no major concerns regarding the event structure and NIP-44 encryption — I support this approach.

• Regarding unsubscribing via deleting the event following NIP-09 — does this mean the push server needs to constantly listen for NIP-09 events to trigger unsubscriptions? While this works, I think a more suitable approach might be to define a separate kind specifically for unsubscription. This would make the process clearer and more efficient.

• About the online/offline notification using the pause_until field — I believe this might not be the most reliable method. If the app crashes or is force-closed, it won’t have the chance to update pause_until, leading the push server to wrongly assume the client is still online and thus skip sending notifications.
  A more robust solution would be to implement a heartbeat mechanism. If the push server doesn’t receive a heartbeat within a certain time frame (e.g., 1 minute), it can safely assume the client has gone offline and resume push notifications accordingly.

[staab]

Regarding unsubscribing via deleting the event following NIP-09 — does this mean the push server needs to constantly listen for NIP-09 events to trigger unsubscriptions? While this works, I think a more suitable approach might be to define a separate kind specifically for unsubscription. This would make the process clearer and more efficient.

Yes, that's the idea. I don't see a downside to using deletes, and the replaceable could also remove its subscriptions. But I also don't mind adding a new kind necessarily. I'll wait to see what others think.

A more robust solution would be to implement a heartbeat mechanism.

I think my approach is equivalent. The client would just re-publish the 32830 every minute, updating the pause_until timestamp. When about to go offline, it could also update the event, removing pause_until to resume notifications, just like in the heartbeat example. But I also don't feel strongly about splitting this into a separate event.

[staab]

@water783 some of my motivation for doing everything in one event is that the pattern of a longstanding, frequently-updated replaceable event feels a lot like re-inventing DVMs, but for subscriptions rather than transactions. It doesn't necessarily have any bearing on this particular use case, but it would be an interesting pattern to experiment with to create a new kind of DVM standard.

[water783]

@water783 some of my motivation for doing everything in one event is that the pattern of a longstanding, frequently-updated replaceable event feels a lot like re-inventing DVMs, but for subscriptions rather than transactions. It doesn't necessarily have any bearing on this particular use case, but it would be an interesting pattern to experiment with to create a new kind of DVM standard.

I see, makes sense.