Nostr Web Client

> instead of returning events, the filter and fulltext search endpoints are specced to return simple lists of events in whatever expected sort order.

In our case that would work poorly. Kind:0s are replaceabe, so if we returned the list of kind:0s sorted by the npub's rank, the result can hardly be reused later. One of the kind:0s might become outdated the next time you want to use it.

We care about this because it's quite a lot of work for generating these responses. That's why we return hex pubkeys sorted by the npub's rank. The rank of these pubkeys is stable over time except for edge cases like a key hack.

I think our case is different enough from the normal use of relays. For most other cases, returning event IDs is a solid choice I think.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 10mo ago

this is why i'm prompting you to think about what you think a helpful API for your task would look like, because after i'm done making the basic replacement for filter search and HTTP for everything else using nip-98 and optionally JWT, this is the kind of thing i can see becoming useful

right now, #realy is a bit messy in the sense that things are all still a bit jammed together in ways that they shouldn't be, and some things are separated and replicating things in ways they shouldn't be

the ideal situation is where you can define a simple single source file that specifies what parts are available, so eg, we have a standard NIP-01 implementation, and added to that is a spider that farms the whole nostr network for this data, and then it exposes protected endpoints that yield search results that precisely fit the needs of vertex

so, yeah, from what you are describing, right off the top of my head i can picture something like an endpoint called `/directory` which takes a parameter of the last-updated-timestamp that you are interested in (as your database already has everything to that moment) and it spews back all of the event kinds newer than that in one big shebang and that funnels into your graph generation pipeline

Reply to this note

Please Login to reply.

Discussion

Pip the WoT guy 10mo ago

yeah, DVMs can all become/be morphed into standard http APIs.

I guess one loses the simplicity of having only one communication protocol (websocket) though.