Open a dapp that reads TN from the browser inside a wallet's in-app browser, and every view call comes back 401 cookie not found. The gateway is reachable and its chain info answers, but nothing that needs a session works: no order books, no balances, no positions. The page either sits empty or has to fall back to the indexer.
The gateway authorises view calls with the session cookie __Host-kgw_session (SameSite=None, Secure). For any app not served from truf.network, that is a third-party cookie. Android WebView, which Trust Wallet and most wallet browsers are built on, drops third-party cookies unless the host app opts in, and iOS WKWebView does much the same. A browser script cannot work around it: Cookie is a forbidden header, so kwil-js can only fall back to cookies in the browser, and @trufnetwork/sdk-js inherits that.
Confirmed from inside Trust Wallet on Android 13 (…; wv) … Chrome/151), with a diagnostics page that checks each dependency in turn:
- Indexer: ✓ (9 settlements)
- Gateway reachable, no sign-in: ✓ (
chain tn-v2.1, block 2630247)
- Gateway sign-in (
kgw.authn): ✕ 401
- Order book read: ✕ 401
Reproducible in Chromium with --test-third-party-cookie-phaseout: a fresh load of a client-side TN app makes 32 user.calls and gets 32 401s, keeps no cookie, and shows no prices. The same load in a normal browser works.
This is not specific to one venue. It affects any third-party app that reads TN from the browser, including predict.truflation.com, whose order book, balance and positions fail the same way in a wallet browser; its prices survive only because they are read on its own server. Wallet in-app browsers are how a large share of users open a dapp, so today every such app has to proxy its reads through a server it owns, which a static or fully on-chain frontend cannot do.
Writes are unaffected: broadcasting a transaction and the info.actions catalogue query both work without a session, so a user in that browser can sign a trade but cannot see the book they are trading into.
The fix belongs at the gateway: let a caller carry its session without a cookie. An Authorization: Bearer <token> header returned by the existing kgw.authn exchange would do it, with the cookie kept for the browsers that allow it. Alternatively, let view calls through unauthenticated (they are public reads), or expose the choice per deployment. Whichever way, @trufnetwork/kwil-js and @trufnetwork/sdk-js then need to accept and send that token in the browser, since today only the Node path can set a header.
Worth deciding alongside this: whether first-party reads should stop depending on a cross-site cookie at all, since serving an app from a *.truf.network subdomain is currently the only way a browser dapp gets a reliable session.
Done when a browser app served from an origin outside truf.network can read order books, balances and positions from the gateway in Trust Wallet's in-app browser, with third-party cookies blocked, and the SDK offers that path without the app touching kwil-js internals.
Deadline
ETA: undefined
Open a dapp that reads TN from the browser inside a wallet's in-app browser, and every view call comes back
401 cookie not found. The gateway is reachable and its chain info answers, but nothing that needs a session works: no order books, no balances, no positions. The page either sits empty or has to fall back to the indexer.The gateway authorises view calls with the session cookie
__Host-kgw_session(SameSite=None, Secure). For any app not served fromtruf.network, that is a third-party cookie. Android WebView, which Trust Wallet and most wallet browsers are built on, drops third-party cookies unless the host app opts in, and iOS WKWebView does much the same. A browser script cannot work around it:Cookieis a forbidden header, so kwil-js can only fall back to cookies in the browser, and@trufnetwork/sdk-jsinherits that.Confirmed from inside Trust Wallet on Android 13 (
…; wv) … Chrome/151), with a diagnostics page that checks each dependency in turn:chain tn-v2.1, block 2630247)kgw.authn): ✕ 401Reproducible in Chromium with
--test-third-party-cookie-phaseout: a fresh load of a client-side TN app makes 32user.calls and gets 32 401s, keeps no cookie, and shows no prices. The same load in a normal browser works.This is not specific to one venue. It affects any third-party app that reads TN from the browser, including predict.truflation.com, whose order book, balance and positions fail the same way in a wallet browser; its prices survive only because they are read on its own server. Wallet in-app browsers are how a large share of users open a dapp, so today every such app has to proxy its reads through a server it owns, which a static or fully on-chain frontend cannot do.
Writes are unaffected: broadcasting a transaction and the
info.actionscatalogue query both work without a session, so a user in that browser can sign a trade but cannot see the book they are trading into.The fix belongs at the gateway: let a caller carry its session without a cookie. An
Authorization: Bearer <token>header returned by the existingkgw.authnexchange would do it, with the cookie kept for the browsers that allow it. Alternatively, let view calls through unauthenticated (they are public reads), or expose the choice per deployment. Whichever way,@trufnetwork/kwil-jsand@trufnetwork/sdk-jsthen need to accept and send that token in the browser, since today only the Node path can set a header.Worth deciding alongside this: whether first-party reads should stop depending on a cross-site cookie at all, since serving an app from a
*.truf.networksubdomain is currently the only way a browser dapp gets a reliable session.Done when a browser app served from an origin outside
truf.networkcan read order books, balances and positions from the gateway in Trust Wallet's in-app browser, with third-party cookies blocked, and the SDK offers that path without the app touching kwil-js internals.Deadline
ETA: undefined