Group Resolution Protocol Specification
This is the normative GRP specification. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are interpreted as described in RFC 2119 and RFC 8174 .
Conformance: an implementation that passes the relevant v0.1 profile and publishes a signed report can claim that profile. See Conformance for the core, transport, and operator profiles.
Document set
| Section | Status |
|---|---|
| Versioning | Release Candidate |
| Transport | Release Candidate |
| Rooms | Release Candidate |
| Decisions | Release Candidate |
| Mechanisms | Release Candidate — eight mechanisms shipped; reserved identifiers refused |
| Mandates | Release Candidate |
| Receipts | Release Candidate |
| Discovery | Release Candidate |
| Errors | Release Candidate |
| Schema reference | Generated from canonical TypeScript types |
| Changelog | Tracks protocol-affecting changes |
Versioning at a glance
GRP v0.1 uses the protocol version string "0.1", declared by every conforming room in its .well-known/grp.json under protocol_version. Publishing the v0.1 tag freezes the protocol surface: after the tag, breaking changes ship only under a new version string, never silently under "0.1". See Versioning for the change rules.
Out of scope (spec-explicitly-not)
The following are deliberately out of scope for v0.1:
- Money flow. Payment authorization, escrow, disbursement. v1.0 will layer this on top of v0.1’s primitives.
- Federation. Cross-operator state sync, room migration. The protocol is structurally federation-friendly (signed receipts cross operators, mandates are operator-agnostic), but no normative federation layer ships in v0.1.
- Custom mechanisms. Mechanisms are an enum at v0.1. v0.2 will define a mechanism extension point.
Three trust gates (informative)
Three structural commitments anchor the trust model. They are informative here (not normative requirements on implementers); they define the protocol governance model.
- Standalone-verifiable receipts. Every binding decision emits a compact JWS. Anyone with the receipt and the room’s public key can verify it without calling the operator.
- Adversarial sim suite as release gate. Every protocol-affecting change runs against the sim suite. Failure blocks release.
- No platform-side privilege. The hosted server is one host among many possible. The spec and the conformance suite are open.
Reading order for implementers
- Versioning — how to pin and migrate.
- Transport — the wire format.
- Rooms — what you’re implementing.
- Decisions — the lifecycle you must honor.
- Mechanisms — the deterministic functions.
- Mandates — how authorized actors authenticate.
- Receipts — what you emit at decision close.
- Discovery — the well-known endpoints.
- Errors — the error envelope.