# [IPFS (HTTP) client - protocol, use-cases, spec](https://hackmd.io/w3a0zRXJR_6mThuqEdBs_g)

## Actions

* "transport gateway" spec
* wip: see "TRUSTLESS_GATEWAY.md" in https://github.com/ipfs/specs/pull/283
* "http ipfs client" spec
* ideally, have draft with basic outline ready before the [next IPFS gathering]
* (prerequisite: [rfc process](https://github.com/ipfs/specs/issues/286))
* Dietrich will block time on calendar to outline "client spec" things with lidel
* **UPDATE: WE ARE DOING IPIP DRAFT IN https://hackmd.io/v0BxUlrASRmT2PYm5oeSeQ**

## Summary (one sentence)

Summary: An IPFS client specification for maximally decentralized operation of IPFS in non-server platforms, optimized for retrieving data.

TODO:
* needs http-only support added
* needs trustlessness added

What makes a light client "native":
* zero delegation of trust (content cannot be modified)
* decentralization (>1 server)

## Users

* web content
* web browsers (desktop and mobile)
* mobile apps/browsers
* IoT
* low power devices
* low bandwidth devices
* http clients mitigating censorship

## Requirements

* Must be able to operate transiently (not persistently running)
* Must be language agnostic (so, a spec)
* Must support low-power
* Must be able to operate fully when only HTTP is available
* Must be able to operate fully in web content
* Must be able to operate fully in native mobile apps
* Must be able to trustlessly use gateways
* Must be able to use multiple gateways per-request
* Must be able to use gateways as block-level "peers"

## Gateway paradigm

Don't limit client's choice of gateway.
Don't delegate any trust to the gateway.
Do only safe things.

Specs: https://github.com/ipfs/specs/tree/feat/gateway-specs/http-gateways

Trustless vs full gateway
* data-only gateway
* not a "webserver"
* block gateway

Light client uses subset of trustless gateway.
* uses no paths

## Web Servers and Rendering Web Content

## Evaluated options

We looked into various options in https://github.com/ipfs/in-web-browsers/issues/128 and leveraging raw block and CAR response format on gateways is so far the best option, considering the gateways already exist, CAR format already exists, and we will be leveraging existing infra.

go-ipfs 0.13 will ship with `?format=raw|car`, allowing us to prototype light client specs and libraries based on regular gateways.

## Use cases

Users who are not able to run local IPFS node with p2p stack, but still could get full integrity guarantees provided by content-addressing if they have software capable of re-calculating CIDs based on gateway responses.

* mobile browsers (e.g. brave)
* iot devices
* package managers, bash scripts that need one-off, verifiable download
* additional transport for regular IPFS nodes

## Needs

## Lite Client spec

TODO: research use cases, identify

## Trustless gateway spec

* use-case: HTTP endpoint consumed by light client
* fetching content-addressed data from any public HTTP gateway
* fetching block by block
* fetching DAG as CAR
* ability to [pass IPLD selector](https://github.com/ipfs/go-ipfs/issues/8769) to fetch only a subset of DAG
* ability to [test if gateway has requested data in cache (only-if-cached)](https://github.com/ipfs/go-ipfs/issues/8783)
* IMPORTANT CAVEAT: every gateway should support "trustless mode"

* Specification work
* wip gw spec is part of https://github.com/ipfs/specs/pull/283
* markdown preview [TRUSTLESS_GATEWAY.md](https://github.com/ipfs/specs/blob/feat/gateway-specs/http-gateways/TRUSTLESS_GATEWAY.md)

## TODO

* libp2p transport - how to find all these gateways
* works like alt-service
* or dns addr