`Property.ip` at `pong.proto:35` declares the backing Node's public address as a `string` in dotted notation ("203.0.113.7"), while `Peer.ip` at `pong.proto:61` encodes the same semantic concept — a Node's public IPv4 — as four raw bytes in network byte order. `Welcome.ip` (`welcome.proto:39`) and `Welcome.home` (`welcome.proto:52`) also use raw bytes. `Property.ip` is the only IPv4 field across the four proto files that uses a string.
A client building a connection target from a `Property` must parse a dotted string, while one reading a `Peer` for the same purpose must decode four raw bytes. The `Ping.canaries` map key (`ping.proto:23`) inherits the dotted-string convention to key per-peer failure counters, which means a client correlating `Pong.servers` entries (raw bytes) against `Ping.canaries` keys (dotted strings) must convert between representations at runtime. That conversion has no single canonical place in the codebase and is a concrete source of implementation bugs, especially across the iOS, Android, and Node clients that all consume the same proto definitions.
Introduce a new `bytes ip_bytes = 8` field on `Property` in `pong.proto` to carry the address in the same raw-byte encoding used by `Peer.ip`, and reserve `string ip = 4` once all clients have migrated. Align the `canaries` key documentation in `ping.proto` to note that keys match `ip_bytes` rather than the dotted `ip` string. The two-field transition preserves wire compatibility during the rollout.
`Property.ip` at `pong.proto:35` declares the backing Node's public address as a `string` in dotted notation ("203.0.113.7"), while `Peer.ip` at `pong.proto:61` encodes the same semantic concept — a Node's public IPv4 — as four raw bytes in network byte order. `Welcome.ip` (`welcome.proto:39`) and `Welcome.home` (`welcome.proto:52`) also use raw bytes. `Property.ip` is the only IPv4 field across the four proto files that uses a string.
A client building a connection target from a `Property` must parse a dotted string, while one reading a `Peer` for the same purpose must decode four raw bytes. The `Ping.canaries` map key (`ping.proto:23`) inherits the dotted-string convention to key per-peer failure counters, which means a client correlating `Pong.servers` entries (raw bytes) against `Ping.canaries` keys (dotted strings) must convert between representations at runtime. That conversion has no single canonical place in the codebase and is a concrete source of implementation bugs, especially across the iOS, Android, and Node clients that all consume the same proto definitions.
Introduce a new `bytes ip_bytes = 8` field on `Property` in `pong.proto` to carry the address in the same raw-byte encoding used by `Peer.ip`, and reserve `string ip = 4` once all clients have migrated. Align the `canaries` key documentation in `ping.proto` to note that keys match `ip_bytes` rather than the dotted `ip` string. The two-field transition preserves wire compatibility during the rollout.