Subnostr

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.

Reply to this note

Please Login to reply.

Discussion

PABLOF7z 2y ago

yeah, I think this can be built with caching primitives, where your app-level code doesn't need to concern itself with this but transparently receive this functionality

it's one of the reasons why I built #[2], because this is a problem that needs to be addressed, and having a more "definite" source which you can ask for these type of data might be useful

but yeah, apps need to have this stuff abstracted away; we can't expect all apps to reinvent these things