Farcaster Devs

Building @warpcast and @farcaster / dad / like to read, cook, ski, code

@deodad Pls help:

> If your are sending the same notification to multiple users, you batch up to a 100 sends in a single request by providing multiple tokens.

Should each batch use a different notificationId or the same?

Dad, geek, conversation liquidity provider. vrypan.net (home), @l--o--l (fun). devcoin:$lemon3

these are request level idempotency keys so different, will triple check and add a clarification to the docs

If they have to be different, it adds complexity to the sender, as they have to keep track of all the notificationIds that correspond to what they consider a single notification ("I want to send this to all my subscribers").

It may be a good idea to rethink this part. For example, I would like to be able to re-send the same notificationId with updated content.

Or at least rename it to requestId.

BTW, there's nothing stopping an other app accepting more than 100, say 1000, without breaking something. And then we will have requestIds all over the place, some corresponding to 100s, some to 256s, etc.

(Let's forget the resending part, it's too much of a change, my fault for mentioning it here.)

My issue with with the current design:

The spec is designed (and explained, see bellow) from the perspective of an application like WC. For you, a notification is something that must be presented to up to 100 users, you need a Id, and you call it notificationId. You don't care if this id identifies the same text or not. 

Otoh, from the sender's perspective, a notification is something that must be sent to their users, and a "notificationId" is usually something that identifies the message to be sent (especially if it's a broadcast).

There is a solution and I think it should be mentioned in the docs: notificationId is up to 128 characters, which means it is easy to have an "id-batchNumber" notificationId, that works both for WC (you get a different id) and the sender (have a single id for what they call a notification, and append the batch number to make each batch unique).

a bit confused by the last part  about resending

but i think what you’re suggesting is that we make notificationId-fid the idempotency key?