Repository navigation
Description
Where this stands
zingo-mobile takes the Binding Layer from the Prebuilt Bundles that the Bundle Pin names (zingo-adrs zingo-mobile/0020, zingolib/0059). The pin and the submodule both name 81d799775, zingolib v8.0.0, since #1836 moved them on 2026-10-29 (before it, #1745 moved them to the sixth entry 625f617b6, #1787 to v8.0.0-rc.0, #1829 to rc.1 and #1832 to rc.2). Every consumer builds from the fetched bundles, the nightlies included, and the two fetch jobs are required checks on dev since 2026-10-23. The submodule still exists, and the old build jobs still run with no consumer.
This issue asserts the next step for removing the zingolib submodule dependency. It supersedes #1728 and #1729. zingolib#2930 holds the plan, its rulings and its history; its steps 1 to 5 are done.
Done: one beta release from the bundles (zingolib#2930 step 5)
The release path needs the submodule for nothing. The tag-triggered Android release workflow assembles the APKs from the pinned AAR, and the keep-verifier reads the class list from that AAR. The proof is recorded in the comment below of 2026-11-02: betas 342, 343, 344 and 346 and stable 3.0.0 (324) were assembled from the pinned AAR at 81d799775, each run passing the assembly, the keep-verifier and the release creation, and users tested the betas through 346. Beta 345's run was cancelled and created no release.
Two items of the record are owed by whoever holds them: the Play and App Store Connect build numbers of the beta uploads, and the Mixnet Mode device test, one tester per platform, which proves the one iOS archive and the one mobile profile on a device. Neither gates step 6, since the stable release shipped from the same path.
Next step: delete the submodule (zingolib#2930 step 6)
One pull request deletes the submodule and everything that reaches into it: the two workflows that built the Binding Layer per platform and the workflow that derived their cache key, the action that checked the submodule out, the workflow that ran the Binding Layer's host-side tests (zingolib runs them since zingolib#2937), the action and the scripts that generated the Kotlin bindings on the host and their consumers, the two yarn scripts that built the Binding Layer, and every submodule reference in scripts and docs (the release quickstart still says the libraries build from the submodule). The same pull request updates the glossary, advances the ADR pointer, and moves zingo-adrs zingo-mobile/0020 to accepted and 0016 to superseded. As it merges, branch protection on dev drops the old build contexts and keeps the two fetch checks. Afterwards the LavaMoat stack (#1642, #1646, #1652) rebases onto dev, as ruled on 2026-10-21.
The deletion is #1865, opened 2026-11-02 from dev at 5fd3662, 27 files, +57/-951, with docs/adr advanced to a680cbe, the merge of zingo-adrs#63 (0020 accepted, 0016 superseded). The branch-protection rewrite is its first comment and runs as it merges.
Both of this step's preconditions are met: the dispatched CI nightly of 2026-10-23 passed every job that fetches, builds or installs the app from the bundles, and #1741 selects Xcode 26.3 in both jobs that build the app.
Rulings carried forward
- Nightly failures that predate the consumption merge do not block (ruled 2026-10-23): the two
WalletFileMemoryTestout-of-memory cases on the x86 API 29 emulator, and the Maestro flows 04, 06 and 07. fix(maestro): flow 04 asserts the renamed New contact button #1742 addresses flow 04. - kitchen-sync and zingo-mobile manage their bundles identically (zingolib#2930 ruling 2).
- The submodule is not bumped on its own; the pin and the submodule name one commit while both exist (zingolib#2930 ruling 10).
- This work and zingolib#2833 complete before the JavaScript hardening of Harden the JS supply chain with LavaMoat (allow-scripts + SES lockdown) #1641 resumes (ruled 2026-10-21).
Owed beside the sequence
- zingo-adrs: the acceptance edits of zingolib/0059 and 0060 (0062 already reads
accepted). - zingolib: the publisher App's pull-request write permission, so a publication opens its own record pull request.
- kitchen-sync#8 moves to a current entry.
Updated 2026-11-02: step 5 is recorded as done; step 6 is #1865 with zingo-adrs#63 merged. Updated 2026-10-24: the pin moved to the sixth entry, 625f617b6, with #1745.
Activity
zancas commentedon Nov 2, 2026
Step 5 record
Every Android release since the consumption merge was assembled from the pinned AAR. The pin and the submodule named 81d799775 (zingolib v8.0.0, pinned by #1836 as 2f86c7fba) at each tagged commit, under zingolib#2930 ruling 10. In each run the steps
Assemble APKs (4 ABI splits + universal),Verify R8 kept the uniffi bindingsandCreate GitHub Releasepassed, and the release holds the five APKs.zingo-beta-3.0.0-342zingo-beta-3.0.0-343zingo-beta-3.0.0-344zingo-beta-3.0.0-345zingo-beta-3.0.0-346zingo-3.0.0-324Users tested the betas through 346, and the fixes they reported merged between them (#1833 to #1848). Stable 3.0.0 (324) shipped from the same path on 2026-10-31. The last release built from the submodule was 2.1.1 (323) on 2026-10-20, run 39496421890.
Two items of step 5 are unrecorded here: the Play and App Store Connect build numbers of the beta uploads, and the Mixnet Mode device test, one tester per platform. Whoever uploaded the builds or ran the test adds them in a reply. The deletion of step 6 opens on this record.
zancas commentedon Nov 3, 2026
Step 6 is done. #1865 merged on 2026-11-03 as e1a38da after juanky201271's review. Branch protection on
devwas rewritten before the merge and requires the 14 surviving contexts.Two pull requests follow it. #1866 deletes the residues the review found in the quickstarts, the scripts, four workflow checkouts, the ignore list, the Gradle source set and the lint suppression. #1868 restores the mixnet marker cross-check against zingolib at the pinned commit.
Still owed beside this issue: the LavaMoat stack rebases onto
dev, and the record above lacks the store build numbers and the Mixnet Mode device test.