🛡️ XEdDSA packet signing — client UI spec

Tracking: design#113 · Firmware: firmware#10478 (2.8) · Reference build: Meshtastic-Android#5976 (merged) + #5980 + #5985

What it looks like (Android reference)

Messaging — per-message shield	Node details — "Signed node"	Node list — "Signed node"
Top bubble (14:02) verified — green 🛡️; bottom (14:03) unsigned, no shield.	"Signed node · Verified automatically" in the security section, paired with the manually-verified cell.	Shield beside the key/lock status icon in the row — visible without opening details.

Trust states at a glance

Goal

Show users when a node and its broadcast packets are cryptographically signed and verified (XEdDSA over the node's identity key) — primarily in node details and the messaging view.

Guiding principle

Affirm the good state; stay silent otherwise. The radio drops invalid and stripped-signature broadcasts from a known signer before the client sees them, so there is no "tampered/invalid" state to render. A small broadcast you can see from a signing node is verified by construction. We only ever say "this is signed and verified" — we never warn, flag, or downgrade unsigned traffic.

What the radio gives the client

Read-only flags — no client-side crypto.

What is signed: unencrypted broadcasts that fit a 64-byte signature — NodeInfo, position, telemetry, channel text. The signature covers from | id | portnum | payload.
Not signed: DMs (those are PKI-encrypted — a separate mechanism) and oversized broadcasts.

Two distinct affordances — shield vs lock

Signing ≠ encryption. They answer different questions ("who really sent this" vs "who can read this") and apply to disjoint traffic, so they stay separate:

• 🛡️ shield = authentic (a verified, signed broadcast)
• 🔒 lock = private (a PKI-encrypted DM)

Use a shield-with-check mark for signing — each platform picks its nearest native equivalent (Android used the Material Symbols verified_user glyph). Leave the existing DM lock untouched.

Node details & node list

• Signed node: when has_xeddsa_signed, show a "Signed node" 🛡️ shield. Because NodeInfo is itself a signed broadcast, the node's name/identity is verified by extension.
• Node details: slot a "Signed node" row into the existing key/security section, ordered most-trusted-first: manual-verified → signed → has-key → no-key. Keep it a distinct cell from manual key verification (Android pairs it with the manually-verified cell in one row; stack or pair as suits the platform) — the two are earned differently. Signing is automatic trust (observed from the radio); manual verification is user-asserted. Label it accordingly (e.g. "Verified automatically").
• Node list (rows): also show the shield in each node row's security cluster, right beside the key/lock status icon, so signing is visible at a glance without opening details. Apply to every list density (compact + full). Group it with the key icon as one affordance rather than a scattered separate badge.
• Phrase it as observed ("signs its packets" / "Signed node"), never as a configurable setting ("signing enabled") — there is no such advertised flag.
• Tap to explain: make the shield tappable (mirroring the key-status icon), opening a plain-language explanation. Suggested copy — title "Signed node", body "This node signs its broadcasts with XEdDSA. Broadcasts you see from it are verified by the radio using its identity key."
• Copy: row label "Signed node", value "Verified automatically"; per-message reveal "Signed · verified"; message detail "Signed & verified — verified with their key." Keep wording consistent across clients.

Messaging view

• Channel/broadcast messages: a green 🛡️ on xeddsa_signed bubbles; reveal "Signed · verified" on tap. Per-message — a node may send a signed small message and an unsigned oversized one in the same channel.
• Direct messages: keep the existing 🔒; do not show the signing shield. Lock = private (DM); shield = authentic (signed broadcast).

• Message detail/info: plain-language, affirmative state — e.g. "Signed & verified — sent by Alice (!a1b2c3d4), verified with their key." For unsigned, use neutral copy ("not signed — older firmware or too large") and never anything accusatory.

Resolved decisions (v1)

The original open questions are settled for v1:

1. Signing vs encryption language → two separate affordances (shield + lock), not a merged "security" concept.
2. Node trust state → two distinct cells (manual key-verify and signature-verify), most-trusted-first and laid out per platform (Android pairs them in one row); don't conflate them.
3. Per-data-field signed badges (badging individual position/telemetry/sensor rows) → deferred. The node-level "Signed node" row already conveys trust; the per-field visual cost wasn't justified for v1. Revisit on demand.
4. Treatment for "unsigned" → strictly silent. No icon, no label, no neutral chip.
5. Compose-time "will be signed" indicator → out for v1.
6. "Signed but unverifiable" state (signature present, xeddsa_signed == false because the radio lacked the key) → dropped for v1. It's rare and transient — it resolves once the key is known. Render trust from the verified boolean only; clients don't need to read Data.xeddsa_signature yet. Revisit only if it proves non-transient in the field.

Don'ts

• Don't reuse the lock icon for signing.
• Don't use red / error styling anywhere — nothing here is an error.
• Don't flag unsigned DMs / large / legacy traffic as insecure.
• Don't phrase node UI as "signing enabled"; phrase it as observed ("signs its packets").

Per-client status

• Android — #5976 (merged), #5980 (shield color), #5985 (legibility + node-details polish)
• iOS — Meshtastic-Apple#1992
• Web — web#1188
• BaseUI (firmware on-device UI) — firmware#10800
• MUI — standalone-ui#35, device-ui#331