# IPFS Client-native Connectivity

AKA multiplexed HTTP transport
AKA federated HTTP proxy nodes

## Problem

The IPFS connectivity model of persistent TCP peer accumulation is a non-starter on mobile devices, web content on non-mobile devices, and resource constrained environments like IoT sensor networks.

IPFS needs a transient connectivity mode which works with existing client transport capabilities and provides an optimal balance of performance and resource utilisation.

HTTP is available everywhere, and has a transient operational model which aligns well with mobile devices and other resource and connectivity constrained runtimes. However a single HTTP endpoint for accessing the IPFS network has all the downsides of HTTP and few of the benefits of IPFS. It also requires a cost and complexity to scale which increases linearly with adoption.

## Proposal

IPFS Client-native Connectivity aims to achieve high performance connectivity while achieving decentralization by balancing load across multiple HTTP peers.

For these platforms, "native" IPFS connectivity will accumulate HTTP gateways as "peers", and balance communication across a set of peers based on a mix of pre-determined algorithm and runtime heuristics.

A specification will be written describing the gateway selection and ordering rules, to inform implementations.

Note: This proposal is strictly scoped to reads at this time.

TODO: Is this is a standalone library? Or a libp2p transport implementation? Both? Or integrated at js-ipfs level?

Ref.
- tldr spec will be trustless and progressive data fetch with HTTP HEAD|GET for `/ipfs/{cid}?format=raw|car[&selector={cid2}]`
- go-ipfs gateway improvements alowing for trustless fetch of IPFS data
- block and car response formats: https://github.com/ipfs/go-ipfs/pull/8758
(`Accept: application/vnd.ipld.raw|car` / `?format=car|raw`)
- efficient cache hit probe: https://github.com/ipfs/go-ipfs/issues/8783
- car selectors (IPLD way of doing range-requests for specific sub-DAGs or byte ranges): https://github.com/ipfs/go-ipfs/issues/8769
- verifiable DNSLink names with DNSSEC proofs: https://github.com/ipfs/go-ipfs/issues/8799
- this would enable use of DNSLinks in trustless contexts

## Client-native gateway multiplexing

*v1 - Static list of HTTP gateways*
The client library has a set of hard-coded gateways, and rotates requests in random order.

*v2 - Runtime gateway selection*
The client library has a set of hard-coded gateways, and selects gateways to use based on runtime heuristics derived from previous request performance, known previous failures, and other available data (connection type, application layer hinting).

*v3 - Gateways to gateways*
The client library has a set of hard-coded bootstrap gateways, from which it receives additional gateways to add to its list.

## TODO: DNS-level gateway multiplexing

eg scatter.xyz redirects requests across a set of HTTP gateways

Maybe this is just crazytalk tho.

## TODO: Writes

This work is currently focused on reads. Feels like writes could be handled by a completely separate protocol/system, or at least layered on later.

Need to make distinction between local and remote writes.

TBD:

* local connectivity such as local subnet and BLE
* custom transports in space communications

Ref.
- writable gateways - meta issue - https://github.com/ipfs/in-web-browsers/issues/189