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

Reply to this note

Please Login to reply.

Discussion

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.