A Settings section for public keys is furniture, not a feature. Nothing
in ihasmail signs, encrypts, decrypts or verifies with a key, so the
page could only ever tell the reader in its own footnote that adding one
does nothing. It is withdrawn on that reasoning -- the same reasoning
that closed PR #67, reached again with the code in front of us.
So this reverts every user-visible part of it: the section, the lib, the
mock handlers, the component and the 261 catalogue strings. Nothing in
web/ or server/ differs from main now.
What stays is the part that was expensive and is true regardless. The
x:PublicKey registry was probed against a live 0.16.20 on 2026-09-05,
and the findings are now in KNOWN-ISSUES rather than in a closed pull
request -- which is where they sat for the nine days between #67 and
this branch, and why the work was done twice. Consolidated into one
entry, framed as what Stalwart does rather than what ihasmail offers:
- an ordinary user may read and write their own keys, whatever the
permissions table says
- the registry takes S/MIME certificates as well as OpenPGP keys, and
parses both -- confirmed with a real self-signed X.509 certificate,
and a malformed one gets its own BER decoding error
- a key can parse and still be refused, with different words. A
sign-and-certify key -- what `gpg --quick-generate-key` makes --
gets "Could not find any suitable keys", which is not a paste error
and must not be shown as one
- emailAddresses comes back as {} when empty, an object where a list
property should be an array. It type-checks, then throws in join()
- a create answers with the id alone; patching `key` is allowed
- expiresAt is the registry's field and is not derived from the key
ROADMAP now says plainly that key management has been built and
withdrawn twice, that the registry is not the obstacle, and that
verifying a signature -- which needs only public keys -- is the shortest
route to a key being worth having. Encryption at rest moves from "not
offered yet" to refused: it is a one-way door, since turning it off does
not decrypt what is already there, and that is not a switch to hand an
ordinary user however easy it would be to add.
jcoffey-dev
45c8929697