Subnostr

> 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.

Reply to this note

Please Login to reply.

Discussion

PABLOF7z 2y ago

yeah, NDK aims to do all of this

discoverability is one of the core goals and ease of developer's life a second goal

with NDK, instead of writing to a relay pool (which is a dumb idea imo), it writes to a relay set, which is an ad-hoc subset of the existing relay pool (which might have the explicit relays, or have other relays it choose to connect to)

connecting to a relay to perform an action and disconnecting (if it makes sense) is also something that it'll do.

it's still early days, but this is why I'm making NDK

Blake 2y ago

The other key use case I have is effectively batching. Where you may want to lookup N profiles and understand which profiles you need to try fetch again from different relay/s, as didn’t return results - you got EOSE before a match for M query keys. Obviously max retries or attempts is needed as there may not be any results to find.

This is most useful when querying for updates against local cached event state. Or even against what your DB has.. like refreshing user profiles.

PABLOF7z 2y ago

caching is also provided by ndk via adapter (right now I only wrote a simple redis-backed adapter); but caches can also be in-browser (right now I have an NDK adapter for Zapstr that I need to extract into it's own package)