chore(release): 0.28.0

[kivtxs]

The 0.28.0 cut, following CONTRIBUTING's "Cutting a Release". It touches the same file set as #460 (0.27.0).

Merge order

Merge this last. It renames ## [Unreleased] to ## [0.28.0] — 2026-10-06, so anything that lands after it would be described under a release it isn't in.

Already on main: #504 (Android library artifact id) and #505 (Android Wi-Fi Direct fixes). #508 (demo app) was closed. Still to merge, in any order:

• fix(protocol,mls): report a key package refused by this device's clock #506: clock-skew warning;
• feat(bindings): Android forms its Wi-Fi Direct group itself, without a system dialog #507: Android Wi-Fi Direct group formation (now rebased onto main after fix(bindings): Android Wi-Fi Direct sends at once, rejoins its group, and starts from the config #505's squash, so it shows only its own three commits);
• fix(bindings): Bluetooth peers find each other in busy rooms, and Android survives Bluetooth toggles and stack crashes #511: Bluetooth discovery in busy rooms, plus Android surviving Bluetooth toggles and stack crashes.

This branch currently stacks the remaining three (main + merges of each + the release commit), so its CI tests exactly the tree 0.28.0 would ship. You can also merge it alone: it carries their commits unchanged.

Then rebase this branch; I'll do it if you'd like. The only expected conflict is the changelog heading line. Update the date to the day you tag.

docs/UPGRADING.md §26 already describes #505, #506, #507 and #511's change to neighbor_lost. If any of them doesn't make 0.28.0, drop its paragraph; I can do that too.

What changed

• Versions to 0.28.0:
  • Cargo.toml: [workspace.package] plus the 11 internal deps;
  • the four local deps in offline-protocol-sealed and offline-protocol-leaf;
  • Cargo.lock, tools/embedded-footprint/Cargo.lock, tools/mls-interop/Cargo.lock (refreshed with cargo metadata; only our own crates moved);
  • bindings/python/pyproject.toml;
  • bindings/react-native/package.json and its lockfile (npm version 0.28.0 --no-git-tag-version).
• THIRD-PARTY-NOTICES.md (×3): regenerated with scripts/generate-third-party-notices.sh and cargo-about 0.9.1, the pinned version.
• CHANGELOG.md: Unreleased becomes 0.28.0. The 0.27.0 section moves to the new docs/changelog/0.27.md, with its title and release table, and a row in both archive tables.
• Moved links: ](docs/…) becomes ](../…) (four of them).
• The move is lossless: re-extracting the section from HEAD:CHANGELOG.md and applying the same rewrite gives the archived text exactly, apart from one trailing blank line.
• SECURITY.md: the current line is 0.28.x; earlier lines are ≤ 0.27.x.
• docs/UPGRADING.md:
  • the current line is v0.28.x;
  • seven releases since 0.17 can now break a build. 0.28.0's two breaks: iOS peer streams move to Network framework, so an iPhone on 0.28 doesn't see one on ≤ 0.27 over that slot, and Python's InternetManager now requires app_id=;
  • a 0.28.0 summary paragraph;
  • a new §26, "Behaviour that changes without a compile error (v0.28.0)".

Verification

• cargo test -p offline-protocol-core -p offline-protocol-leaf --lib local_dep_versions (the version guards): pass.
• cargo check --workspace --locked: clean.
• cargo test -p offline-protocol-uniffi --lib (the bridge guards): 189 passed.
• Markdown links: every relative ](path#anchor) in every tracked file, resolved against real headings. No new breakage; the only two flagged are the illustrative ](docs/…) and ](path#anchor) in CONTRIBUTING itself.

Device validation of this tree (two Android phones, Infinix NOTE 12 on Android 13 and Seeker on Android 15)

Area	Result
Wi-Fi Direct group formation (#507), Bluetooth off, location not granted	8/8 clean starts, 18 to 225 s (median about a minute), no system dialog
Wi-Fi Direct chat	30/30, p50 73 to 82 ms; 40-round soak 80/80 received, 79/80 receipts (see below)
App restart / 30 s Wi-Fi outage / group chat	stream re-proved in 3 s / 3 of 3 queued messages delivered after Wi-Fi returned / 3/3 each way
Bluetooth only	discovery 2 s; 30-round soak 30/30 each way, with receipts
Bluetooth toggled on both phones, 3 rounds (#511)	one neighbor_lost per phone; relinked in 7, 21, 4 s (never, before)
Both carriers, then Bluetooth off, then Wi-Fi off (#505 be01882a)	no false loss while Wi-Fi Direct holds; one neighbor_lost per phone when nothing is left
DORS with both carriers	routes Wi-Fi Direct (p50 59 to 88 ms), falls back to Bluetooth at once when Wi-Fi drops
Clocks 40 days apart (#506)	KEY_PACKAGE_OUTSIDE_VALIDITY_WINDOW once per phone; demo alert shown; messaging after the clock is fixed
App in background	2/2 received
Mesh services	ping.v1 discovered, pong received
Whole final session, toggles included	43/43 each way: sent = received = receipts

Seen and not fixed in 0.28.0:

• Event gaps: twice, one message in a 30-message soak arrived with a receipt but no message_received in the receiver's JS log, and once a receipt was missing in a 40-round soak. Not reproduced in the 86 messages after native-side event logging was added; I'll keep watching.
• Pre-existing Android BLE behaviour, issues to follow:
  • after a reconnect, writes from an address the server hasn't mapped to a peer wait for a resolution dial (seconds to about 40 s; retries deliver);
  • a peer that switches Bluetooth off stays listed for over a minute on the other phone (a clean disconnect is treated as transient).
• Flaky relay test: mesh relay: a message can die inside a dense cluster when no fan-out ever picks the one bridge node (mesh_forwarding flake, ~1.5%) #510.

After merge (from CONTRIBUTING)

1. Optional rehearsal: push v0.28.0-rc.1, or a workflow_dispatch with dry_run: true, version: 0.28.0. That checks npm OIDC before anything is permanent.
2. Push v0.28.0.
3. gh workflow run publish.yml -R Offline-Protocol/offline-protocol-swift -f version=0.28.0. This is the first release with a Swift package.
4. Maven Central and PyPI stay behind their switches (MAVEN_CENTRAL_PUBLISH, PYPI_PUBLISH), unchanged here.

For the release run

One flaky test appeared in CI today: mesh_forwarding::everyone_hearing_everyone_does_not_multiply_the_traffic (#510, about 1.5%). It failed on #508, a demo-only change, and on an earlier run on main (36897622339); the failure is non-delivery (far's inbox empty). A flake in the tag's run means a re-run, not a new patch version, but it's worth knowing before you push the tag.