Skip to content

IPFS Gateway

All desktop and server peers host an IPFS gateway. A gateway is useful for light-clients which are unable to directly traverse the network, and/or want to request data from where they know it's stored.

For the most part, the gateway functions exactly like an IPFS gateway:|ipns/<path>

This is an unencrypted file within a thread shared over a peer gateway.


Thread files are encrypted by default. Learn how to write schemas that generate unencrypted files here.

Threads store files in structured DAG nodes. Web applications or light-clients will often want to use a gateway to navigate these thread file "directories".

You can explore a file DAG node by referencing its target hash:<target>
  • target: Top-level hash of a file DAG node, referenced by a thread update block.

Here is a DAG node served from one of Textile's federated gateways:

If your thread files are encrypted (the default), the meta and content data won't be viewable over a normal IPFS gateway. See next.

Decrypt thread files

Gateways are primarily useful for sharing unencrypted data or in cases where the client can efficiently decrypt data locally. However, in many cases, it may be acceptable to let a gateway decrypt a file before serving it to a client.

We can ask this cafe's gateway to decrypt an image by appending the key as a query parameter:<path>?key=<key>
  • path: A path in a file DAG node to either a meta or content link.
  • key: An AES encryption key for the data at path. See files for more about keys.

This is a dynamically decrypted image. Gateways will attempt to decrypt data with a key passed as a query parameter.