mikedilger on Nostr: I'm trying to solve a problem and I thought I'd ask for help. I've got a website ...
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 Yuki Kishimoto (npub1drv…seet)
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?
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 Yuki Kishimoto (npub1drv…seet)
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?