# OBJECTS Docs

> Build user friendly physical design apps with OBJECTS

## Data

The data layer defines schemas for content in the OBJECTS protocol. It specifies Asset, Project, and Reference, the core primitives that enable interoperability across applications.

### Design Goals

| Goal          | Description                                                 |
| ------------- | ----------------------------------------------------------- |
| Structured    | Defined schemas for protocol primitives                     |
| Minimal       | Only essential primitives defined                           |
| Opinionated   | Fixed fields ensure interoperability across applications    |
| Interoperable | Common vocabulary enables data exchange across applications |

### Data Types

The protocol defines five core types:

| Type                | Purpose                                   |
| ------------------- | ----------------------------------------- |
| Asset               | A versioned unit of content with metadata |
| SignedAsset         | Asset with cryptographic authorship proof |
| Project             | An organizational grouping of assets      |
| ProjectCatalogEntry | Encrypted project reference in user vault |
| Reference           | A typed link between assets               |

#### Asset

An Asset is the fundamental unit of content. It represents a versioned piece of content with associated metadata.

| Field         | Description                               |
| ------------- | ----------------------------------------- |
| id            | Unique identifier within project          |
| name          | Human-readable name                       |
| author\_id    | Identity ID of the asset creator          |
| content\_hash | BLAKE3 hash of content (32 bytes)         |
| content\_size | Size of content in bytes                  |
| format        | MIME type or format identifier (optional) |
| created\_at   | Creation timestamp                        |
| updated\_at   | Last update timestamp                     |

The `content_hash` serves as a version identifier. Same content produces the same hash. No separate version numbering is required.

#### SignedAsset

A SignedAsset wraps an Asset with a cryptographic signature, enabling authorship verification without registry lookups.

| Component | Description                                       |
| --------- | ------------------------------------------------- |
| asset     | Asset record with metadata                        |
| signature | Cryptographic signature from identity signer      |
| nonce     | 8-byte nonce for identity derivation verification |

Signatures enable offline verification of authorship. Verifiers check that the `author_id` matches the signature's public key without requiring registry access.

#### Project

A Project is an organizational grouping of assets. It maps 1:1 with a sync layer Replica.

| Field       | Description                                |
| ----------- | ------------------------------------------ |
| id          | Unique identifier (derived from ReplicaId) |
| name        | Human-readable name                        |
| description | Project description (optional)             |
| owner\_id   | Identity ID of the project owner           |
| created\_at | Creation timestamp                         |
| updated\_at | Last update timestamp                      |

This means:

* Creating a project creates a replica
* Sharing a project shares the doc ticket
* Project sync scope = replica sync scope
* Write access = replica write capability

### User Vault

A User Vault is a private replica containing an encrypted catalog of all projects owned by an identity. Vaults enable cross-application project discovery without centralized infrastructure.

#### Purpose

| Use Case              | Description                                |
| --------------------- | ------------------------------------------ |
| Project Discovery     | New apps discover user's existing projects |
| Cross-App Portability | Data follows users between applications    |
| Privacy-Preserving    | Projects not publicly enumerable           |
| Decentralized         | No central directory required              |

#### Vault Namespace Derivation

Vault replica namespace is derived from the identity's **signing key secret** using HKDF-SHA256. Only the identity owner (who has the signing key) can compute the vault namespace ID.

| Property  | Value                                    |
| --------- | ---------------------------------------- |
| Input     | Identity signing key secret (32 bytes)   |
| Algorithm | HKDF-SHA256                              |
| Output    | Vault namespace keypair + encryption key |
| Privacy   | Cannot be computed without signing key   |

This ensures project catalogs remain private by default. Applications cannot derive vault IDs. They must request vault access from the user. Users explicitly grant permission for each app to access their project catalog.

#### Catalog Structure

Vault entries use the key format `/catalog/{project_id}` and contain encrypted ProjectCatalogEntry records.

**ProjectCatalogEntry fields:**

