> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tape.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Objects

The object layer is what lets you think in files and folders (and point standard S3 tooling at Tapedrive) while the storage underneath stays the append-only tape and track model.

The object catalog is an index rebuilt from chain history, the same replay that nodes and gateways use to build their own state. Nothing maintains it by hand, and there is no separate database that could drift out of sync with the chain ([tracks](/protocol/architecture/tracks), [how replay works](/protocol/architecture/overview)).

## An object is a named track

A write may carry a plaintext name and a content type. Carrying a name is what makes the resulting track an object: named tracks appear in listings, and nameless tracks (stream segments, internal blobs) never do.

Only the *hash* of the name is committed on-chain. The plaintext name travels in the write and lives in the replay metadata.

## Buckets

A bucket is a tape. Creating a bucket means reserving a tape, the bucket's contents are the tape's named tracks, and the bucket's lifetime and capacity are the tape's. Reservation, permissionless extension, and expiry all work exactly as the [tapes page](/protocol/architecture/tapes) describes.

## Names

The namespace is flat. Object names are yours to choose, unique within their bucket, and they may look like nested paths, but there are no directories: a name that looks like a folder can coexist with names that appear to live inside it.

Directory-style browsing is a convention over sorted names (prefix and delimiter listing), the same convention S3 tooling expects. The [CLI](/tools/cli) follows it when uploading or downloading folder trees:

```text Local directory theme={null}
photos/
├── 2025/beach.jpg
└── 2025/dunes.jpg
```

```text Object names after upload theme={null}
photos/2025/beach.jpg
photos/2025/dunes.jpg
```

<Note>
  Stick to this canonical layout if you upload trees by hand. Names that deviate from it break recursive downloads with standard tooling.
</Note>

A name can be up to 1024 bytes, and an empty name is rejected. Beyond length the protocol imposes nothing: any byte is allowed, and a separator like `/` is just another byte with no special meaning on-chain. The [S3 gateway](/tools/s3-gateway/uploads) is slightly stricter about the keys it accepts on the way in.

## What the catalog knows

Each object carries the metadata S3 users expect: an ETag (the track's on-chain commitment), a content type, a size, and a last-modified time taken from the block that wrote it.

Listings are name-ordered and served from a sorted index. A listing page is one range scan, not a lookup per object, which is what makes directory-style browsing over millions of small objects practical.

## Semantics

* **put / get / head / delete / list**: the full set of object operations, available through the [SDKs](/sdks/objects) and the [S3 gateway](/tools/s3-gateway).
* **Replace is last-write-wins**: objects are never updated in place. Writing again under the same name creates a new track, and the catalog resolves to the latest write.
* **Deletes are real**: an on-chain operation with a Merkle proof against the tape's commitment, not a soft-delete flag. Deleted capacity returns to the tape.
* **Objects inherit their tape's lifetime**: when the tape expires, its objects go with it. Permissionless [extension](/protocol/architecture/tapes) is the escape hatch.

## Objects and the S3 gateway

This page covers what objects *are*. The S3-compatible HTTP API (SigV4 auth, multipart uploads, the verb-by-verb compatibility table) lives in the [S3 gateway docs](/tools/s3-gateway). If you're using an SDK, the same object operations are first-class calls: no HTTP gateway required.