nostr:npub1xv8mzscll8vvy5rsdw7dcqtd2j268a6yupr6gzqh86f2ulhy9kkqmclk3x what do you think of adding this to alby? https://github.com/nostr-protocol/nips/pull/1174
Discussion
Uh, so for example zap splits could be done with one click instead of multiple confirmations by the user?
what does it solve? we put effort in to be available as early as browsers allow on load.
and this works:
https://gist.github.com/bumi/6bd2c76b8a83170e2471da50a79aec97
and this will bring UX problems like how to deal with prompts.
I find `window.nostr` not available very very often, basically a nostr webapp must always handle retrying things until window.nostr becomes available. In fact, NDK's NIP07 signer builds this in; but what this NIP proposes is far cleaner.
I'd pose that having a queue is even better for UX, instead of showing a bunch of prompts you can ask all of them at the same time.
which window.nostr implementation is not available very often?
can you show where?
It’s a race condition, so it doesn’t happen all the time, I don’t have a URL to point to since an app that doesn’t handle it already for you is essentially non-functional, but it’s a known issue that apps need to handle.
I use alby, so I’ve observed this with it but people using nos2x report the same. I guess particularly when loading other extensions the context of the page runs before the extension
if you still see this, point me to a page where this happens.
Quite a long time ago this was optimized and with MV3 browsers I think also made this easier.
There was the discussion of adding an event similar to how it actually works with DOMContentLoaded and other events which I think would be the cleaner way if something is really needed.
and isn't it easy to do this fully on the client side?
for example like this: https://gist.github.com/bumi/050a29cef2f6f9f9d7960d834104890a
making a queue and wait a but until window.nostr is enabled?
I think the window.nostr should be as stupid as possible to also make it easier for other ways to implement it. (e.g. nsecbunker and such)
syntactic sugar and such nice things I would try to put in the client -maybe even some library.
to me this is throwing complexity at something and not solving the seemingly fundamental issue.
now suddenly there would be multiple ways on how calls are made and it adds implementation complexity at both ends.