| Field         | Description                               |
| ------------- | ----------------------------------------- |
| project\_id   | Unique project identifier                 |
| replica\_id   | NamespaceId of project replica (32 bytes) |
| project\_name | Human-readable name                       |
| created\_at   | Creation timestamp (Unix seconds)         |

**Storage format:**

```
Entry Key: /catalog/{project_id}
Entry Value: nonce (24 bytes) || XChaCha20-Poly1305(ProjectCatalogEntry)
```

Encryption uses XChaCha20-Poly1305 AEAD with the catalog encryption key derived alongside the vault namespace.

#### Access Control

| Access Type | Required                                          |
| ----------- | ------------------------------------------------- |
| Write       | Vault namespace secret (derived from signing key) |
| Read        | Vault namespace ID (derived from signing key)     |
| Decryption  | Catalog encryption key (derived from signing key) |

Only the identity owner can write to, read from, or decrypt vault contents. Applications request vault access. Users grant permission via signature, and their identity signer issues a read-only capability ticket.

The read-only vault ticket allows applications to discover which projects exist. Once projects are discovered, users can read and write to those projects based on the project's own access control. Users who own projects have write capability to those projects through the app.

#### Vault Lifecycle

**Creation:** Vault created automatically when user creates their first project.

**Updates:** Wallet updates vault when projects are created, renamed, or deleted.

**Synchronization:** Vaults sync via standard replica synchronization across user devices.

**Discovery:** Apps request vault access. User grants permission via signature. Identity signer issues read-only ticket. App syncs vault, requests decryption key, and discovers projects.

#### Reference

A Reference is a typed link between assets. References enable dependency graphs, assembly structures, and version chains without embedding data.

| Field                 | Description                           |
| --------------------- | ------------------------------------- |
| id                    | Unique identifier within project      |
| source\_asset\_id     | ID of the source asset                |
| target\_asset\_id     | ID of the target asset                |
| target\_content\_hash | Specific version of target (optional) |
| reference\_type       | Type of relationship                  |
| created\_at           | Creation timestamp                    |

##### Reference Types

| Type          | Description                                   |
| ------------- | --------------------------------------------- |
| CONTAINS      | Source contains target (assembly → part)      |
| DEPENDS\_ON   | Source depends on target                      |
| DERIVED\_FROM | Source is derived from target (version chain) |
| REFERENCES    | Generic reference                             |

##### Cross-Project References

References can point to assets in other projects for cross-project dependencies.

| Field                 | Description                |
| --------------------- | -------------------------- |
| source\_asset\_id     | Asset in current project   |
| target\_project\_id   | ID of external project     |
| target\_asset\_id     | Asset in target project    |
| target\_content\_hash | Optional: specific version |
| reference\_type       | Relationship type          |

Applications must handle cases where the target project isn't synced or the target asset isn't accessible. Cross-project references enable modular design across organizational boundaries.

### Storage

Data types are stored as sync layer entries with structured keys.

#### Key Format

```
/{type}/{id}
```

Examples:

```
/project                    → Project metadata
/assets/motor-mount         → Asset record
/assets/gear-assembly       → Asset record
/refs/assembly-to-part-1    → Reference record
```

#### Content Storage

Asset metadata and content are stored separately:

* **Entry**: Contains the Asset record (name, format, timestamps, content\_hash)
* **Blob**: Contains the actual file bytes, referenced by content\_hash

Nodes fetch the content blob separately via blob sync when needed.

### Operations

#### Create Project

Creates a new project and underlying replica. The creator gets write capability.

#### Create Asset

Adds an asset to a project:

1. Store content blob via blob sync
2. Create Asset record with content hash
3. Store Asset entry at `/assets/{id}`

Requires write capability for the project.

#### Update Asset

Updates an existing asset's content or metadata. Updates are last-write-wins based on timestamp. The sync layer preserves all author versions; applications resolve conflicts.

#### Create Reference

Creates a link between assets. Applications should verify that source and target assets exist.

### Versioning

