Skip to content

Add reusable native activity cards with SDK source context - #89

Draft
WeiR-h wants to merge 3 commits into
hagency-org:mainfrom
WeiR-h:native-activity-card-contract
Draft

WeiR-h wants to merge 3 commits into
hagency-org:mainfrom
WeiR-h:native-activity-card-contract

Conversation

@WeiR-h

@WeiR-h WeiR-h commented Oct 10, 2026 •

Copy link
Copy Markdown

Activity messages currently have no generic native application locator. This adds a versioned org.rinx.native.activity pointer, a timeline card and MiniAppAction::OpenNative. The action retains SDK room, server event and sender context; the current account comes from the SDK. Cards cannot carry credentials, authorization, actions or executable URLs.

Unknown versions or malformed fields use the existing unsupported-card flow. Standalone clients explain that a compatible native host is needed. A receiving host must re-fetch the source, validate identity, target membership and the authoritative application resource, then display or focus it. Enrollment and sends still require separate approval.

Validation at 83f83a1: Windows/Linux CI and complete Windows hosted-client compilation passed. The 35 portable mini-app tests include malformed IDs, forged fields, versions and IPv6 server syntax. The English/Chinese catalog check passed (1,588 entries). The workflow uses the VS 2022 image supported by the pinned CMake dependency. Rendered generic-card interaction and concrete shell navigation are still pending; this remains a draft for integration review.

Proposed host seam: OctoSense-org/OctoSense#468. BuWei supplies the real activity/receipt use case: https://github.com/WeiR-h/buwei. No local dependency paths or new external pins; neither proposal implies upstream adoption.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant