unofficial mirror of 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <>
To: Florian Klink <>
Cc:, Christopher Baines <>
Subject: Re: Nix Daemon protocol post / Tvix
Date: Thu, 16 Nov 2023 16:14:20 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <rdrshtntxxzrw2lirjzx33lqttnpvn5evllttxvmvd3kf3drg7@4x2ofykjx742> (Florian Klink's message of "Mon, 30 Oct 2023 23:02:18 +0200")

Hi Florian,

Florian Klink <> skribis:

> I stumbled across your post
> I'm working on Tvix (, a reimplementation of Nix in
> Rust.

Neat, thanks for reaching out to us!


> For example, tvix-store is using a content-addressed merkle storage DAG
> (tvix-castore) under the hood, allowing partial substitution and store
> path subtree sharing.
> However we can still provide a Nix-compatible view into all this, so can
> synthesize NAR Archives and NARInfo files for a given store path on
> demand, if we want to. We currently use the HTTP Binary cache protocol
> as a store interface for Nix (via `nar-bridge`, which spins up a
> webserver).
> At some point, we now also want to implement the daemon protocol - both
> a client and server, to allow talking to Nix more directly - be it a
> "remote store", or just querying the local Nix store for certain
> information. This is so far mostly oriented towards store operations (as
> we didn't do too much work on the Builder interface yet)

All this sounds nice.

> Nevertheless, I think we should collaborate.
> Be that:
>  - just a simple exchange of notes about the behaviour of the protocol
> 	 and certain operations
>  - discussions about designing new protocols, ensuring interop between
> 	 tvix-store and guix stores (there's some ideas for P2P substitution)
>  - or even collaboration and work on getting tvix-store (and tvix-build,
> 	 once it's there) to work with a Guile frontend :-)
> I think we're sharing a lot of common interest and would like to start
> having these conversations :-)

That’s a good idea!

My take is that the daemon rewrite in Guix will aim for 100%
compatibility at the protocol level (in fact part of what’s needed is
already available as (guix …) modules), probably with just the same
feature set.  Christopher Baines may have clearer ideas.

I’m interested in hearing how you view content-addressing and its use.
In Guix there’s one proposal based on ERIS:

Previously there was an experiment to implement what you described at
“partial substitution”:

Hot topics! :-)


  reply	other threads:[~2023-11-16 15:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-30 21:02 Nix Daemon protocol post / Tvix Florian Klink
2023-11-16 15:14 ` Ludovic Courtès [this message]
2023-11-16 19:23   ` Ensuring daemon interop, maybe also store layer standardization? John Ericson
2023-11-16 20:52     ` Florian Klink

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).