Skip to content

feat: prefer browser-system and REST for XL1 website integration - #85

Merged
arietrouw merged 4 commits into
mainfrom
develop
Sep 10, 2026
Merged

arietrouw merged 4 commits into
mainfrom
develop

Conversation

@arietrouw

Copy link
Copy Markdown
Member

Integration PR. Merge with "Create a merge commit" — never squash. Squashing develop into main leaves phantom commits in git log main..develop that accumulate over time, since both branches are long-lived.

What ships

Browser-system and REST guidance (#84) — names @xyo-network/xl1-browser-system as the preferred way to integrate XL1 into a website, and REST as the preferred chain-read transport when configuring it.

React dApps stay on InPageGatewaysProvider, which already launches a browser system per network internally, but must pass transport="rest" because the prop still defaults to 'rpc'. Non-React realms (plain pages, web workers, service workers, extension backgrounds) launch launchXl1BrowserGatewaySystem directly. REST changes reads only; mempool submission still goes over the RPC url.

  • xl1-knowledge — new "Integrating XL1 Into a Website" section in gateway-browser.md; router, skill description, package map, and the gateway.md transports section updated to match
  • xl1-patternstransport="rest" on every in-page provider snippet, a transport subsection in in-page-datalakes.md, new gates in dapp-checklist.md
  • xl1-scaffold — the react template now ships the provider stack wired for REST, where it previously had no gateway provider at all
  • xl1-testingbrowser-mode.md drops the deprecated buildGateway

Block clock correction (5ca476b) — $epoch is leftover client meta rather than the block clock. The signed network.xyo.time payload is, read via timePayloadOfBlock / epochOfBlock. Nothing that gates qualification, finality, or head selection should accept $epoch.

Verification

All checks passed on #84: skill validation, marketplace manifest rendering, conventional title, and the scaffold sync check.

🤖 Generated with Claude Code

JoelBCarter and others added 4 commits August 31, 2026 13:29
chore: sync main → develop after v1.1.33
Names `@xyo-network/xl1-browser-system` as the preferred way to integrate
XL1 into a website, and REST as the preferred chain-read transport when
configuring it.

React dApps stay on `InPageGatewaysProvider` — it already launches a
browser system per network internally — but must pass `transport="rest"`,
since the prop still defaults to `'rpc'`. Non-React realms (plain pages,
workers, service workers, extension backgrounds) launch
`launchXl1BrowserGatewaySystem` directly.

- xl1-knowledge: new "Integrating XL1 Into a Website" section in
  gateway-browser.md covering entry point per app shape, the REST rule and
  endpoint semantics, compile-then-launch, and anti-patterns; router,
  package map, and the transports section updated to match
- xl1-patterns: `transport="rest"` on every in-page provider snippet, a
  transport subsection in in-page-datalakes.md, and new checklist gates
- xl1-scaffold: the react template now ships the provider stack wired for
  REST instead of a bare connect button
- xl1-testing: browser-mode.md drops the deprecated `buildGateway`

Also corrects a stale react-chain version reference (5.0.15 -> 5.5.3).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@arietrouw
arietrouw merged commit 999fe14 into main Sep 10, 2026
7 checks passed
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.

2 participants