#asknostr When publishing events to relays, what is the best practice if we are trying to publish to 10+ relays in terms of duplicate messages? For example, with Zap Receipts, I see "Create a nostr event of kind 9735 as described below, and publish it to the relays declared in the zap request." ... in our NWC implementation, we've seen that often there can be 10 or 20 relays "declared".
The most stable and lowest-latency way to do this, at least in my mind, is to try to connect to all of the relays, and then send to these relays after the first relay connects, after the 3rd relay connects, and then after about 80% of the relays have connected.
Because what is the alternative? Wait until all 20 relays connect !? That is going to be too slow, and probably at least 1 relay is down at any time! So we can't wait for all of them to connect!
Right now we've implemented this "wait for 1, wait for 3, wait for 80%" logic, but that means we are sending DUPLICATE Zap Receipts -- usually three in total!
At least in YakiHonne (npub1yzv…rf8q) , I find that it does show more than one zap receipt, even when there are duplicates, but if I refresh the page, then it seems to de-duplicate the zap receipts, so only one shows on the profile.
Rizful.com
npub1jl…pp2kq
2024-12-22 16:18:51
Author Public Key
npub1jluy3twvf338v6zlujzzdhjkzjy8ezj34ksydr8vw8a6jwp89ygshpp2kqPublished at
2024-12-22 16:18:51Event JSON
{
"id": "8a8b37f645010fd99f11bb1ce4b60a4d79e0e6f7cf8362b432a4dd229ce8f700",
"pubkey": "97f848adcc4c6276685fe48426de5614887c8a51ada0468cec71fba938272911",
"created_at": 1734884331,
"kind": 1,
"tags": [
[
"client",
"Yakihonne",
"31990:20986fb83e775d96d188ca5c9df10ce6d613e0eb7e5768a0f0b12b37cdac21b3:1700732875747"
],
[
"t",
"asknostr"
],
[
"p",
"20986fb83e775d96d188ca5c9df10ce6d613e0eb7e5768a0f0b12b37cdac21b3",
"",
"mention"
]
],
"content": "#asknostr When publishing events to relays, what is the best practice if we are trying to publish to 10+ relays in terms of duplicate messages? For example, with Zap Receipts, I see \"Create a nostr event of kind 9735 as described below, and publish it to the relays declared in the zap request.\" ... in our NWC implementation, we've seen that often there can be 10 or 20 relays \"declared\".\n\nThe most stable and lowest-latency way to do this, at least in my mind, is to try to connect to all of the relays, and then send to these relays after the first relay connects, after the 3rd relay connects, and then after about 80% of the relays have connected.\n\nBecause what is the alternative? Wait until all 20 relays connect !? That is going to be too slow, and probably at least 1 relay is down at any time! So we can't wait for all of them to connect!\n\nRight now we've implemented this \"wait for 1, wait for 3, wait for 80%\" logic, but that means we are sending DUPLICATE Zap Receipts -- usually three in total!\n\nAt least in nostr:npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q , I find that it does show more than one zap receipt, even when there are duplicates, but if I refresh the page, then it seems to de-duplicate the zap receipts, so only one shows on the profile. ",
"sig": "82be10c5c9b21e83ceb6040a486569a43630c64bf448a557ebe418ff908c33e01e12ea78c00f52124f364fe79f356e1ceee2799e6d2990435539924ae2bb3221"
}