Protocol Architecture and Schema Definitions
Palyra’s protocol is versioned and modularized into functional domains. The schemas are located in theschemas/proto/palyra/v1/ directory.
Core Schema Modules
| Module | Purpose | Key Services / Messages |
|---|---|---|
common.proto | Fundamental primitives used across all other schemas. | CanonicalId (ULID), MessageEnvelope, JournalEvent, ToolProposal. |
gateway.proto | The primary interface for the palyrad daemon. | GatewayService, ApprovalsService, VaultService, CanvasService. |
browser.proto | Interface for the palyra-browserd automation service. | BrowserService, SessionBudget, RelayAction. |
auth.proto | Management of credentials and authentication profiles. | AuthServiceClient, OAuthCredential, AuthHealthSummary. |
Data Flow and Service Mapping
The following diagram illustrates how the.proto definitions map to the runtime components and the generated code entities.
Protocol Entity Mapping
Sources: schemas/proto/palyra/v1/common.proto#1-11 | schemas/proto/palyra/v1/gateway.proto#1-29 | schemas/proto/palyra/v1/browser.proto#1-37
Multi-Language Stubs
To support the polyglot nature of the Palyra ecosystem (Rust daemon, Kotlin Android, Swift iOS/macOS), the project generates static stubs. These stubs provide a native API for interacting with gRPC services and serializing/deserializing protocol messages.Generated Stub Locations
- Rust:
schemas/generated/rust/protocol_stubs.rsschemas/generated/rust/protocol_stubs.rs#1-5 - Kotlin:
schemas/generated/kotlin/ProtocolStubs.ktschemas/generated/kotlin/ProtocolStubs.kt#1-4 - Swift:
schemas/generated/swift/ProtocolStubs.swiftschemas/generated/swift/ProtocolStubs.swift#1-3
Service Implementation Example: BrowserService
TheBrowserService defined in browser.proto is the primary interface for the palyra-browserd crate.
Browser Service Implementation Flow
Sources: schemas/proto/palyra/v1/browser.proto#7-37 | crates/palyra-browserd/Cargo.toml#28-29 | schemas/generated/rust/protocol_stubs.rs#61-171
Protocol Validation and CI Pipeline
Palyra maintains strict protocol coherence through a validation pipeline executed during CI. This ensures that any change to the.proto files is backward compatible and that generated stubs are always in sync with the source schemas.
Validation Scripts
The validation logic is split into schema verification and stub compilation checks:- Schema Validation:
scripts/protocol/validate-proto.ps1usesprotocto verify that the.protofiles are syntactically correct and can be compiled into a descriptor set. scripts/protocol/validate-proto.ps1#58-66 - Coherence Check:
scripts/protocol/check-generated-stubs.ps1runs the generator and checks for git diffs in theschemas/generateddirectory. If a developer modifies a.protofile but forgets to update the stubs, the CI will fail. scripts/protocol/check-generated-stubs.ps1#14-21 - Language-Specific Compilation:
- Rust:
scripts/protocol/validate-rust-stubs.ps1attempts to compile the generated Rust file usingrustcto ensure no syntax errors were introduced by the generator. scripts/protocol/validate-rust-stubs.ps1#25-29 - Swift:
scripts/protocol/validate-swift-stubs.shusesswiftcto validate the Swift stubs. scripts/protocol/validate-swift-stubs.sh#20-21 - Kotlin:
scripts/protocol/validate-kotlin-stubs.ps1performs similar checks for the JVM stubs.
- Rust:
Rust Build Integration
For the Rust crates specifically, the protocol compilation is often integrated into thebuild.rs script. For example, palyra-browserd uses tonic-prost-build to compile its specific requirements at build time, ensuring the local crate is always using the latest definitions from schemas/proto.
Sources: crates/palyra-browserd/build.rs#14-17 | crates/palyra-browserd/Cargo.toml#34-37
Key Data Structures
Canonical Identifiers (ULID)
Palyra uses ULIDs (Universally Unique Lexicographically Sortable Identifiers) for all primary keys. In the protocol, these are represented by theCanonicalId message.
- File:
schemas/proto/palyra/v1/common.proto - Definition:
message CanonicalId { string ulid = 1; }schemas/proto/palyra/v1/common.proto#6-11
RunStream and Event Journaling
The core of the agent interaction is theRunStream. It is a bidirectional gRPC stream where the client sends a RunStreamRequest (containing user input or tool approvals) and the server responds with a stream of RunStreamEvent messages.
- Service:
GatewayService::RunStreamschemas/proto/palyra/v1/gateway.proto#9-10 - Event Types:
ModelToken,ToolProposal,ToolResult,StreamStatus. schemas/proto/palyra/v1/common.proto#300-307