Request preparation

• I used an AI assistant to help structure this request
• I checked for existing issues covering the same feature

What would you like?

Following up on the conversation in #2456 — agreed this is a real design question worth thinking through before any responder code lands. Rather than re-submit the original PR as-is, proposing a different approach that I think addresses the concern you raised at root.

The underlying problem

aether_pad (github.com/nigelfenton/aether-pad) is one peripheral; ShackSwitch is another. Both need AetherSDR to know they exist on the LAN. The original PR addressed this by adding a UDP responder inside AetherSDR that listens for aether_pad's discovery broadcasts.

The concern raised — "should AetherSDR host external-project discovery protocols on every install" — is correct on the merits. Each peripheral wanting discovery would need its own responder inside AetherSDR, and that doesn't scale. The next person with a TCI-capable rotator or amplifier hits the same question.

Proposed approach: invert the responsibility via mDNS

Instead of AetherSDR hosting peripheral-specific responders, peripherals advertise themselves via mDNS (Bonjour/Zeroconf), and AetherSDR does a single generic browse when the user opens the relevant settings panel.

Service type (open to bikeshed): _tci._tcp.local

TCI is already an emerging open standard across SDConsole, ExpertSDR and others — registering a service type for it is a natural extension rather than a new invention.

TXT records (proposed schema):

• model — peripheral model identifier (e.g. shackswitch-v2, aether-pad)
• class — device class (antenna-switch, controller, rotator, amplifier, …)
• tci-version — TCI protocol version supported

What AetherSDR does:

1. On opening Settings → Peripherals (or equivalent), kick off a short mDNS browse for _tci._tcp.local
2. Populate a list from the responses
3. User picks one; the existing connect flow takes over

That's it. No persistent listener, no peripheral-specific code, no broadcast traffic when the panel isn't open.

Tradeoffs vs the original PR

Alternatives considered

1. Keep the original UDP responder, accept per-peripheral responders.
Works for two peripherals, doesn't scale. Each future peripheral becomes a PR negotiation about whether it belongs in AetherSDR core.

2. Manual IP entry only.
Bulletproof and boring. Should remain available as a fallback regardless — mDNS doesn't always work on segmented networks, guest VLANs, or some enterprise setups. But as the only option it's poor UX.

3. Plugin architecture — AetherSDR exposes a discovery API, peripherals register via plugins.
More flexible but significant work on your side, and shifts burden onto every peripheral developer to ship a plugin. Probably overkill for the current need.

4. Status quo (no built-in discovery).
Acceptable, but means every peripheral project duplicates the "tell users how to find their device's IP" docs.

Out of scope for this issue

• Any AetherSDR-hosted responder for peripheral-specific protocols
• Changes to the TCI protocol itself
• ShackSwitch or aether_pad implementation details (those projects implement the advertising side independently)
• Authentication / authorisation (separate question — happy to open a follow-up if useful)

Suggested path forward

If the direction is acceptable, I'd propose splitting into two PRs:

1. Docs-only PR — defines the _tci._tcp.local service type and TXT record schema. Tiny, easy to review, locks in the contract.
2. Implementation PR — Qt-side mDNS browse and the peripherals settings list. Likely a thin wrapper around QtZeroConf or platform-native APIs (Bonjour / Avahi / Windows mDNS), depending on what dependency footprint you're comfortable with.

Open to all of: rejecting the approach, modifying the service-type / TXT schema, scoping it tighter, or pushing it later in the roadmap. Mostly want to make sure the direction is one you're comfortable with before either of us spends time on code.

73,
Nigel G0JKN & Claude (AI dev partner)