#### Content Versioning

Asset versions are identified by content hash. To maintain version history, applications create `DERIVED_FROM` references:

```
Asset v3 (hash: 0xdef...)
  └── DERIVED_FROM → Asset v2 (hash: 0xabc...)
       └── DERIVED_FROM → Asset v1 (hash: 0x123...)
```

Applications traverse these references to build version chains.

#### Schema Versioning

The wire format uses Protocol Buffers, which provides schema evolution:

* New fields are added with new numbers
* Old fields are never removed
* Unknown fields are preserved

### Security

#### Authorization

Data operations inherit sync layer capabilities:

| Operation            | Required                       |
| -------------------- | ------------------------------ |
| Read assets          | Read capability (ReplicaId)    |
| Create/update assets | Write capability (private key) |
| Share project        | Ability to share doc ticket    |

#### Content Integrity

Asset content is verified by BLAKE3 hash. Nodes verify content matches `content_hash` before accepting.

#### Vault Security

Vault security is tied to identity signing key security.

| Threat              | Mitigation                           |
| ------------------- | ------------------------------------ |
| Vault enumeration   | Namespace derived from private key   |
| Catalog exposure    | XChaCha20-Poly1305 encryption        |
| Key compromise      | Same recovery as identity compromise |
| Unauthorized access | Apps cannot derive vault ID          |

Vault namespace secret has the same recovery requirements as the identity itself. Future multi-signer support will enable vault recovery through trusted devices.

#### Cross-Project References

References can point to assets in other projects. Applications must handle cases where the target project isn't synced or the target asset isn't accessible.


## Identity

The identity layer provides portable, user-owned identities for the OBJECTS protocol. Users can create an identity using passkeys, associate human-readable handles, and optionally link wallet addresses for payments.

### Design Goals

| Goal            | Description                                           |
| --------------- | ----------------------------------------------------- |
| User Ownership  | Users control their identity with no platform lock-in |
| Passkey-First   | Users can create identity without a wallet            |
| Wallet Optional | Users can link a wallet for payments                  |
| Portable        | Identity can be exported and verified independently   |
| Pseudonymous    | No PII required; handles are user-chosen aliases      |

### Identity Identifier

Each identity has a unique identifier derived from the user's signing key. Identifiers use the `obj_` prefix and are 24 characters total.

```
obj_7kd2zcx9f3m1qwerty
```

#### Derivation

The identifier is derived using SHA-256 with Base58 encoding:

```
identity_id = "obj_" + base58(truncate(sha256(signer_public_key || nonce), 15))
```

| Component           | Description                         |
| ------------------- | ----------------------------------- |
| signer\_public\_key | 33-byte compressed SEC1 public key  |
| nonce               | 8 bytes of cryptographic randomness |
| truncate(x, n)      | First n bytes of x                  |

A nonce is included in the derivation, allowing users to create multiple identities from the same key if needed.

### Handles

Handles are human-readable aliases displayed as `@username`.

| Constraint | Requirement                                                        |
| ---------- | ------------------------------------------------------------------ |
| Length     | 1-30 characters including periods                                  |
| Characters | Lowercase a-z, digits 0-9, underscore, period                      |
| Start/End  | Must not start with period or underscore; must not end with period |
| Uniqueness | Case-insensitive unique across registry                            |
| Reserved   | Cannot use reserved words (admin, root, system, etc.)              |

Handles can be changed. The old handle becomes available for others to claim.

### Signer Types

OBJECTS supports two types of cryptographic signers:

#### Passkey

Passkeys enable biometric authentication (Face ID, Touch ID, Windows Hello) without requiring users to manage wallets or keys.

* Device-native authentication
* Synced across devices via iCloud/Google/1Password
* No seed phrases to manage

#### Wallet

Wallets enable integration with existing wallet infrastructure.

* Connect an existing wallet
* Link wallet for payments and licensing
* Sign with familiar wallet UX

### Operations

#### Create Identity

Creates a new identity with a handle. The user signs a message proving ownership of their key.

#### Link Wallet

Links a wallet address to an existing passkey identity. This enables payment functionality while keeping the passkey as the primary authentication method. Both the identity signer and wallet must sign.

#### Change Handle

Changes the handle associated with an identity. The old handle becomes available for others to claim.

#### Sign Asset

Signs an asset (design file, CAD model, etc.) to prove ownership. The signature includes the asset's content hash and can be verified by anyone.

#### Authenticate

Authenticates to an application by signing a challenge. Applications generate a random challenge, the user signs it, and the application verifies the signature.

### Vault Discovery

User vaults enable private, cross-application project discovery without centralized infrastructure.

#### Vault Namespace

Each identity has a private vault namespace derived from the signing key. The vault namespace cannot be computed without the identity's secret key, ensuring project catalogs remain private by default.

| Property   | Description                                 |
| ---------- | ------------------------------------------- |
| Derivation | HKDF-SHA256 from signing key secret         |
| Privacy    | Only identity owner can compute namespace   |
| Access     | Apps request vault access from wallet       |
| Discovery  | Apps sync vault to discover user's projects |

#### Discovery Flow

Applications discover projects through the vault pattern:

1. User authenticates to app (signs challenge)
2. App requests vault access from wallet
3. Wallet derives namespace and returns read-only ticket
4. App syncs encrypted vault and requests decryption key
5. App discovers project IDs and syncs individual projects

The vault enables seamless cross-app data portability while preserving user privacy.

### Registry

The registry stores identities and provides resolution services. Identities can be looked up by ID, handle, public key, or linked wallet address.

### Security

#### Key Compromise

If a signer key is compromised, an attacker can act as that identity. Users should create a new identity if compromise is detected. Historical signatures remain valid but are attributed to the compromised identity.

#### Recovery (Future)

Version 0.2 will add recovery mechanisms including multiple passkeys across devices, linked wallet as recovery option, and social recovery via trusted contacts.

#### Privacy

Identity IDs are pseudonymous with no PII in the derivation. Handles are user-chosen and may or may not contain PII. Registry data and wallet addresses are public by design. Vault namespaces are derived privately from signing keys, preventing enumeration of user projects without explicit permission.


## Protocol

The OBJECTS protocol specification. These are the rules that clients implement to participate in the network.

### Specification

* **[Identity](/protocol/identity)** — User-owned identities, handles, and authentication
* **[Data](/protocol/data)** — Asset schemas, operations, versioning, and history
* **[Sync](/protocol/sync)** — Mechanisms for synchronizing state between peers
* **[Transport](/protocol/transport)** — How data moves between nodes


## Sync

The sync layer provides content-addressed data synchronization for the OBJECTS protocol. It handles blob transfer, metadata reconciliation, and sync discovery, enabling data to move seamlessly between devices and collaborators without central coordination.

### Design Goals

| Goal                 | Description                                      |
| -------------------- | ------------------------------------------------ |
| Content-Addressed    | All data identified by cryptographic hash        |
| Incremental          | Transfer only what's missing, verify as you go   |
| Offline-First        | Nodes operate independently, sync when connected |
| Transport-Agnostic   | Works over any OBJECTS transport connection      |
| Eventual Consistency | All nodes converge to the same state             |

### Sync Primitives

The protocol defines two complementary sync mechanisms:

| Mechanism     | Purpose                                    |
| ------------- | ------------------------------------------ |
| Blob Sync     | Transfer binary content by hash            |
| Metadata Sync | Reconcile structured entries between nodes |

Blob Sync handles raw data transfer with verification. Metadata Sync handles the index of what data exists and where it lives.

### Blob Sync

Blobs are opaque sequences of bytes identified by their BLAKE3 hash. When you request a blob, you specify the expected hash. The content is verified incrementally during transfer.

#### Content Addressing

```
hash = BLAKE3(content)
```

Same content always produces the same 32-byte hash. This enables deduplication and integrity verification without trusting the source.

#### Verified Streaming

Blob transfer uses BLAKE3 verified streaming with BAO (BLAKE3 Authenticated Output).

| Parameter                | Value              |
| ------------------------ | ------------------ |
| Chunk size               | 1024 bytes         |
| Chunk group size         | 16 KiB (16 chunks) |
| Verification granularity | Per chunk group    |

Content is verified incrementally as it arrives. Corrupted data is rejected immediately without waiting for the full transfer. Nodes can request byte ranges for partial or resumed transfers, making large file sync resilient to network interruptions.

#### Collections

A Collection is an ordered list of blobs treated as a unit. Use cases include:

* Multi-file transfers (e.g., CAD assembly with parts)
* Atomic updates (all-or-nothing sync)
* Chunked large files

### Metadata Sync

Metadata Sync reconciles structured entries between nodes using set reconciliation.

#### Entries

An Entry associates a key with a blob reference:

| Field     | Description                                           |
| --------- | ----------------------------------------------------- |
| key       | Application-defined key (path, ID, etc.)              |
| author    | Ed25519 public key of entry creator                   |
| hash      | BLAKE3 hash reference to blob content                 |
| size      | Size of referenced blob in bytes                      |
| timestamp | Unix timestamp in microseconds when entry was created |

Entries are signed by the author's private key. Multiple authors can write to the same key. Each author's entry is preserved independently.

#### Replicas

A Replica is a local collection of entries that syncs with peers. Each replica has a unique ID derived from a keypair:

| Capability | Grants                                       |
| ---------- | -------------------------------------------- |
| Write      | Create/update entries (requires private key) |
| Read       | Fetch and verify entries                     |
| Sync       | Participate in reconciliation                |

#### Set Reconciliation

Nodes sync entries efficiently using range-based set reconciliation:

1. Nodes exchange fingerprints of entry ranges
2. Differing ranges are recursively subdivided
3. Process continues until missing entries identified
4. Only missing entries are transferred

Transfer is proportional to differences, not total size. Syncing one new entry from a million-entry replica is fast.

### Sync Discovery

Sync Discovery enables nodes to find and initiate data synchronization.

#### Explicit Sync

Once connected via the transport layer, nodes request sync directly by specifying which replica or blob they want.

#### Tickets

A Ticket encodes everything needed to sync specific data. Tickets are designed for:

* Copy/paste sharing
* QR code encoding
* URL embedding

| Ticket Type        | Contains              | Grants                       |
| ------------------ | --------------------- | ---------------------------- |
| Blob ticket        | Hash + peer address   | Read access to specific blob |
| Doc ticket (read)  | Replica ID + peer     | Read access to all entries   |
| Doc ticket (write) | Replica secret + peer | Write access to replica      |

Write tickets must be treated as secrets. Sharing one grants full write access to the replica.

### Vault Discovery

User vaults enable private, decentralized project discovery. Unlike explicit tickets, vaults allow applications to discover all of a user's projects without centralized infrastructure.

#### Vault Access Pattern

Applications cannot derive vault namespace IDs themselves. They must request vault access from the user's wallet or keyring.

| Step                | Actor  | Action                                              |
| ------------------- | ------ | --------------------------------------------------- |
| 1. Authenticate     | User   | Signs challenge with identity signer                |
| 2. Request Access   | App    | Requests vault ticket from wallet                   |
| 3. Derive Namespace | Wallet | Derives namespace ID from signing key (HKDF-SHA256) |
| 4. Issue Ticket     | Wallet | Creates read-only DocTicket for vault               |
| 5. Sync Vault       | App    | Syncs vault replica using ticket                    |
| 6. Request Key      | App    | Requests decryption key from wallet                 |
| 7. Decrypt Catalog  | App    | Decrypts catalog entries to discover projects       |
| 8. Sync Projects    | App    | Syncs each discovered project replica               |

#### Privacy Properties

| Aspect         | Privacy Level                             |
| -------------- | ----------------------------------------- |
| Vault ID       | Private (requires signing key)            |
| Catalog keys   | Private (visible only after vault access) |
| Catalog values | Encrypted (XChaCha20-Poly1305)            |
| Project IDs    | Private (encrypted in catalog)            |

Without the identity signing key, vault namespace ID cannot be computed. This prevents enumeration of projects or correlation of vaults across identities.

#### Vault Availability

Vaults may be hosted by user devices, self-hosted nodes, foundation seed nodes, or third-party services. The protocol does not mandate hosting location. If vaults are unavailable, applications fall back to explicit project ticket sharing.

### Consistency Model

The protocol provides eventual consistency: if no new updates are made, all nodes will eventually converge to the same state.

#### Conflict Handling

When multiple authors write to the same key:

1. All entries are preserved (multi-value)
2. Entries are distinguishable by author
3. Applications implement resolution strategies
4. Protocol does not automatically discard entries

Applications can implement last-write-wins, author-priority, merge logic, or manual resolution. The protocol preserves all entries to enable any strategy.

### Security

#### Content Verification

All blob content is verified against its hash. Nodes reject content that doesn't match or entries with invalid signatures.

#### Capability Security

Write capability requires possession of the replica private key. Entries must be signed. Unsigned entries are never accepted.

#### Privacy

Content hashes reveal nothing about content. However, sync patterns are observable. Nodes can see who syncs what. Applications requiring confidentiality must encrypt at the data layer.


## Transport

The transport layer provides peer-to-peer connectivity for the OBJECTS protocol. It handles connection establishment, NAT traversal, and peer discovery using QUIC, a modern transport protocol built on UDP.

### Design Goals

| Goal                 | Description                                                    |
| -------------------- | -------------------------------------------------------------- |
| Mobile-friendly      | QUIC handles network transitions and intermittent connectivity |
| NAT traversal        | Relay-assisted holepunching for universal reachability         |
| Encrypted by default | All connections use TLS 1.3                                    |
| Single network       | All conforming nodes participate in one shared network         |

### Node Addressing

Each node has a unique identifier derived from an Ed25519 keypair.

#### NodeId

A 32-byte Ed25519 public key that uniquely identifies a node. NodeIds are encoded as z-base-32 for human readability.

#### NodeAddr

Contains everything needed to connect to a node:

* **node\_id** — The node's public key
* **relay\_url** — The node's preferred relay server (optional)
* **direct\_addresses** — Known direct IP addresses (optional)

A NodeAddr with only a `node_id` can be resolved via DNS lookup.

### Connection Model

Connections are established through a relay-assisted process:

1. Both nodes connect to a relay server
2. Node A requests connection to Node B
3. Relay coordinates NAT holepunching
4. Direct connection established if possible, otherwise relayed

All connections use QUIC with TLS 1.3 encryption. Protocol version is negotiated via ALPN during the handshake.

### Peer Discovery

Discovery allows nodes to find other participants in the network.

#### Bootstrap

New nodes connect to bootstrap nodes first. Bootstrap nodes are operated by the OBJECTS Foundation but have no special protocol privileges.

#### Gossip

After bootstrapping, nodes join a discovery topic to learn about additional peers. Nodes periodically announce their presence via signed messages, allowing the network to grow organically.

### Security

#### Authentication

All connections are authenticated via the QUIC handshake. A node cannot impersonate another node's public key.

#### Encryption

All traffic is encrypted end-to-end using TLS 1.3. Connection contents are not visible to relays or network observers.

#### Relay Trust

Relays assist with NAT traversal but cannot read message contents. They can observe connection metadata (which nodes are communicating, timing, volume) but not payload data.


## Introduction \[OBJECTS is an open protocol & network for developing physical design apps]

### Core Principles

* **Local-first**: Data is stored locally and synced peer-to-peer. Apps work offline by default with no central server dependency.
* **Mobile-friendly**: Built on QUIC for reliable connectivity across network transitions and intermittent connections.
* **User-owned**: One login, all your data. Switch apps instantly with a single account. Your projects follow you everywhere.
* **Privacy-first**: Users control who accesses their data. Apps require explicit permission to read or sync your projects.
* **Peer-to-peer**: Direct device-to-device communication. No intermediary required for data access or sync. (Initial nodes will be operated by OBJECTS Foundation)

### Key Features

* **Portable Identity**: Passkey-based identity that works across all apps built on the protocol.
* **Interoperable Data**: Shared data model allows apps to read and write the same design projects.
* **End-to-end Encrypted**: All data and communications encrypted by default. Apps can only access your data with your explicit permission.
* **Permissionless**: Build and ship apps without platform approval or API keys. Launch with instant access to users who already have accounts and data. Skip user acquisition from scratch.

### Use Cases

* **Collaborative Design**: Real-time multi-user editing with automatic conflict resolution.
* **Offline-first Apps**: Full functionality without connectivity, sync projects when available.
* **Cross-app Workflows**: Users move designs between apps without export/import friction.

### Explore

* **[Protocol](/protocol)** — Understand the architecture
* **[Network](/network)** — Connect to public services
* **[App](/app)** — Build your first app

### Community

Join the [OBJECTS group chat](https://popup.convos.org/v2?i=CoICCj8BvlZwfPJmGJ7SWjGWHg1-z2hw4SWQSoJUHu_vqdniVG9n-FkAULKGxMx7y_ptFfeo8uomGsZtVH-9FdwpTcsSIBdXr9yNAWiXrNMdpR9tCP-JAJWwEAJ7nl7K3spYJV0XGgp5SFJXb0poZWs4IgdPQkpFQ1RTKgAyhQFodHRwczovL2NvbnZvcy1hc3NldHMtY29udm9zLW90ci1wcm9kLTIwMjUwODI2MTY0MjA4NDA5ODAwMDAwMDE5LnMzLnVzLWVhc3QtMi5hbWF6b25hd3MuY29tL2Q3YTFm*YTE4LTM5MmEtNDMwYS1hNGEwLWY0ODUyNTA3ZGJmYy5qcGVnEkEuzQ9ibSJX53hppf9zPGU10FTNaWezxdt0UflTRgFDjiYZmXHFn9K8XqmR0nLn_I-C-aFtOCuDWkNNp15eQXVPAQ) to get support, share your projects, and contribute to the development of the protocol.


## Discovery

This section covers the mechanisms for finding peers and content on the OBJECTS network.

*Coming soon.*


## Network

Public services that power the OBJECTS network. Connect to these to register identities, discover peers, and sync data.

### Services

* **[Registry](/network/registry)** — Identity registration and lookup
* **[Indexing](/network/indexing)** — Content search and asset queries
* **[Relay](/network/relay)** — NAT traversal and peer connectivity
* **[Discovery](/network/discovery)** — Peer finding and network joining


## Index

This section covers the indexing infrastructure that enables content discovery and lookup across the network.

*Coming soon.*


## Registry

This section covers the registry and directory services used for registering and looking up identities across the OBJECTS network.

*Coming soon.*


## Relay

This section covers the relay infrastructure that forwards data between peers when direct connections aren't possible.

*Coming soon.*


## App \[Building applications on OBJECTS]

This section covers everything you need to know about building applications on the OBJECTS protocol.

### Why Build on OBJECTS

Launch apps faster by tapping into the OBJECTS network. Users already have accounts and data ready to go. Skip building authentication and user acquisition. Focus on your product instead.

### What to Expect

This documentation will guide you through:

* **SDK Usage**: How to integrate the OBJECTS SDK into your applications
* **Example Apps**: Reference implementations and starter templates
* **Best Practices**: Patterns and conventions for building robust OBJECTS apps
* **API Reference**: Detailed documentation of available methods and types

### Coming Soon

Content for this section is currently in development. Check back soon for guides on building your first OBJECTS application.