CONNECT
client -> server certificate presented on an encrypted socket
server -> client protocol support announced
client -> server version requested required, or the stream stalls
REGISTER
client -> server self announcement, callsign and device identity
client -> server repeated every 15s <-- miss it and you are dropped
EVENT
<event type="a-f-G-U-C-I" uid="..." time/start/stale>
<point lat="..." lon="..." hae="..." />
<detail>
<contact callsign="I-001" /> attribute, not element text
<__group name="Red" /> decides colour and visibility
</detail>
</event>
The connection lifecycle and the event shape, reduced to the parts that were learned the hard way
- Every ring carries its colour three times. The handheld and desktop clients read different fields, and the desktop one drew every ring white until it was given the field it wanted.
- Newer is not always the right version. The push-only relays accept the offer of the newer binary protocol. The two-way relay refuses it and stays on the text protocol rather than the binary one, so inbound events parse with the standard library alone. A deliberate downgrade, recorded as one.
- The expensive one: the wrong input isolates you silently. Markers sent to a plain input were accepted and logged as relayed, and never reached certificate-authenticated clients, because they carried no group identity. On the authenticated input they appeared instantly. Every log said success the whole time.