Skip to content

Commit 175591a

Browse files
committed
📝 T022: Note mpay PlaocService IPC envelope
1 parent 3a153b3 commit 175591a

1 file changed

Lines changed: 12 additions & 2 deletions

File tree

openspec/changes/add-dweb-authorize/proposal.md

Lines changed: 12 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -106,10 +106,19 @@ The concrete runtime entrypoint is still unconfirmed. We must lock it down with
106106
- Candidate A: mpay-style `plaoc.initAppPlaocEventListener((eventId, url, event) => ...)`
107107
- Candidate B: `@plaoc/plugins` `dwebServiceWorker.addEventListener('fetch', (event) => ...)` (request/response IPC)
108108

109+
#### Observed mpay PlaocService (evidence only)
110+
111+
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.
114+
- `getCallerAppInfo(eventId)` reads `event.getRemoteManifest()`.
115+
- `respondWith(eventId, pathname, payload)` serializes JSON `{ "data": payload }` with `application/json`.
116+
- `removeEventId(eventId)` responds with JSON `{ "data": null }`.
117+
109118
### Event ID Format
110119

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
113122
- **Lifetime**: Valid for 5 minutes from creation
114123
- **Single-use**: Each eventId can only be responded to once
115124

@@ -139,6 +148,7 @@ interface CallerAppInfo {
139148
| `/wallet/authorize/signature` | `{ signature: string, txHash?: string }` | `{ error: 'rejected' \| 'timeout' \| 'insufficient_balance' }` |
140149

141150
**Compatibility note (mpay)**:
151+
- mpay wire response uses JSON `{ "data": <payload> }` with `application/json` (and `removeEventId` responds `{ "data": null }`).
142152
- mpay may send/expect raw array payloads (e.g. address returns `addressList` array; signature returns a result array aligned by request index).
143153
- Phase B MUST confirm with runtime samples whether KeyApp should normalize these shapes at the adapter boundary (recommended for smooth mpay migration).
144154

0 commit comments

Comments
 (0)