gchristensen changed the topic of #nixos-chat to: NixOS but much less topical || https://logs.nix.samueldr.com/nixos-chat
<infinisil> Logarithmic maybe even
<infinisil> Now I want like a status bar that shows such a timeline stretched over the whole screen width
<infinisil> That would be neat
<__monty__> Definitely neat.
<__monty__> I stopped wearing a watch exactly to be less obsessed with checking the current time though. Works wonderfully for me.
slack1256 has joined #nixos-chat
<infinisil> Hmm, similarly, what if there was a watch that's just really long and thin, with a display showing that same timeline
<infinisil> So the only information you get is whether something is coming up (and maybe what it is) soon
<infinisil> But you won't have an exact time
<__monty__> That sounds impractical. I'll let you muse on it : )
__monty__ has quit [Quit: leaving]
<infinisil> I only really check time for events, so that might work well
<infinisil> The status bar idea is definitely something I want now though..
<aleph-> Oh boy. Who still likes NNTP?
<samueldr> isn't NNTP just a protocol?
<samueldr> I mean, is there something more to your question?
<aleph-> Apparently there's a NNTP integration for https://lobste.rs you can run now.
<samueldr> nice
<samueldr> tavis ormandy wrote an NNTP frontend for reddit too
<samueldr> there's the D lang forums that are/were also browsable through NNTP
<samueldr> ah, inspired by said reddit frontend lol
<samueldr> I'm wondering if mailing lists can/are frontend with NNTP
<samueldr> might make them less cumbersome to use
<samueldr> >> Read-only nntp gateway
<samueldr> for public inbox
<samueldr> imap too, that's wild!
<samueldr> I guess that means you could use a mail client by replying from the other account to mails received through that interface
<samueldr> considering mailman's gzip is basically a `cat` of all plaintext messages... I guess it should be possible to "rehydrate" them into an NNTP interface
<samueldr> mailman supports *forwarding* to NNTP built-in, but AFAICT nothing from just using an instance's data
<samueldr> the good thing, too, is you know the archives in the past won't change
lunc has quit [Ping timeout: 246 seconds]
<samueldr> oh right, gmane... that was a thing that's not a thing anymore, wasn't it?
<samueldr> (not exactly, there is apparently gmane.io which is an NNTP interface to lists)
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-chat
<gchristensen> can jq parse a string as json within an expression? hmm
<gchristensen> yes, fromjson, neat
<gchristensen> tailscale is nice ...
cole-h has joined #nixos-chat
rajivr has joined #nixos-chat
<aleph-> Yep
<elvishjerricco> Is tailscale just "WireGuard, but we did all the annoying stuff for you"?
<gchristensen> yeah
<gchristensen> so ... I guess I use that now instead
<elvishjerricco> From their FAQ: "Tailscale might bounce your encrypted packets through one of our relay servers scattered around the Internet."
<elvishjerricco> That's a bit annoying
<elvishjerricco> Not an issue since it's encrypted
<elvishjerricco> Wish they would have explained when that happens though
<elvishjerricco> I'm currently using tinc because it's decentralized, totally self hosted, it's a mesh network, and it has NAT traversal
<elvishjerricco> Do WireGuard/tailscale do all that?
<aleph-> Not mesh yet.
<aleph-> Otherwise yes
<elvishjerricco> aleph-: So everyone has to know everyone else's public IP?
<aleph-> For plain wg? Trying to remember...
<aleph-> I usually do it site to site.
<aleph-> So a node on my core router at home so all my clients can access the network when remote.
<aleph-> I believe they need to yes.
LnL has quit [Ping timeout: 264 seconds]
LnL has joined #nixos-chat
<Ashy> not every node, just one public IP with forwarding enabled is enough
<Ashy> so long as at least that is available they'll all be able to find each other
<Ashy> even as the dynamic IPs change
<Ashy> oh I'm talking about wireguard, tailscale probably makes that even easier
<danderson> elvishjerricco: tailscale is a mesh of wireguard tunnels, with keys tied to SSO and NAT traversal.
<danderson> relay servers: they get used when NAT traversal fails (we have a whole blog post on how nat traversal works and when that might happen), and to exchange some metadata to help NAT traversal (basically "hey start probing me now, here's my ip:ports")
<danderson> tailscale isn't decentralized. There is a central coordination server that handles propagating network information between nodes. Tailscale the company runs that, though enterprises can pay us for an on-premises deployment.
<danderson> so, if self-hosting is a big deal to you, tinc is probably a better fit.
<danderson> aside from that, yeah, tailscale is in the same vein as tinc, zerotier, and a few others: a full mesh of tunnels between your machines, with some niceties built on top (automagic DNS names, strong identity for connections in the mesh, device sharing between users, central ACL configs...)
<elvishjerricco> So WireGuard itself doesn't do mesh or NAT traversal, but tailscale implements those things on top of WireGuard. Cool
<danderson> yup, that's right
<danderson> oh, and SSO. WireGuard works similar to basic SSH: you generate keypairs, statically configure each end.
<danderson> tailscale makes you log in with some SSO provider (e.g. gmail, okta, office365...), and ties that identity to the keypairs used for communication
<danderson> The appeal for that is mostly companies, because it means their VPN automatically ties into their existing central auth system
<danderson> But under the hood, all we're doing is: the client sends a pubkey to the coordination server, coordination server says "do an OAuth dance to tell me which human you are"
<danderson> and once you've done the dance, coordination server goes "ok, so this pubkey belongs to danderson@tailscale.com, I'll tell all the other members of the tailscale.com network how to connect to it"
<danderson> and a few other things happen, like ACLs might get recompiled and pushed to everyone (for example, if you have a global ACL defined as "danderson@tailscale.com -> tag:server:*", when you auth a new machine, all machines tagged with "server" receive a new firewall ruleset that allows the new peer to connect)
<danderson> all stuff you can do by yourself, using wireguard and a bunch of effort. We've just done it so you don't have to ;)
Dotz0cat_ has joined #nixos-chat
slack1256 has quit [Remote host closed the connection]
Dotz0cat has quit [Ping timeout: 272 seconds]
<aleph-> danderson: Heh didn't I help take down one of the tun servers with a routing loop?
<aleph-> Or did I just help make that error knowm
<aleph-> known...*
<danderson> heh, yeah, one of the DERP servers went nuts when you did that thing
<danderson> it does have rate-limiters to protect it and between users, so only you suffered from it
<danderson> but it was a pretty hilarious cliff in the traffic graphs
<danderson> 1 ping -> 10MB/sec lol
<aleph-> Yeahhhh haha
<aleph-> danderson: Btw for next week, replied to your email for work stuff. Was laid up most the week as I mentioned haha.
<lovesegfault> gchristensen: I found a better way to control backlight. Add `ddcci-driver` to extraModulePackages and load `ddcci-backlight` on boot. It just exposes them in `/sys/class/backlight` and you can control things with `echo` and no extra tools
<lovesegfault> also easier to use b/c you can just write to all `/sys/class/backlight/ddcci*` devices and synchronize all your monitors with one command
<elvishjerricco> lovesegfault: I use that on my desktop and it's very nice. It doesn't always work for me though, and there were some quirks with nvidia drivers that affected when I had to load the module (had to do it in the display manager setup commands, after writing some config thing for the nvidia card)
<lovesegfault> Yeah, nvidia is a wildcard as always
<elvishjerricco> Now I can just use the brightness keys on my keyboard, which is just so... so nice
<lovesegfault> I use `brillo -e -S`
<elvishjerricco> Never heard of brillo
<lovesegfault> simple cli tool
<elvishjerricco> Ah. Keyboard key is quicker :P
LnL- has joined #nixos-chat
LnL has quit [Ping timeout: 260 seconds]
<danderson> aleph-: oh, right. I'm out for the start of the week
<aleph-> Heh, enjoy!
srhb has quit [Read error: Connection reset by peer]
jackdk has quit [Read error: Connection reset by peer]
jackdk has joined #nixos-chat
srhb has joined #nixos-chat
waleee-cl has quit [Quit: Connection closed for inactivity]
slack1256 has joined #nixos-chat
supersandro2000 has quit [Quit: Ping timeout (120 seconds)]
supersandro2000 has joined #nixos-chat
slack1256 has quit [Remote host closed the connection]
<eyJhb> It is always a little fun updating once own NixOS router, while you are having a lecture! :D And then you just hope it works, else do a rollback :P
<aleph-> Eyeppp.
<aleph-> Speaking of I do kinda wish nixops had infinisil's rollback feature if unable to connect to a network on the host.
<aleph-> Or if it does advertised it better
<srk> how do you handle network topology data and dns for your deployments?
<eyJhb> aleph-: It is a really nice feature, the only thing I miss/annoys me is, that it will reboop my system if I cancel a deploy
supersandro2000 has quit [Quit: The Lounge - https://thelounge.chat]
supersandro2000 has joined #nixos-chat
<sphalerite> reboop :D
FRidh has joined #nixos-chat
<eyJhb> :D
Gaelan_ has joined #nixos-chat
ky0ko has quit [Read error: Connection reset by peer]
Gaelan has quit [Read error: Connection reset by peer]
ky0ko has joined #nixos-chat
__monty__ has joined #nixos-chat
FRidh has quit [Ping timeout: 272 seconds]
FRidh has joined #nixos-chat
supersandro2000 has joined #nixos-chat
supersandro2000 has quit [Changing host]
Dotz0cat_ has quit [Ping timeout: 240 seconds]
tilpner has joined #nixos-chat
Dotz0cat has joined #nixos-chat
cole-h has quit [Ping timeout: 272 seconds]
<infinisil> eyJhb: i should really fix that already...
<infinisil> Shouldn't be too hard
Dotz0cat has quit [Ping timeout: 264 seconds]
<sphalerite> joepie91: a colleague is currently considering using JWT for authentication to avoid keeping state on the server side, that was one of your pet peeves, right? Do you have an article or such that explains why?
<adisbladis> sphalerite: JWT is fine
<joepie91> no, JWT is not 'fine'
<joepie91> even in the odd case that you really do need stateless tokens, it's a badly-designed standard resulting in security-critical implementation errors constantly
<joepie91> in which case you want something like PASETO instead
BaughnLogBot has quit [Quit: ZNC 1.6.2+deb1 - http://znc.in]
<adisbladis> [unpopular opinion]: Most problems people have with JWT comes from the fact that they know nothing about secure designs
<joepie91> without even discussing whether that is true, that is frankly another reason why people should generally not be using it :)
<joepie91> insufficiently misuse-resistant
<adisbladis> That said, PASETO is pretty much how I've always used JWT anyway
<adisbladis> But I think ppl bashing on JWT is a bunch of FUD
<adisbladis> I even think PASETO did some major mistakes
<adisbladis> Like standardising on ed25519
<adisbladis> Which has very little support in hardware tokens
<adisbladis> So it's not useful for many applications
<adisbladis> In many ways I'd be happier with nistp256 (secp256r1)
<joepie91> have you filed a bug? :P
<adisbladis> Nah, I'd rather just stick to jwt where this "just works"
<adisbladis> There are good reasons for JWT to have a flexible alg field
<gchristensen> lovesegfault: oh that is great!
BaughnLogBot has joined #nixos-chat
<__monty__> joepie91: Hmm, what did you do differently to have the second url encode the twiddle but not the first?
<__monty__> adisbladis: There's a lot of pressure from the cryptography community not to include the NIST curves in anything though?
<adisbladis> __monty__: Sure, but that's not practical.
<adisbladis> Right now everyone is walking around with crypto hardware in their pockets that only supports those curves
<gchristensen> really?
<adisbladis> gchristensen: All android phones for one
<__monty__> Otoh being under the impression you're doing something securely when it's not is maybe worse than not being able to do it "securely" at all.
<gchristensen> they don't support any non-nist curves? that is a shame
<adisbladis> gchristensen: Yep.. :/
<adisbladis> And it's actually worse than it sounds
<__monty__> Though maybe I'm too biased about the NIST curves. I don't believe any weaknesses are known publicly. They're just too suspect for me to have any confidence in them.
<gchristensen> it is a bigger shame that math doesn't advance at the same speed of law
<adisbladis> Because a lot of applications are using secp256k1 but phones only support secp256r1
<adisbladis> This was a major hassle at my old job
<adisbladis> Apple is actually really good here
<adisbladis> Their enclaves support ed25519
<adisbladis> But their nist curves are only r1
<gchristensen> yay apple
<adisbladis> But really, that r1/k1 split is annoying as hell
<adisbladis> From my old job ^
<gchristensen> "en uh ma" huh
<adisbladis> tl;dr; We had to do ECC in ethereum smart contracts
<adisbladis> Because of the incompatible curves
<adisbladis> Even though they are pretty much identical...
<joepie91> __monty__: dunno, Firefox being weird I guess
<joepie91> maybe I got one from the URL bar and another from Copy Link?
<siraben> adisbladis: hehe, ethereum!
<joepie91> adisbladis: also, to be clear, complaints about JWT certainly are not "FUD"
<joepie91> it is a misdesigned standard where implementations do constantly fail in the same dumb (and dangerous ways) and which on top of that is constantly recommended for usecases that should not use stateless tokens
<joepie91> all of this is trivially verifiable
<joepie91> and "PASETO chose an algo that doesn't have hardware support" is, to put it mildly, not really a problem of the same magnitude as "lol you can completely bypass signature verification"
<gchristensen> it reminds me of SAML's very common failure points
<V> gchristensen: lol
<V> I read your message before I saw the URL, and cannot unsee
<joepie91> and whether one would personally choose JWT or not depending on circumstances does not really change that these are real problems with real impact
<adisbladis> Sure, these are problems
<adisbladis> But I'm not sure if they are problems with jwt as such
<adisbladis> And I think making an inflexible standard to replace it isn't a solution
<joepie91> sorry, but this is the exact same reasoning as "no, the problem isn't with C, but with people writing memory-unsafe code"
<joepie91> dangerous tools are bad, end of
<joepie91> unnecessarily dangerous tools*
<adisbladis> I'm arguing that paseto is also bad :P
<adisbladis> And not a good replacement
<joepie91> I have seen no plausible arguments to support that
<joepie91> "it does not use a hardware-supported algo" is not a safety issue, for example
<adisbladis> It is
<joepie91> how is it?
<adisbladis> Having accessible key material is a huge liability
<adisbladis> And with the standard as written it's not possible to work around it given real world hardware constraints
<adisbladis> With JWT this is entirely trivial
<joepie91> yeah, okay, sorry, but I'm not going down that particular rabbit hole. the reasoning always assumes that a perfectly secure enclave both exists and is used, neither of which are true
<adisbladis> I'm not saying this hardware is perfect
<joepie91> you may not be saying it, but I have very little faith that the rationale will hold up without that assumption, because that's basically always how it plays out when I try to have this discussion with people, and honestly it's become an exercise in time-wasting that I don't particularly wish to repeat
<adisbladis> Same but in reverse
<joepie91> if you feel that the algorithm selection in paseto is a poor choice, then the correct venue for reporting that and having an in-depth discussion on tradeoffs is the issue tracker
<adisbladis> I'm sick and tired of people pushing ed25519 without consideration for the implications re key mgmt
<adisbladis> joepie91: Or I keep using jwt which doesn't have this drawback?
<joepie91> and if it actually works out being a better idea to choose a different algorithm, then I'm sure it will get changed accordingly
<joepie91> adisbladis: which doesn't have this largely-theoretical drawback and instead signs you up for a perpetually-broken ecosystem of implementations :.
<joepie91> :/ *
<joepie91> there may well be specific circumstances where this tradeoff actually makes sense
<joepie91> but it is not representative of how people actually use stateless tokens
<joepie91> on average
<joepie91> and in the way that people actually generally use them, the issue you're seeing with PASETO is basically irrelevant whereas people constantly get bitten by the JWT implementation issues
<joepie91> please don't confuse those two cases
<joepie91> very few developers even know about the existence of hardware enclaves, on the whole
<joepie91> and so I can understand *you personally* making another choice, but I don't appreciate you dismissing these very real concerns as "FUD"
<joepie91> it's already difficult enough to convey the problem to developers who don't understand the implementation internals or spec safety issues, please don't make that job harder by making such broad claims
<__monty__> I wonder whether people believe enclaves solve the inherent privilege to grant equal access that comes with having access to key material?
FRidh has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-chat
Dotz0cat has joined #nixos-chat
lunc has joined #nixos-chat
Dotz0cat has quit [Ping timeout: 256 seconds]
<andi-> I never got why we are still passing tokens around as matter of authorization. I would actually wish fro everyone that is using JWT to use JWS at the same time. JWT tokens (signed by the issuer that signifies the requesters key as trusted) will be passed on as auth token and the actuall message signed via JWS. The handling server can then (almost stateless?) confirm that a) the message is
<andi-> authenticated & b) the token hasn't been intercepted anywhere and the message is valid
<andi-> many JWTs should be short lived anyway and rolling a key for that period of time might not be a problem at all..
ky0ko has quit [Ping timeout: 246 seconds]
<__monty__> :reload
<__monty__> Apologies.
<infinisil> > timeTo mars
<{^_^}> "3 days, 1 hour, 39 minutes, 8 seconds"
<__monty__> Ugh, it's been 3 days for days!
<gchristensen> such is life when you're traveling at the speed of light
slack1256 has joined #nixos-chat
waleee-cl has joined #nixos-chat
<ldlework> There was a young lady named Bright
<ldlework> Whose speed was far faster than light;
<ldlework> She set out one day
<ldlework> In a relative way
<ldlework> And returned on the previous night.
slack1256 has quit [Ping timeout: 265 seconds]
srhb has quit [Ping timeout: 264 seconds]
ghuntley has quit [Ping timeout: 268 seconds]
srhb has joined #nixos-chat
<__monty__> When the running shoes you chose are great in every way but the fit :"(
ghuntley has joined #nixos-chat
rajivr has quit [Quit: Connection closed for inactivity]
<infinisil> > timeTo mars # philipp[m]1 less than four days!
<{^_^}> "3 days, 30 minutes, 19 seconds"
<srhb> Exciting!
<aleph-> ldlework: heh
BaughnLogBot has quit [Quit: ZNC 1.6.2+deb1 - http://znc.in]
BaughnLogBot has joined #nixos-chat
<philipp[m]1> infinisil: Oh, good bot!
<philipp[m]1> Can I look at the sources of {^_^}, btw?
<infinisil> Yes and no
<infinisil> The bot's source is in https://github.com/infinisil/nixbot
<infinisil> But all the definitions are only accessible by :v in the bot itself
<infinisil> E.g.
<infinisil> > :v mars
<{^_^}> mars = date.parseDateTime "2021-02-18 19:15:00"
<infinisil> (or I could manually publish the json of all definitions if wanted)
<infinisil> Oh also, the date library used here is stored in a file on the nixbot host, soo that also can't be viewed without me manually publishing it atm 😅
<gchristensen> > date.parseDateTime "2021-02-29 00:00:00"
<{^_^}> { day = <CODE>; hour = <CODE>; minute = <CODE>; month = <CODE>; second = <CODE>; year = <CODE>; }
<gchristensen> > (date.parseDateTime "2021-02-29 00:00:00").day
<{^_^}> 29
<gchristensen> > timeTo (date.parseDateTime "2021-02-29 00:00:00")
<{^_^}> "13 days, 4 hours, 51 minutes, 13 seconds"
<gchristensen> > timeTo (date.parseDateTime "2021-02-2900 00:00:00")
<{^_^}> "7 years, 10 months, 24 days, 4 hours, 51 minutes, 9 seconds"
<gchristensen> nice
<gchristensen> > timeTo (date.parseDateTime "1980-02-2900 00:00:00")
<{^_^}> "24 days, 4 hours, 50 minutes, 54 seconds"
<philipp[m]1> infinisil: No, I don't need anything published but thanks.
<infinisil> gchristensen: The hardest part was getting months/days correct
<infinisil> Oh wait what
<infinisil> > :p date.parseDateTime "2021-02-2900 00:00:00"
<{^_^}> { day = 2900; hour = 0; minute = 0; month = 2; second = 0; year = 2021; }
<infinisil> Oh lol
<gchristensen> :P
<infinisil> I'm impressed that that worked
<gchristensen> I am too!
<cransom> oh fun, thats how we calculate some of the release dates being the 43rd of march!
<gchristensen> haha
<aleph-> lolol
<infinisil> Oh that's perfect
<infinisil> > date.parseDateTime "2020-09-57 12:00:00"
<{^_^}> { day = <CODE>; hour = <CODE>; minute = <CODE>; month = <CODE>; second = <CODE>; year = <CODE>; }
<infinisil> That's the NixOS 20.09 release date
<infinisil> 57th of September!
<aleph-> ~Do you remember~
<aleph-> ~The 57th of Septemberrrr~
<infinisil> Ah yes
<das_j> ~Love was changing the mind of pretenders~
<samueldr> well, it's not a *date*, but it's some kind of relative moment, and not having to deal with overflowing values in the right container at the right moment is a net bonus
<infinisil> Oh wait, let's see if it can normalize it by converting to unix epoch and back
<infinisil> > date
<{^_^}> { dateTimeToEpoch = <CODE>; diffDateTime = <CODE>; epochToDateTime = <CODE>; parseDateTime = <CODE>; prettyDateTime = <CODE>; prettyDuration = <CODE>; }
<infinisil> > :p date.epochToDateTime (date.dateTimeToEpoch (date.parseDateTime "2020-09-57 12:00:00"))
<{^_^}> { day = 27; hour = 12; minute = 0; month = 10; ms = 0; second = 0; year = 2020; }
<infinisil> > :p date.prettyDateTime (date.epochToDateTime (date.dateTimeToEpoch (date.parseDateTime "2020-09-57 12:00:00")))
<{^_^}> "2020-10-27 12:00:00 UTC"
<infinisil> Nice
<infinisil> samueldr: It should be a date though
<infinisil> I think it is
<infinisil> The time difference calculations aren't in play here
<samueldr> yeah, I mean, if you're using it for date calculations, it's fine enough
FRidh has quit [Quit: Konversation terminated!]
<lovesegfault> is lorri still maintained/developed?
<gchristensen> anyone happen to know if cpio has a spec that can be read? :P
<__monty__> Why is it still in use?
<samueldr> kernel
<__monty__> lovesegfault: I don't think it's been abandoned.
<__monty__> samueldr: But why no other format? It's just an archive, no?
<__monty__> It feels a bit like an anachronism.
<samueldr> no one got around to it?
<samueldr> maybe it works just fine for the needs?
leah2 has quit [Ping timeout: 264 seconds]
<gchristensen> perfect! thank you :D
leah2 has joined #nixos-chat
pie_ has quit [Ping timeout: 256 seconds]
Dotz0cat has joined #nixos-chat
<infinisil> Spicy ramen time \o/
<aleph-> Nom
cole-h has joined #nixos-chat
__monty__ has quit [Quit: leaving]
endformationage has joined #nixos-chat
<aanderse> i haven't had ramen in forever T_T
<infinisil> It was very good
<infinisil> Also spicy, if you can believe it
<gchristensen> the only place with ramen within 30 minutes of here ran out of money during covid :(
<infinisil> Oh no :(
<gchristensen> rest in peace, flavors https://www.yelp.com/biz/flavours-of-malaysia-pittsfield
<aanderse> > Also spicy, if you can believe it
<aanderse> i think i've only ever had ramen that wasn't spicy maybe twice in my life :D
<{^_^}> error: syntax error, unexpected ',', expecting ')', at (string):475:11
<infinisil> I'm kind of partial about spicy ramen
<aanderse> pork+kimchi+miso ramen <3
<infinisil> Because from the ramen I've tasted, the spicier ones seemed to have less flavor (or at least it was less noticeable due to the spice)
<infinisil> I do like both spice and flavor though
<infinisil> I'm currently making notes for which ramen has how much spice and how much flavor :)
<infinisil> So far, spice seems to be inversely proportional to flavor
<aanderse> taking notes on ramen sounds like a good idea ha ha ha
<infinisil> (out of 4 products)
<joepie91> this feels like a twitter account in the making
<joepie91> @RamenRates or something
<infinisil> Hehe
<infinisil> Traveling the world, tasting ramen in all sorts of places
<aanderse> i feel like this tv show must already exist
tilpner_ has joined #nixos-chat
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
<aleph-> It does I'm fairly certain
<cole-h> Anybody else's "news feed" on GitHub get removed as well? (Visible on `https://github.com` when logged in)
<cole-h> I relied on that to see what cool things the people I'm following were doing :(
<jtojnar> refined-github?
<cole-h> I have it disabled at the moment
<rmcgibbo[m]> Does anyone know of a tutorial on how to use github actions to create a nix channel backed by a binary cache? e.g. having GH actions build on every commit but then only update the channel if the build succeeds and was pushed to cachix, so that installing from the channel will always trigger a fetch of the most recent successful build.
<rmcgibbo[m]> Maybe some trick with having the CI run `git push --force` to a second branch after a successful build and then https://github.com/<owner>/<repo>/archive/<branch>.tar.gz as the channel...