kjeldahl on Nostr: When writing my first Nostr apps I had recurring issues with notes disappearing and ...
When writing my first Nostr apps I had recurring issues with notes disappearing and user metadata and profiles not being up to date. It took a while, but eventually I figured out how relays work, and how it's tied together with user profiles and other events containing relevant data (preferred relays etc). I'm still not sure what the "ideal" way to retrieve initial user data etc is. Which relays do I query? Do I actually have to implement a "Nostr crawler" that continuously monitor events to detect relays, and asking relays more or less at random for data that I have been unable to retrieve? Besides the relay issue, which can be solved by some more or less hardcoded list of popular relays, most things are working great now. I typically cache events when found. Events that can be "renewed" I periodically try to refresh (pubkey+kind), but client never have to wait. When clients retrieve something that can theoretically be updated, I return the last known value. But if some value haven't been tried to be re-fetched in a while, I put it in a queue to be re-acquired by another "worker" process. So clients will never have to wait for anything to be fetched from relays, unless it's something that has never been seen before of course. There's no manual for how this works AFAIK, so there are many pieces to work out by yourself. You need some ability and lots of curiosity IMHO.
Published at
2025-01-13 19:10:44Event JSON
{
"id": "48ec5b2c133a8ae434e856bf54564f48120dd953e4b28e6e491d76c83e416e0d",
"pubkey": "2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f",
"created_at": 1736795444,
"kind": 1,
"tags": [],
"content": "When writing my first Nostr apps I had recurring issues with notes disappearing and user metadata and profiles not being up to date. It took a while, but eventually I figured out how relays work, and how it's tied together with user profiles and other events containing relevant data (preferred relays etc). I'm still not sure what the \"ideal\" way to retrieve initial user data etc is. Which relays do I query? Do I actually have to implement a \"Nostr crawler\" that continuously monitor events to detect relays, and asking relays more or less at random for data that I have been unable to retrieve? Besides the relay issue, which can be solved by some more or less hardcoded list of popular relays, most things are working great now. I typically cache events when found. Events that can be \"renewed\" I periodically try to refresh (pubkey+kind), but client never have to wait. When clients retrieve something that can theoretically be updated, I return the last known value. But if some value haven't been tried to be re-fetched in a while, I put it in a queue to be re-acquired by another \"worker\" process. So clients will never have to wait for anything to be fetched from relays, unless it's something that has never been seen before of course. There's no manual for how this works AFAIK, so there are many pieces to work out by yourself. You need some ability and lots of curiosity IMHO.",
"sig": "8ae65f49952fbc67a58de4545ff91d1a0a90bd14b546139ff612127e7a5be6467d89fbcc33945eaa7504818ecce1a22e262c10fafdf4b42d6c1d169db6748680"
}