teatwo on Nostr: Event design, especially with UX considerations across the signer provider ecosystem. ...
Event design, especially with UX considerations across the signer provider ecosystem.
Attaching an `on` listener to `window.nostr` seems problematic, because `window.nostr` is not a persisted object, but an object injected by a specific provider. For example, when the user wants to switch or multisig signers and the i.e. `providerChanged` or `multisigUpdated` is emitted, `window.nostr` seems like an inappropriate place.
If we consider such case, is it better to only define the standard event name, and not where to listen?
Published at
2024-11-01 09:30:38Event JSON
{
"id": "70979a4d784fd6202d7c71bb89e1b135f9e1285b37ed08d60802bef91bfe95cf",
"pubkey": "3589b793b977c4f025175afd792e7c51d26ef683b45cbc66c56c4d14ad53847e",
"created_at": 1730453438,
"kind": 1,
"tags": [
[
"e",
"a26d039f4e0d120d5e8c1db964a26c0feb66a540312f5417bb26fcac4a68dd06",
"",
"root"
],
[
"e",
"278e96863fb1a679a1fbb31fa0c1276312b7525d5aab50c63392c243aa1a6f19",
"",
"reply"
],
[
"p",
"3589b793b977c4f025175afd792e7c51d26ef683b45cbc66c56c4d14ad53847e"
],
[
"p",
"330fb1431ff9d8c250706bbcdc016d5495a3f744e047a408173e92ae7ee42dac"
]
],
"content": "Event design, especially with UX considerations across the signer provider ecosystem.\n\nAttaching an `on` listener to `window.nostr` seems problematic, because `window.nostr` is not a persisted object, but an object injected by a specific provider. For example, when the user wants to switch or multisig signers and the i.e. `providerChanged` or `multisigUpdated` is emitted, `window.nostr` seems like an inappropriate place.\n\nIf we consider such case, is it better to only define the standard event name, and not where to listen? ",
"sig": "37c404f493525604d19c8d6cc70e48000b1925665c18e43360d350356f51f49840146bbd72fd179465599ae5fa79448d29c831696442a037618e7ab526a8a569"
}