| 1 Jun 2025 |
 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 |
| Arian | Some interesting things I noticed looking at Fastly dashboard:
We have 0 requests using TLS 1.3. They’re all using TLS 1.2. Is this some limitation in the nix codebase in how we setup openssl?
half of the requests are HTTP1.1 and the other half HTTP2. I would expect way more (maybe even all) to be HTTP2. Where is all that HTTP1.1 traffic coming from?
| 20:39:52 |
 hexa | our config does not support tls1.3 | 20:48:04 |
| hexa | it supports 1.1 and 1.2 and all clients use 1.2 | 20:48:11 |
| hexa | at least the last time I checked, which was early januar | 20:48:29 |
| hexa | * at least the last time I checked, which was early january | 20:48:30 |
| hexa | interesting profiles would support h2/h3 with 0rtt, but the offered ones lack ipv6 | 20:49:02 |
