fenleon 28e0432f09 registration: the register body is capture-exact (rev 51) — four services, id-get-handles, one prekey mint ...

The trapped reference register (frame-026) is now matched field for field.

- RegisterServiceCatalog: the reference's four services in wire order
  (madrid + multiplex1 + facetime.multi + ess), each row a constant from its
  own source, with per-service capabilities/sub-services/client-data and a
  per-service ec-version (real 1.0 on madrid, integer 1 on the other three
  — the plist types differ).
- IdsHandleFetcher: id-get-handles, the bodiless signed GET the reference
  calls per user before building the body; the register echoes the server's
  handle list on every service instead of inventing one from the username.
- One prekey mint and one kt-loggable-data blob for the whole body: the
  reference mints outside the service loop and clones, and the capture's
  blobs are byte-identical across the four services.
- MadridIdentity.clientData now builds the six identity keys only; the
  per-service capability keys come from the catalog row. Key order matches
  the capture (top-level and per-user).
- RegisterServiceCatalogTest + IdsHandleFetcherTest pin the shape against a
  PII-free projection of the capture
  (registration/src/test/resources/imessage/register-reference-shape.plist).

Nothing here is verified against Apple yet — the next live register is the
first one whose body matches the oracle's.

2026-10-16 21:43:31 +02:00

..

imessage-protocol-spec.md

registration: the register body is capture-exact (rev 51) — four services, id-get-handles, one prekey mint

2026-10-16 21:43:31 +02:00

USAGE.md

JitPack publishing (maven-publish on all modules), docs/USAGE.md, CI + weekly drift probe

2026-10-12 23:36:32 +02:00