I'm trying to solve a problem and I thought I'd ask for help.

I've got a website using a WASM framework (dioxus) that gives me the ability to do async functions to fill in part of the web page. The web page renders immediately with either a placeholder or the result. I'm also using `nostr` and `nostr-sdk` from nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet

On one page I have a long list of events each by potentially a different npub. But initially I don't have any of their metadata. I want that page to fetch and fill in the metadata for all these people. This is a very typical (I'd say necessary) part of any web-based nostr client. I haven't done it yet though, I've done a desktop client.

The component on the page that renders the metadata is calling into this async function. Remember there are many of them, so many components are all nearly simultaneously calling into this async function, generally with different pubkeys but sometimes with the same pubkey.

The async function needs to either return metadata, or eventually return a failure.

A simple first idea that mostly works is to independently spin up a client and use it to two-step fetch the NIP-65 list from the discovery relay and then fetch the metadata from the user's relay. But this creates tons of clients and connections, saves nothing (no caching) and is generally regarded as a "bad idea."

The next iteration on the idea is to store a map from URL to Client and keep the client's alive. Then I can fetch the client (creating if missing) and fire off a new REQ. But this is still bad because I'm doing one request per pubkey and relays hate me saying I'm making too many requests.

So really I need to batch these somehow (multiple pubkeys per request). And to cache the results. And to be aware when some other thread is already doing this pubkey (and yet wait on it's result). And solving all of that simultaneously has been.... difficult.

I can have a map with pubkey as the key. And I can have the value be an enum either Fetching or Metadata (and missing from the map means it is not fetching). But no easy way to async wait on a map entry to show up. Also no easy way to wait a bit and then batch the multiple requests and avoid all race conditions with other threads doing the exact same thing (although that I can solve). Anyhow, the whole thing seems rather difficult and yet it must be solved by ... every web based nostr client out there... right?

From a request perspective you want to wait 50 or 100 msec before sending out a request so that at least some of the requested ids can queue up. It's going to take a few hundred msec for the first SSL connection anyway, so a little delay is valuable and hard to notice.

What you do when the data comes back depends on how you're writing the UI. You probably don't want to apply results one at a time because it will likely cause things to needlessly re-render, but how you apply multiple updates in the same render is framework dependent.

Reply to this note

Please Login to reply.

Discussion

No replies yet.