null
/
Closer
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs(manual): batch 6 - fix broken iOS-Android sealed-answer bridge anchor (→ slug mismatch)

This commit is contained in:
null 2026-07-11 16:25:36 -05:00
parent 690b567f82
commit f336c91731
2 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Engineering_Reference_Manual_Plan.md
View File

@ -70,4 +70,4 @@ catalog start).
| 3 | Cloud Functions: webhook handler | Line 831 (per-module responsibilities) said "RevenueCat webhook (source-only; not exported/deployed)" — fixed to "exported; deploy gated on `REVENUECAT_WEBHOOK_SECRET`". All other webhook-related lines (843-844, 905-908, 910) were already updated by 89d06eeb itself. | (this commit) | | 3 | Cloud Functions: webhook handler | Line 831 (per-module responsibilities) said "RevenueCat webhook (source-only; not exported/deployed)" — fixed to "exported; deploy gated on `REVENUECAT_WEBHOOK_SECRET`". All other webhook-related lines (843-844, 905-908, 910) were already updated by 89d06eeb itself. | (this commit) |
| 4 | Engineering conventions: copy catalog + string resource cleanup | None — the manual already references `docs/copy-guide.md` (line 1063) as the source of voice; the new `CloserCopy` Kotlin catalog is internal implementation tracked in `docs/CopyMigration.md` and doesn't change the voice contract. The 55 purged string resources were already off-grid (no manual references to `strings.xml`). | (no-op) | | 4 | Engineering conventions: copy catalog + string resource cleanup | None — the manual already references `docs/copy-guide.md` (line 1063) as the source of voice; the new `CloserCopy` Kotlin catalog is internal implementation tracked in `docs/CopyMigration.md` and doesn't change the voice contract. The 55 purged string resources were already off-grid (no manual references to `strings.xml`). | (no-op) |
| 5 | Notifications / FCM: qa_push.js | None — the manual documents the production FCM token pipeline (TokenRegistrar → onAnswerWritten → fcmTokens subcollection fan-out, line 963+) but does not reference the `qa/qa_push.js` helper script. The c60fa958 fix only changes how the QA helper picks a token (newest instead of `docs[0]`); the production path is unchanged. | (no-op) | | 5 | Notifications / FCM: qa_push.js | None — the manual documents the production FCM token pipeline (TokenRegistrar → onAnswerWritten → fcmTokens subcollection fan-out, line 963+) but does not reference the `qa/qa_push.js` helper script. The c60fa958 fix only changes how the QA helper picks a token (newest instead of `docs[0]`); the production path is unchanged. | (no-op) |
| 6 | TOC + anchor integrity | TBD | TBD | | 6 | TOC + anchor integrity | 1 broken anchor: `### iOS → Android sealed-answer bridge (...)` had a `→` in the heading text; the auto-generated slug was `ios--android-sealed-answer-bridge-wrapreleasekeycallable` (double dash) but the TOC + the in-text link both pointed to `ios-android-sealed-answer-bridge-wrapreleasekeycallable` (single dash). Fixed by adding an explicit `{#ios-android-sealed-answer-bridge-wrapreleasekeycallable}` anchor. Re-run: 62/62 TOC + 62/62 in-text anchors resolve. | (this commit) |

2
docs/Engineering_Reference_Manual.md
View File

@ -458,7 +458,7 @@ The commitment hash lets the reveal step verify that the decrypted payload match
`UserKeyManager.kt` documents a known limitation: there is **one keypair per user, stored only on the device that created it**. If a user signs in on a second device and generates a new keypair, sealed answers whose keys were wrapped for the old public key become undecryptable. The fix path is multi-device key distribution, but it is not implemented. **Do not market multi-device support** until this is resolved. `UserKeyManager.kt` documents a known limitation: there is **one keypair per user, stored only on the device that created it**. If a user signs in on a second device and generates a new keypair, sealed answers whose keys were wrapped for the old public key become undecryptable. The fix path is multi-device key distribution, but it is not implemented. **Do not market multi-device support** until this is resolved.
### iOS → Android sealed-answer bridge (`wrapReleaseKeyCallable`) ### iOS → Android sealed-answer bridge (`wrapReleaseKeyCallable`) {#ios-android-sealed-answer-bridge-wrapreleasekeycallable}
iOS does not implement Tink's `ECIES_P256_HKDF_HMAC_SHA256_AES128_GCM` locally, so it cannot produce a `keybox:v1:` that Android can unwrap. Instead, iOS calls the server-side `wrapReleaseKeyCallable` (`functions/src/releaseKey/wrapReleaseKeyCallable.ts`) with its one-time AES-256 answer key and the recipient's Tink public key. The Cloud Function performs the Tink wrap using the Admin SDK and returns a `keybox:v1:` string that Android's `ReleaseKeyEncryptor` can decrypt. The function is strict-coupled: caller and recipient must be the two members of an active couple, and the recipient must have published a device public key at `users/{recipientUserId}/devices/primary`. iOS↔iOS sealed-answer releases continue to use the native Path A envelope and do not require this bridge. iOS does not implement Tink's `ECIES_P256_HKDF_HMAC_SHA256_AES128_GCM` locally, so it cannot produce a `keybox:v1:` that Android can unwrap. Instead, iOS calls the server-side `wrapReleaseKeyCallable` (`functions/src/releaseKey/wrapReleaseKeyCallable.ts`) with its one-time AES-256 answer key and the recipient's Tink public key. The Cloud Function performs the Tink wrap using the Admin SDK and returns a `keybox:v1:` string that Android's `ReleaseKeyEncryptor` can decrypt. The function is strict-coupled: caller and recipient must be the two members of an active couple, and the recipient must have published a device public key at `users/{recipientUserId}/devices/primary`. iOS↔iOS sealed-answer releases continue to use the native Path A envelope and do not require this bridge.