Today the self-signed cert workflow is entirely reactive — apps/web/src/core/connections/transports.ts:63 only tells the user to open the device URL in a new tab and accept the cert after the connection attempt fails. On the hosted client (https://client.meshtastic.org) users hit this on their first HTTPS device connect and the "not reachable" message in AddConnectionDialog doesn't explain why.
Proposal:
- In
AddConnectionDialog when protocol is HTTPS, show a "self-signed cert?" helper with a button that opens the target URL in a new tab before the user tries Test Connection.
- After the user returns, re-probe reachability and show a positive "cert accepted" indicator.
- Distinguish cert-not-trusted from actually-unreachable in the error copy.
Distinct from #1015 and #1031, which report the raw "HTTPS doesn't work" symptom. This tracks the UX around self-signed cert acceptance specifically.
Today the self-signed cert workflow is entirely reactive —
apps/web/src/core/connections/transports.ts:63only tells the user to open the device URL in a new tab and accept the cert after the connection attempt fails. On the hosted client (https://client.meshtastic.org) users hit this on their first HTTPS device connect and the "not reachable" message inAddConnectionDialogdoesn't explain why.Proposal:
AddConnectionDialogwhen protocol is HTTPS, show a "self-signed cert?" helper with a button that opens the target URL in a new tab before the user tries Test Connection.Distinct from #1015 and #1031, which report the raw "HTTPS doesn't work" symptom. This tracks the UX around self-signed cert acceptance specifically.