Hi Frank--

On Fri 2025-11-07 15:02:36 +0000, Frank Seifferth wrote:
> My script is very similar in spirit to the MVP proposed by Antoine
> Beaupré in April 2023, yet it offers a slightly different UI. One of my
> main design decisions was *not* to introduce the idea of an accounts and
> a peers table into notmuch. Instead, I simply treat the email database
> as if it were a local key server that can be queried to import keys into
> the gpg keyring by running, e.g.,
>
>     notmuch autocrypt --locate-keys frankseifferth@posteo.net

this is super interesting, thanks for publishing it!  I'm many many
years behind of buckling down and getting the thing i wanted to get done
for notmuch and autocrypt, so i really appreciate your stepping up and
offering something concrete.

The accounts and peers table in the autocrypt spec describe one way to
get to the deterministic query of "what OpenPGP certificate should I use
for this peer?"  even in the situation where messages arrive out of
order, are deleted, etc.  And if a certificate is available for the peer
in question, it also yields a recommendation for "shen composing a new
message to this peer, should the new message be encrypted by default?"

Do you think your script's implementation would yield the same result
for these queries, even without maintaining a table?  That would be a
very nice result.

> This UI deliberately mirrors gpg, where you can run `gpg --locate-keys` to
> retrieve keys from a WKD. I found it very natural to model the autocrypt
> key import functionality as a query against the email database, and I
> believe that this approach might be more promising than sticking too
> closely to the UI described in the autocrypt spec.

I'm a long-time user of (and contributor to) GnuPG but i gotta say i
would *not* try to deliberately mirror the UI of gpg.  it's kind of a
mess.

I've found notmuch's interface to be better organized -- it seems like
it might be better to try to extend notmuch's interface to map to the
queries supported by autocrypt, and then backfill from that to figure
out whether we need to change the database at any infrastructural level.

This script also seems devoted to working with gpg.  I know that notmuch
is pretty dependent (through gmime) on gpg at the moment, but there are
many other OpenPGP compatible tools available today -- it'd be cool if
this tooling just extracted the Autocrypt recommendation (certificate
plus default choice of encrypted), and the user could plug the relevant
certificate and policy information into their own OpenPGP tooling.

> Until now, `notmuch-autocrypt` is still limited to my own very specific
> use case[3]. However, I believe that it could be a promising starting
> point for finally bringing autocrypt support to notmuch. So if anyone
> reading this mailing list should be interested in pursuing the MVP
> approach a little further, I would be very happy to hear from you.

I think this is a great starting point.  I love the simplicity of it,
but i also think the simplicity might be a bit risky (e.g.
https://github.com/seifferth/notmuch-autocrypt/issues/1).

I'd be happy to work with you on this, i think it's very cool!

    --dkg