| 1 Jun 2025 |
 Vladimír Čunát | It's normal to cache even over larger spaces than 2^160. | 17:48:20 |
| Vladimír Čunát | (I do that at work.) | 17:48:37 |
 edef | but a bloom filter only kicks the can down the road, it only answers "probably present", etc | 17:49:30 |
| edef | you'll improve p95 latency but not p100 | 17:49:49 |
| edef | it is an improvement, but the actual hashset fits in memory easily | 17:50:28 |
 Arian | Our p100 times probably pretty bad now too. S3 fetch across the continent is not particularly fast | 17:51:18 |
| edef | this is true, yes | 17:51:32 |
| edef | sticking the narinfos in postgres would be easy and get us a bloom filter with a CREATE INDEX | 17:52:13 |
| edef | i forget what backends we currently have for the snix narinfo service but "just a database" is the straightforward answer | 17:52:59 |
| edef | an object store full of text files is just an awkward answer | 17:53:16 |
| Arian | What if we only do my idea for Nars and not narinfos | 17:53:36 |
| Arian | Would still cut down bandwidth and keep 404s "fast" | 17:53:53 |
| edef | In reply to @edef1c:matrix.org
so like, for the most part you can do anything to the NAR datapath sure, that is fine ^ | 17:54:00 |
| edef | all i aim to point at is that the narinfo datapath is uniquely sacred | 17:54:24 |
| edef | it is not where the heavy lifting is in terms of data volume | 17:54:32 |
| edef | nar requests are essentially guaranteed to hit (you were given the path in a narinfo, it will exist) and don't need to be particularly low-latency | 17:55:51 |
 flokli | I still think it'd be very worthwhile to tap into narinfo uploads, so we can continuously update our data on narinfos that doesn't involve scraping millions of text files. | 17:58:22 |
| edef | yes | 17:58:30 |
|  mjolnir unbanned  @mightyiam:matrix.org. | 22:58:05 |
| 2 Jun 2025 |
|  @deeok:matrix.org joined the room. | 08:18:33 |
 Jeremy Fleischman (jfly) | infinisil, I'm going to spend some time hacking on https://github.com/NixOS/infra/issues/700. I'll dump any progress onto this draft PR: https://github.com/NixOS/infra/pull/705 | 16:29:16 |
 infinisil | In reply to @jfly:matrix.org
infinisil, I'm going to spend some time hacking on https://github.com/NixOS/infra/issues/700. I'll dump any progress onto this draft PR: https://github.com/NixOS/infra/pull/705 Nice! Want some company? Otherwise I'm also available async :) | 16:35:44 |
| Jeremy Fleischman (jfly) | if you're available! https://meet.jit.si/freescoutingggggggg | 16:36:37 |
| infinisil | Redacted or Malformed Event | 19:42:45 |
| infinisil | Jeremy Fleischman (jfly): We might need to do some more: https://public.infinisil.com/2025-06-02_21-43.png | 19:44:52 |
| infinisil | (the bottommost error is probably just because there are no background jobs, though the error message sucks if so) | 19:47:01 |
| Jeremy Fleischman (jfly) | ok, good to know!
Nina predicted the modules permissions error in https://cyberchaos.dev/e1mo/freescout-nix-flake/-/issues/1. That's a good reminder that we should try out a module. | 19:58:29 |
| Jeremy Fleischman (jfly) | * ok, good to know!
Nina predicted the modules permissions error(s) in https://cyberchaos.dev/e1mo/freescout-nix-flake/-/issues/1. That's a good reminder that we should try out a module. | 19:59:03 |
| Jeremy Fleischman (jfly) | files https://cyberchaos.dev/e1mo/freescout-nix-flake/-/issues/2 for the public/storage issue | 20:03:59 |
| Jeremy Fleischman (jfly) | and https://cyberchaos.dev/e1mo/freescout-nix-flake/-/issues/3 for the .env perms issue | 20:05:59 |
