Skip to content

Console: register the mobile shell's native push token after sign-in, unregister it on sign-out #29042

Open

Description

@hotlong

Blocked-by: #29039
Blocked-by: #29041

Context

The mobile shell (objectstack-ai/mobile#144) exposes ObjectStackNative.getPushToken(). It resolves to { token, vendor: 'apns' | 'fcm' }, or null on a simulator, when permission is denied, or when no token is available. The first call shows the OS permission prompt, so the Console decides when that happens. The shell holds no API credential, so the registration must come from the Console under its own session.

Ask

  1. After sign-in in shell mode (useNativeHost() from @object-ui/mobile: shell mode — detect window.ObjectStackNative and adapt the Console when the mobile shell hosts it #29039, with has('getPushToken') true), call getPushToken() and register the token with the device registry from Push channel: build the device registry routes (/notifications/devices) and the APNs + FCM transport that ADR-0012 marks "MUST ship M1" #29041.
  2. Unregister the token on sign-out and on account switch.
  3. Re-register when the token changes; compare with the last registered value kept per session.
  4. Choose the moment of the permission prompt deliberately: after the first meaningful screen, not during sign-in. Do nothing when the call resolves null.

Acceptance

  • With a fake bridge, sign-in registers the token, sign-out unregisters it, and null leads to no request.
  • An end-to-end check on a device build receives a push and opens the payload's route. This is recorded as a manual run if no device lab exists.

Activity

  1. objectstack-fleet commented on Nov 2, 2026

    @objectstack-fleet
    Contributor

    triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U

    Path: none

    Triage: p2 · domain:ui · pm:blocked · 2026-11-02T06:36Z

    ⛔ Not a claim.


    Generated by Claude Code

  2. objectstack-fleet commented on Nov 2, 2026

    @objectstack-fleet
    Contributor

    repo:mobile#1 · os-justin · session_01QSeKYnW1Xf6HDSWz1eGAqv

    Shell side of this card's ask 3 (token rotation) and the duplicate-device fix, from objectstack-ai/mobile#163 → PR objectstack-ai/mobile#167. The seat has accepted the PR; it awaits the maintainer's merge.

    What the shell now offers the Console. Everything is feature-detected, so the Console can ship before an updated shell is installed.

    Unlock rule for the pm:blocked state on this card is unchanged. This comment only records the shell half. The source of truth for the bridge contract is mobile's docs/HYBRID-SHELL.md once objectstack-ai/mobile#167 merges.

  3. objectstack-fleet commented on Nov 2, 2026

    @objectstack-fleet
    Contributor

    domain:ui#5 · zhuangjianguo · session_01QsR2jQjvWkZ7is6GXbC6DB

    Seam for this card's unregister half · 2026-11-02T20:56Z

    PR #29565 (#29458) merged at 2026-11-02T20:55Z. The Console now answers the shell's objectstack-native:connectionRemoved event inside useNativeHostRouting (@object-ui/mobile). Today it calls event.waitUntil() with a promise that resolves at once, because no Console path registers a device yet.

    When this card registers the push token, it also owes the matching unregister. Pass onConnectionRemoved: () => <unregister this device under the Console's own session> to the Console's useNativeHostRouting call (NativeShellRouting). The shell is held until that promise settles, for at most 10 s. A rejected promise releases the shell, which then records the token as left registered. No other wiring is needed.

  4. objectstack-fleet commented on Nov 3, 2026

    @objectstack-fleet
    Contributor

    domain:spec#3 · os-support-ai · session_01WGufzfgvGexKn9vLHsy89K

    Carried here from the contract review of PR #29767 (record 6595157663, PASS), which adds an optional origin to RegisterDeviceRequest (#29642, ruling B 6593872191). This card is the Console producer for it.

    When the Console fills origin from window.location.origin, send it only when window.location.protocol is http: or https:. In a sandboxed iframe, or an about:blank / data: context, window.location.origin answers the opaque "null". The spec grammar refuses that value, and the refusal is a 400 on the whole POST /api/v1/notifications/devices body, so the device would not register at all. Leaving origin out in that case keeps registration working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions