# AAD and ownership of the M5C

AAD is a static SPA at willey.co. Modeling, project storage, exports and real FDM slicing execute in the browser. Every browser runtime dependency is committed under `vendor/`, including the slicing engine and embedded WASM. No cloud slicer, CDN, vendor account or third-party desktop UI is involved in those operations.

## Home bridge

The optional device service lives separately in private [willeyco/aad-printer-bridge](https://github.com/willeyco/aad-printer-bridge). It uses Node 22 standard-library modules only. Run `npm start` there for same-computer HTTP loopback. Its README and configuration example describe household HTTPS deployment.

A household bridge needs a stable LAN address, an owner-managed DNS name and a browser-trusted certificate. The service refuses plaintext HTTP on the LAN. Trusted certificate provisioning/renewal and household network deployment are not automated by this release.

An ordinary SPA cannot broadcast mDNS/UDP or enumerate arbitrary LAN hosts. The bridge prints a pairing link that supplies its address. Open the link, enter its pairing code in Prepare → Printers, and grant local-network permission if the browser asks. AAD stores a nonextractable P-256 signing key in IndexedDB, pins it to the bridge identity and remembers only its address in localStorage. The bridge stores public keys; eight-hour bearer sessions stay in page memory. Subsequent visits reconnect automatically and refresh discovery once a minute while visible. Disconnect stops that visit's reconnect loop; Forget removes the pairing.

CORS permits configured exact origins, Host must match the advertised endpoint, and signed challenges expire and cannot replay. The browser key belongs to the willey.co origin: deployed code on that origin can use it, so review integrity matters. If browser storage is cleared, pair again. Local forgetting while offline cannot revoke the bridge's saved public key; an owner can remove it from the stopped service's client registry. Do not disable certificate checks or browser security features.

## What this release proves

Bridge 0.2 sends bounded printer DNS-SD queries on UDP 5353 and PPPP `LAN_SEARCH` on UDP 32108, with 2.5-second response windows. The September 25 LAN experiment found one PPPP candidate and no supported open service. That is **one candidate**, not authenticated proof of the M5C model or firmware. Discovery data is never uploaded to a server. Device addresses and IDs are omitted from repository evidence.

The API returns 0..n printers, with nullable make/model and explicit identity provenance. Owner display labels remain separate from device-reported fields. In AAD 2.1, select a candidate and choose **Read device information**, or use `aad.device.inspect` with its discovered ID. Supported Moonraker/Klipper, OctoPrint and PrusaLink local APIs can report software/firmware and job observations. These readers have fixture coverage; physical validation on those printer families remains outstanding. Protected APIs report authentication required because credential provisioning is not implemented. See [local printer information](AAD-local-printer-status.md) for endpoints, freshness behavior and limits.

The M5C remains discovery-only: its local identity, firmware and job state are still unknown. All current adapters leave physical identity unauthenticated and print/home/extrude/retract/cancel disabled. AAD distinguishes current observations from stale last-known state; neither discovery nor idle implies a verified completed print. Job validation, upload, staging and start remain future work. The browser's separate slicing capability is available without this bridge.

The transport boundary must not equate discovery with ownership. Other devices can speak PPPP and discovery replies are unauthenticated. Before enabling transfer, match the physical unit, obtain its exact firmware and verify the protocol with owner-supplied credentials or a supported local pairing mechanism. Do not extract credentials from the vendor app or assume the M5 firmware project applies to the M5C.

## Work required before direct printing

1. Bind an authenticated session to the exact device and firmware, and expose identity/status timestamps. Never accept a stale discovery entry as a live print target.
2. Implement a reviewed adapter for that firmware. Determine whether upload immediately starts printing; if it does, expose `uploadStartsPrint: true` and require a single explicit physical-start authorization. Do not invent separate staging/start semantics.
3. Validate an immutable job: source project revision and digest, printer profile revision, G-code digest, machine bounds, modal interpretation, material/nozzle and toolpath review. Recheck the device is idle before any start.
4. Verify cancellation, busy/reboot conditions, partial transfer, retries and recovery. Never automatically retry an uncertain physical start.
5. Test ordinary printing with WAN blocked, then reboot printer/bridge, expire cloud credentials, and test recovery. Test first provisioning independently. A local transfer protocol can still depend on cloud-issued keys.
6. Confirm the M5C's USB-C **flash-drive** workflow on this exact firmware as an offline fallback. A USB storage port is not proof of browser WebUSB or serial streaming support.

No print, firmware flash, security-setting change or vendor account change was performed for this release. Full cloud-free provisioning is unresolved. First establish the actual M5C's local identity/status route; then prepare the original Little Tug end-to-end experiment, with a short calibration specimen first if the physical setup needs it.

## Protocol references

- [Community protocol details](https://github.com/Django1982/ankerctl_go_remake/blob/main/docs/wiki/Protocol-Details.md) and its `internal/pppp/protocol/packet.go`: discovery framing and identity tuple.
- [AnkerMake protocol research](https://github.com/Ankermgmt/ankermake-m5-protocol): credential and transfer constraints. Community research is not a vendor compatibility guarantee.
- [Chrome Direct Sockets](https://developer.chrome.com/docs/iwa/direct-sockets): special installed-app capability, not ordinary static-site UDP.
- [M5C product documentation](https://www.ankerjapan.com/products/v8110): machine envelope and USB-C flash-drive support.