You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The legacy mpay implementation strongly suggests Candidate B is real in practice:
112
+
113
+
- Wallet listens via `dwebServiceWorker.addEventListener('fetch', ...)` and generates an internal `eventId` like `eventId:${Date.now()}` to correlate UI with the captured fetch event.
-`removeEventId(eventId)` responds with JSON `{ "data": null }`.
117
+
109
118
### Event ID Format
110
119
111
-
-**Source**: Generated by DWEB runtime when triggering authorization
112
-
-**Format**: TBD (treat as opaque identifier). Note: if Candidate B is used, the underlying request correlation id is a numeric `reqId`.
120
+
-**Source**: Wallet-side listener generates an internal eventId (used to correlate UI flow with the underlying IPC event)
121
+
-**Format**: Opaque string (mpay uses `eventId:${Date.now()}`); if Candidate B is used, an underlying numeric `reqId` may exist but does not need to be exposed
113
122
-**Lifetime**: Valid for 5 minutes from creation
114
123
-**Single-use**: Each eventId can only be responded to once
- mpay may send/expect raw array payloads (e.g. address returns `addressList` array; signature returns a result array aligned by request index).
143
153
- Phase B MUST confirm with runtime samples whether KeyApp should normalize these shapes at the adapter boundary (recommended for smooth mpay migration).
0 commit comments