| 5 Mar 2025 |
 John Ericson | Well, lol, it was exactly pre-determined! | 16:07:33 |
 Robert Hensing (roberth) | Nice. Don't be late because I nerd sniped you! | 16:08:00 |
| John Ericson | Based on this, I feel like both types of placeholders could look exactly like store paths, except for using a different hash character set to very subtly distinguish them | 16:08:25 |
| John Ericson | I might be a little worried about that confusing humans, hah, who just glance at it | 16:08:55 |
| John Ericson | But it would be great for code in Nixpkgs that wants to look for name parts and and the store dir | 16:09:29 |
| Robert Hensing (roberth) | Canonical JSON looks kinda good. Canonical, sorted, no floats. Strings are bytes, so not technically JSON. RFC 8785 is complicated and does not allow non-Unicode bytes | 16:31:41 |
 emily | please don't use canonicalized JSON formats | 16:42:10 |
| emily | people WILL use something less rigid and only find out years down the line when it's a huge headache | 16:42:25 |
| emily | pick a format that's rigid by design or at least has a canonical format rigidly specified in the same spec rather than being something people have made 100 canonical versions of | 16:42:54 |
| emily | it's a huge footgun, everyone who uses JSON in a cryptographic context gets bitten by this eventually. Matrix included iirc :) | 16:43:17 |
| Robert Hensing (roberth) | hmm ok. Something human readable would be great (and something not ATerm) | 16:45:17 |
| emily | human-readable can actually be a drawback for formats specifically designed to be non-malleable, precisely because they invite opening in a text editor and appending some keys in whatever order.
fwiw, https://preserves.dev/ is well-designed, has a superset of JSON types, and has both a textual format and a binary format with a rigidly-defined canonical representation for the latter. however it's also a bit obscure and won't have as wide library support as alternatives so I can understand not going with it. the Spritely/Agoric/Cap'n Proto standardization effort OCapN uses it as Syrup, which is a separate canonical-but-made-up-of-printable-characters serialization of it https://github.com/ocapn/syrup#pseudo-specification.
more well-known alternatives:
- deterministic CBOR serialization, buuuut there are like three versions of it so caveat emptor https://www.imperialviolet.org/2022/04/17/canonsofcbor.html
- canonical s-expressions
- bencode
- …ASN.1 BER? 🙃
also, if you don't actually need a flexible/extensible format, defining your own very simple rigid serialization isn't a sin when you want cryptographic canonicity. (just make sure it's actually non-ambiguous and preferably can't be corrupted into another valid message by truncation, especially if you might be concatenating multiple messages.)
| 17:00:57 |
| emily | (total digression but Preserves is also used in the https://syndicate-lang.org/ ecosystem which I suspect John Ericson might find interesting) | 17:03:05 |
| emily | (the Preserves textual format is also a superset of JSON, so in terms of being able to ingest things in a familiar format to then canonicalize it works well. but again many understandable reasons to pick something else, just giving an overview of the space as I see it) | 17:04:33 |
| Robert Hensing (roberth) | John Ericson: did we have an issue on this topic yet? Couldn't find one | 17:06:35 |
| John Ericson | @roberthensing:matrix.org: for new drv format? | 17:24:42 |
| John Ericson | Not actually sure | 17:24:54 |
| John Ericson | Also FYI https://github.com/facebook/buck2/issues/866 | 17:25:21 |
| John Ericson | I sent to @edef1c too | 17:27:02 |
 puck | In reply to @roberthensing:matrix.org
John Ericson: I've suggested to treat the Nixpkgs "fix" for the CA placeholder issue (no storedir prefix) as a workaround as ca-derivations is experimental https://github.com/NixOS/nixpkgs/pull/386774#pullrequestreview-2660479310 builtins.placeholder has the same "issue", though i like them not being /nix/store-prefixed because it disambiguates that their format is unstable | 17:31:38 |
| Robert Hensing (roberth) | That one isn't experimental, so we'd need a very very good reason to change that anyway | 17:33:35 |
| emily | I don't suppose Nix strings support NUL bytes in them so that we could properly separate the namespace from actual filesystem paths? in the same way abstract Unix sockets do | 17:33:47 |
| Robert Hensing (roberth) | Also isn't user-handled as much as outputs are | 17:34:04 |
| Robert Hensing (roberth) | Evaluator strings are C strings. This could be changed to something with a length, but we're not in a hurry. I guess one of those separator control characters could serve the same role, but I feel that it'd be weird to do any of that (regardless of choice of byte value) | 17:35:50 |
| emily | NUL is the only byte that is actually guaranteed to not be allowed on Linux anyway (though of course other platforms exist too) | 17:38:44 |
| emily | so no advantage to anything else | 17:38:48 |
|  Naxdy changed their profile picture. | 18:03:52 |
| 6 Mar 2025 |
|  @maikelfrias:matrix.org joined the room. | 02:33:30 |
| @maikelfrias:matrix.org left the room. | 02:36:01 |
 ElvishJerricco | I'm going to make this comment here because I think it is one of the most important things I've said in the world of NixOS. Please read this comment: https://discourse.nixos.org/t/determinate-nix-3-0/61202/57 | 21:33:50 |
