That's why it's caching data. People that last posted days a...

Leo Wandersleb

npub1gm7tuvr9atc6u7q3gevjfeyfyvmrlul4y67k7u7hcxztz67ceexs078rf6

hex

ececab68dd69ccd0e9ff336264421ecc35d6c88ac0cd24a30f36da5fb634ae9f

nevent

nevent1qqswem9tdrwknnxsa8lnxcnygg0vcdwkez9vpnfy5v8ndkjlkc62a8cprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsydl97xpj74udw0qg5vkfyujyjxd3l706jd0t0w0turp93d0vvungrntz5j

Kind-1 (TextNote)

2026-04-27T13:06:38Z

↳ 回复 Cody (npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl)

Honestly, it’s a really useful view, but Jumble might struggle to fully take advantage of it. You probably won’t be able to fetch notes from all follo...

That's why it's caching data. People that last posted days ago - most people - can be backfilled slowly and cached indefinitely. nostr:npub1q3t5ttqwjzjrv9q68twaj4t4ct4dg7mp8azjsu5rukqzlalan87s57u7l3 was last active 48 days ago so unless I manage to poke him into action, his line in my "Pulse" won't change any time soon. In other words, if you store per user 10 latest events and check back about every day, you don't need more connections than the "24h Pulse" as it's old events anyway. IDB can easily store 1000 follows times ten events at all time.

My current code state still strains the connections so liking stuff while it's bombarding the relays is broken but I know I can get it there.

I would load the 10 events per user in the background even before they go to the Pulse view. Your caching strategy throws away older events that happen to be the last events from authors. I would never throw away those above mentioned events or profile information. Profiles only ever get updated when we happen to come across a newer version of the event.

原始 JSON

{
  "kind": 1,
  "id": "ececab68dd69ccd0e9ff336264421ecc35d6c88ac0cd24a30f36da5fb634ae9f",
  "pubkey": "46fcbe3065eaf1ae7811465924e48923363ff3f526bd6f73d7c184b16bd8ce4d",
  "created_at": 1777295198,
  "tags": [
    [
      "e",
      "7bcf2be158b1310d6f6b1135f31c1aeecc3c13e70ecc136da4e194f05d24727e",
      "wss://pyramid.fiatjaf.com/inbox",
      "root",
      "46fcbe3065eaf1ae7811465924e48923363ff3f526bd6f73d7c184b16bd8ce4d"
    ],
    [
      "e",
      "ae6f48b7dd6343741135683f273ad18d811d2a8a6dc12c0c3c1ce9d8a422705f",
      "wss://relay.primal.net/",
      "reply",
      "8125b911ed0e94dbe3008a0be48cfe5cd0c0b05923cfff917ae7e87da8400883"
    ],
    [
      "p",
      "045745ac0e90a436141a3addd95575c2ead47b613f45287283e5802ff7fd99fd"
    ],
    [
      "p",
      "8125b911ed0e94dbe3008a0be48cfe5cd0c0b05923cfff917ae7e87da8400883"
    ]
  ],
  "content": "That's why it's caching data. People that last posted days ago - most people - can be backfilled slowly and cached indefinitely. nostr:npub1q3t5ttqwjzjrv9q68twaj4t4ct4dg7mp8azjsu5rukqzlalan87s57u7l3 was last active 48 days ago so unless I manage to poke him into action, his line in my \"Pulse\" won't change any time soon. In other words, if you store per user 10 latest events and check back about every day, you don't need more connections than the \"24h Pulse\" as it's old events anyway. IDB can easily store 1000 follows times ten events at all time.\n\nMy current code state still strains the connections so liking stuff while it's bombarding the relays is broken but I know I can get it there.\n\nI would load the 10 events per user in the background even before they go to the Pulse view. Your caching strategy throws away older events that happen to be the last events from authors. I would never throw away those above mentioned events or profile information. Profiles only ever get updated when we happen to come across a newer version of the event.",
  "sig": "39522b58bee09a5d5416c514de68c9eb5a98e53c0a3352562b4c3c27774fa3d8597f06895543caa2394901f9e3cac16fa6af1671c77ace71783804b0e02cf3e5"
}