Platform API overview

@fkn/lib gives browser apps networking and page-automation primitives that the web platform does not provide on its own. The cloud networking APIs and isolated frame backend are available directly from browser code with no extension or account. Cloud storage is separate and requires a connected account. The optional extension adds a second backend for capabilities that should run in the user’s browser.

The cloud surface today:

API	What it gives you
`cloud.fetch`	HTTP fetch routed through the FKN proxy, reaching APIs a browser otherwise cannot
`cloud.net`	Node.js-style TCP sockets (`Server`, `Socket`, `connect`) over WebTransport or WebSocket
`cloud.dgram`	Node.js-style UDP sockets (`createSocket`) over WebTransport or WebSocket
`cloud.http`	HTTP client primitives built on the socket layer
`cloud.dns`	DNS-over-HTTPS lookups
`cloud.attachFrame`	Page automation on an embedded frame, rendered through the FKN proxy
`cloud.quota`	The user’s egress quota and throttle state

import { 
(alias) namespace cloud
import cloud
cloud } from '@fkn/lib'

const 
const response: Response
response = await 
(alias) namespace cloud
import cloud
cloud.
cloud_d_exports.fetch(input: string | Request | URL, init?: (RequestInit & {
    render?: boolean;
}) | undefined): Promise<Response>
export cloud_d_exports.fetch
fetch('https://example.com/api/catalog')

The net and dgram shapes are also published standalone as @webvpn/net and @webvpn/dgram, which is how projects like libtorrent-wasm run a BitTorrent client in the browser.

The root net, dgram, http, and dns exports are aliases of these cloud implementations today. Bare fetch() can choose between the extension and cloud, while attachFrame() has a separate extension-or-cloud rule. The desktop namespace is a typed placeholder for a future backend. See API backends for the exact behavior.

Platform networking primitives by execution backend

All APIs below are called from browser code. The columns show which backend performs the work.

API / feature	Extension	Cloud	Desktop
`fetch`	Supported	Supported	Planned
`net (TCP)`	Not available	Supported	Planned
`dgram (UDP)`	Not available	Supported	Planned
`http`	Not available	Supported	Not available
`dns`	Not available	Supported	Not available
`attachFrame`	Supported	Supported	Not available
`quota`	Not available	Supported	Not available

Socket transports and throughput

Socket APIs prefer WebTransport and fall back to WebSocket when WebTransport is unavailable or does not become ready. Safari therefore uses WebSocket, while supported Chromium and Firefox versions normally start with WebTransport.

On the WebTransport path, TCP sockets ride QUIC streams with flow control and congestion control. UDP sent from the browser uses WebTransport datagrams. Since @fkn/lib 0.4.2, server-to-browser UDP uses one QUIC stream per socket, avoiding Chromium’s datagram pacing cap on that direction while preserving UDP semantics for application code. Prefer TCP for bulk transfer when the remote service offers both.

Free-tier usage has a 5 GB daily allowance and is throttled after that point. Connected traffic is metered per account; anonymous traffic is metered per IP. No account is required, and an app can read the current quota and throttle rate.