what do you mean?

Reply to this note

Please Login to reply.

Discussion

> hat really solve the key repetitive utility functions I use often.

Your NDK may solve it. I haven’t taken a look yet.

I guess things like relay management, where it reconnects as needed. Or, maybe it has a relay pool of 5, and only connects as-hoc to publish or request a single event. Then WS close.

Somehow tracking per event per relay, if a publish was successful, relay said it was a dupe, timed out, errored or relay never connected.

Even using the window.nostr is great - but you can’t use it at first because it hasn’t loaded. So you need a way to test if it has loaded yet. UI can depend on it being found/loaded - and obviously calling functions too soon fails.

Maybe simple stuff too like remembering loaded relays for a user. If I refresh the page, why do I need to load from extension or kind 10002 so soon.

Things like maybe using shared state across tabs. We can share the relay connections, instead of new ones per tab - fairly sure this is possible.

And even things like if I provide a addr with relay suggestions, try query them first, then fallback to others. Or when I query for an event by id, can I kill/ignore all the other results that were too slow.

Maybe optional event signature verification for relay responses. Sometimes you want it sooner and sometimes perhaps delayed for performance for different processing.

Perhaps some optional pubkey cache.

That’s a start of some ideas anyway.