feat(notify): message idempotency/storage & webhook refactor

[chris13524]

• Add id to notifyMessage (ensures message ID can be used for client deduplication, and also provides method to acknowledge, send read receipts, etc.)
• Add notificationId to /notify endpoint, which makes the endpoint idempotent
• Allow sending multiple notifications in a single network request to enable use cases where each account may gets different notification content. Scaling should be unchanged.
• Add webhook authentication & idempotency
• Correct the current specs with <project-id> parameter
• Add /v1 prefix

Send Notification and Notification Status APIs subject to change upon discovering real-world implementation scalability challenges. For example, it may make sense to respond with not-subscribed, wrong-scope, and rate-limited in the initial request, rather than requiring a second call to get this information.

Potential TODOs:

• Add how rate limiting is implemented
• How queueing is implemented

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
walletconnect-specs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 8, 2023 3:03pm

[Elyniss]

Shouldn't be nullable

[chris13524]

@Elyniss it should because this is the Notify API endpoint. null will be translated to "" by the Notify Server

[geekbrother]

Do we really need to give the ability to provide the ID for a new notification? For me, server-generated IDs look more consistent, and does the client need this ability? cc @chris13524

[chris13524]

The primary purpose of this ID is actually for idempotency.

We can have an idempotencyKey field instead, and require the client to read the response in order to call the status endpoint. But I figured it's a slightly nicer API for the caller to be able to specify their own IDs in order to avoid storing the response to their database if they already have notification IDs on their end.

In my approach this notificationId would be dapp-facing only, unique key being separate per-dapp, and the pk of the database would still be a server-generated UUID. Happy with either approach really, but we need idempotency.

[devceline]

With the queuing behavior now, are consumers of this API expected to query all the messages they sent until they either get published or some of the error statuses?

Not sure if I missed something here

[chris13524]

are consumers of this API expected to query all the messages they sent until they either get published or some of the error statuses?

Yes, but only if they want to know the status. However I suppose this is polling so would be good to have a webhook option for this as well.

[devceline]

yes - I think a webhook option would make sense. Polling would be absurd for all the different notification ids