Skip to content

RFC: Contacts API#17

Open
filvecchiato wants to merge 3 commits into
mainfrom
rfc/0014-contacts-api
Open

RFC: Contacts API#17
filvecchiato wants to merge 3 commits into
mainfrom
rfc/0014-contacts-api

Conversation

@filvecchiato
Copy link
Copy Markdown
Collaborator

@filvecchiato filvecchiato commented Apr 23, 2026

RFC: Contacts API

Summary

Exposes the user's host-managed address book to products via Host API. Each contact pairs local metadata with a context-scoped map keyed by ProductAccountId, enabling products to resolve human-readable identities to accounts.

Checklist

  • Added docs/rfcs/0014-contacts-api.md with completed frontmatter
  • Filled all RFC sections (Summary, Motivation, Detailed Design, Drawbacks, Alternatives, Unresolved Questions)
  • Updated docs/rfcs/_index.md with a link to the new RFC
  • Added labels: rfc, proposal

Motivation

Products need to resolve human-readable identities to accounts. Without this API, users must paste raw keys or scan QR codes for every interaction. Renumbered from 0011 to 0014. Migrated from paritytech/triangle-js-sdks#137.

- Rewrite motivation: frame around privacy model (alias-per-context),
  contact list as private mapping notebook, social circle analogy
- Replace generic bullet points with concrete value propositions
- Note that hosts already have internal contact schemas
- Clarify ContactContext/Ring VRF type relationship and DerivationIndex need
- Fix tier 1 safety explanation
- Add context: Option<DotNsIdentifier> parameter to host_contacts_get
- Flesh out alternatives with clear rationale
- Add unresolved question about contact ingestion
- Expand pagination concern
- Clarify that new DevicePermission variants are defined in this RFC,
  not as an amendment to RFC-0002 (@Imod7)
- Document when each ContactsErr variant is returned
- Explain what tier 1 reveals vs what a product already knows: the
  product knows its own user's alias but not other users' aliases in
  the same context (@BigTava)
- Flesh out alternatives with concrete examples and threat model so
  trade-offs are easier to evaluate (@BigTava)
pgherveou added a commit that referenced this pull request May 17, 2026
Products running in a WebView/WKWebView now connect to the Rust core
through the localhost WebSocket bridge instead of a base64-over-
JavascriptInterface (Android) / base64-over-WKScriptMessageHandler (iOS)
shim. The Rust ws_bridge already existed; this commit adds the
matching JS client and strips the obsolete native transport.

@parity/truapi:
- New `createWebSocketProvider(url, opts?)` producing a `Provider` over
  a binary WebSocket. Connects to the localhost endpoint the native
  shell prints via `startWsBridge`.

android/TrUAPIHost.kt:
- Drop `WebViewTransport`, `CoreInbound`, `bootstrapScript`, and all
  base64/JavascriptInterface plumbing.
- `TrUAPIHostCore` keeps its `receiveFromProduct` entrypoint for tests
  and alternative transports; the WS bridge feeds the core internally.

ios/TrUAPIHost.swift:
- Drop `WebViewTransport` (`WKScriptMessageHandler` + base64 path) and
  `CoreInbound` protocol. Drop the `WebKit` import.
- Keep `LocalhostBridgeBootstrap` — its purpose is exactly to publish
  the WS endpoint to the product page so it can call
  `createWebSocketProvider(url)`.

READMEs for both native shells now describe the WS-bridge flow:
1. Host calls `core.startWsBridge()` → gets port + token.
2. Inject the endpoint into the product page (Android: query string;
   iOS: `LocalhostBridgeBootstrap.script()` as a WKUserScript).
3. Product JS reads the URL and passes it to `createWebSocketProvider`.

@parity/truapi build + tests pass with the new export.
@filvecchiato filvecchiato changed the title RFC-0014: Contacts API RFC: Contacts API Jun 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant