# Method ID Reference

The v2 RPC protocol dispatches requests by a `u16` method ID encoded in the first two bytes of every request frame. This page is the authoritative reference for all 44 method IDs and their corresponding Protobuf message types.

Method IDs are defined in `crates/quicprochat-proto/src/lib.rs` (the `method_ids` module). Proto definitions live in `proto/qpc/v1/`.

---

## Auth (100-103)

OPAQUE asymmetric password-authenticated key exchange. Registration is a two-round trip (start + finish); login is a two-round trip (start + finish). See [Auth Schema](auth-schema.md) for proto definitions and [Authentication Service](../internals/authentication-service.md) for flow diagrams.

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 100 | `OPAQUE_REGISTER_START` | `OpaqueRegisterStartRequest` | `OpaqueRegisterStartResponse` |
| 101 | `OPAQUE_REGISTER_FINISH` | `OpaqueRegisterFinishRequest` | `OpaqueRegisterFinishResponse` |
| 102 | `OPAQUE_LOGIN_START` | `OpaqueLoginStartRequest` | `OpaqueLoginStartResponse` |
| 103 | `OPAQUE_LOGIN_FINISH` | `OpaqueLoginFinishRequest` | `OpaqueLoginFinishResponse` |

---

## Delivery (200-205)

Store-and-forward message relay. The server is MLS-unaware: payloads are opaque byte strings routed by recipient key and channel ID. See [Delivery Schema](delivery-schema.md) for proto definitions.

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 200 | `ENQUEUE` | `EnqueueRequest` | `EnqueueResponse` |
| 201 | `FETCH` | `FetchRequest` | `FetchResponse` |
| 202 | `FETCH_WAIT` | `FetchWaitRequest` | `FetchWaitResponse` |
| 203 | `PEEK` | `PeekRequest` | `PeekResponse` |
| 204 | `ACK` | `AckRequest` | `AckResponse` |
| 205 | `BATCH_ENQUEUE` | `BatchEnqueueRequest` | `BatchEnqueueResponse` |

---

## Keys (300-304)

MLS KeyPackage and hybrid post-quantum key management. See [Delivery Schema](delivery-schema.md) for proto definitions (keys are defined in `keys.proto`).

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 300 | `UPLOAD_KEY_PACKAGE` | `UploadKeyPackageRequest` | `UploadKeyPackageResponse` |
| 301 | `FETCH_KEY_PACKAGE` | `FetchKeyPackageRequest` | `FetchKeyPackageResponse` |
| 302 | `UPLOAD_HYBRID_KEY` | `UploadHybridKeyRequest` | `UploadHybridKeyResponse` |
| 303 | `FETCH_HYBRID_KEY` | `FetchHybridKeyRequest` | `FetchHybridKeyResponse` |
| 304 | `FETCH_HYBRID_KEYS` | `FetchHybridKeysRequest` | `FetchHybridKeysResponse` |

---

## Channel (400)

Direct-message channel creation. Returns a deterministic channel ID for a given peer key pair, with deduplication.

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 400 | `CREATE_CHANNEL` | `CreateChannelRequest` | `CreateChannelResponse` |

---

## Group Management (410-413)

MLS group operations: member removal, metadata updates, member listing, and key rotation.

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 410 | `REMOVE_MEMBER` | `RemoveMemberRequest` | `RemoveMemberResponse` |
| 411 | `UPDATE_GROUP_METADATA` | `UpdateGroupMetadataRequest` | `UpdateGroupMetadataResponse` |
| 412 | `LIST_GROUP_MEMBERS` | `ListGroupMembersRequest` | `ListGroupMembersResponse` |
| 413 | `ROTATE_KEYS` | `RotateKeysRequest` | `RotateKeysResponse` |

---

## Moderation (420-424)

Content moderation: encrypted reports, user bans, and audit lists. Admin-only methods require elevated session privileges.

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 420 | `REPORT_MESSAGE` | `ReportMessageRequest` | `ReportMessageResponse` |
| 421 | `BAN_USER` | `BanUserRequest` | `BanUserResponse` |
| 422 | `UNBAN_USER` | `UnbanUserRequest` | `UnbanUserResponse` |
| 423 | `LIST_REPORTS` | `ListReportsRequest` | `ListReportsResponse` |
| 424 | `LIST_BANNED` | `ListBannedRequest` | `ListBannedResponse` |

---

## User / Identity (500-501)

Forward and reverse user resolution. `ResolveUser` returns the identity key with a key-transparency inclusion proof.

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 500 | `RESOLVE_USER` | `ResolveUserRequest` | `ResolveUserResponse` |
| 501 | `RESOLVE_IDENTITY` | `ResolveIdentityRequest` | `ResolveIdentityResponse` |

---

## Key Transparency (510-520)

Key revocation and audit log access for the Merkle-based key transparency log.

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 510 | `REVOKE_KEY` | `RevokeKeyRequest` | `RevokeKeyResponse` |
| 511 | `CHECK_REVOCATION` | `CheckRevocationRequest` | `CheckRevocationResponse` |
| 520 | `AUDIT_KEY_TRANSPARENCY` | `AuditKeyTransparencyRequest` | `AuditKeyTransparencyResponse` |

---

## Blob Storage (600-601)

Content-addressed binary object storage with chunked upload and ranged download.

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 600 | `UPLOAD_BLOB` | `UploadBlobRequest` | `UploadBlobResponse` |
| 601 | `DOWNLOAD_BLOB` | `DownloadBlobRequest` | `DownloadBlobResponse` |

---

## Device Management (700-702, 710)

Multi-device registration, listing, and revocation. Method 710 registers a platform push notification token.

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 700 | `REGISTER_DEVICE` | `RegisterDeviceRequest` | `RegisterDeviceResponse` |
| 701 | `LIST_DEVICES` | `ListDevicesRequest` | `ListDevicesResponse` |
| 702 | `REVOKE_DEVICE` | `RevokeDeviceRequest` | `RevokeDeviceResponse` |
| 710 | `REGISTER_PUSH_TOKEN` | `RegisterPushTokenRequest` | `RegisterPushTokenResponse` |

---

## Recovery (750-752)

Encrypted account recovery bundle storage. The server stores an opaque blob indexed by `SHA-256(recovery_token)`; the plaintext is never visible to the server.

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 750 | `STORE_RECOVERY_BUNDLE` | `StoreRecoveryBundleRequest` | `StoreRecoveryBundleResponse` |
| 751 | `FETCH_RECOVERY_BUNDLE` | `FetchRecoveryBundleRequest` | `FetchRecoveryBundleResponse` |
| 752 | `DELETE_RECOVERY_BUNDLE` | `DeleteRecoveryBundleRequest` | `DeleteRecoveryBundleResponse` |

---

## P2P / Health (800-802)

iroh P2P node address exchange and server health probe.

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 800 | `PUBLISH_ENDPOINT` | `PublishEndpointRequest` | `PublishEndpointResponse` |
| 801 | `RESOLVE_ENDPOINT` | `ResolveEndpointRequest` | `ResolveEndpointResponse` |
| 802 | `HEALTH` | `HealthRequest` | `HealthResponse` |

---

## Federation (900-905)

Cross-server relay for messages, key packages, and user resolution. All federation methods include a `FederationAuth` struct carrying the origin server domain.

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 900 | `RELAY_ENQUEUE` | `RelayEnqueueRequest` | `RelayEnqueueResponse` |
| 901 | `RELAY_BATCH_ENQUEUE` | `RelayBatchEnqueueRequest` | `RelayBatchEnqueueResponse` |
| 902 | `PROXY_FETCH_KEY_PACKAGE` | `ProxyFetchKeyPackageRequest` | `ProxyFetchKeyPackageResponse` |
| 903 | `PROXY_FETCH_HYBRID_KEY` | `ProxyFetchHybridKeyRequest` | `ProxyFetchHybridKeyResponse` |
| 904 | `PROXY_RESOLVE_USER` | `ProxyResolveUserRequest` | `ProxyResolveUserResponse` |
| 905 | `FEDERATION_HEALTH` | `FederationHealthRequest` | `FederationHealthResponse` |

---

## Account (950)

| ID | Constant | Request | Response |
|----|----------|---------|---------|
| 950 | `DELETE_ACCOUNT` | `DeleteAccountRequest` | `DeleteAccountResponse` |

---

## Push Event Types (1000+)

Push events are sent by the server on QUIC uni-streams using the push frame format. They are not RPC methods (no `request_id`), but share the same event type namespace.

| ID | Constant | Payload |
|----|----------|---------|
| 1000 | `PUSH_NEW_MESSAGE` | `NewMessage` |
| 1001 | `PUSH_TYPING` | `TypingIndicator` |
| 1002 | `PUSH_PRESENCE` | `PresenceUpdate` |
| 1003 | `PUSH_MEMBERSHIP` | `GroupMembershipChange` |

Push payload messages are defined in `proto/qpc/v1/push.proto` and wrapped in a `PushEvent` oneof. See [RPC Reference](node-service-schema.md) for the full proto listing.

---

## Method ID assignment policy

Method IDs are stable across versions. Once assigned, an ID is never reused. New methods are assigned the next available ID in their logical category. Gaps in the numbering are reserved for future use within a category.

---

## Further reading

- [Wire Format Overview](overview.md) -- frame format and transport parameters
- [Auth Schema](auth-schema.md) -- OPAQUE proto definitions (IDs 100-103)
- [Delivery Schema](delivery-schema.md) -- delivery + keys proto definitions (IDs 200-304)
- [RPC Reference](node-service-schema.md) -- all proto definitions for all 14 files
