Versia Federation Protocol
The Versia Protocol is a communication medium for federated applications, using HTTP and plain JSON. It is heavily inspired by ActivityPub. Messages between instances are signed. The core protocol covers users, subscriptions and how instances exchange entities, and anything beyond it, posts included, is a namespaced extension.
Audience and Scope
This specification is for people implementing a Versia server or library.
It covers what instances exchange with each other: entities, signatures, HTTP routes and extensions, plus Versia Links for opening addresses. It does not cover client APIs, storage, account management or moderation policy.
Reading Order
- Entities, JSON and Signatures, which everything else builds on.
- Federation, for how instances exchange entities.
- The core entity pages, starting with User and Subscribe.
- Validation, for what to check on everything you receive.
- Extensions, as you need them. Most others build on Social, which defines posts.
Two guides walk through signing requests and implementing a receiver. The reasoning behind the design is in Principles, and terms are defined in the Glossary. If you know ActivityPub or Matrix, Other Protocols maps their concepts to Versia’s.
Vocabulary
The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY in this specification are to be interpreted as described in BCP 14 (RFC 2119, RFC 8174) when, and only when, they appear in bold capitals, as shown here. In any other form, these words have their everyday meaning and set no requirement.
An Instance conforms to this specification if it meets every MUST and MUST NOT of the core protocol, and of each extension it lists in compatibility.extensions. Extensions are optional.
Domains, names and timestamps in samples are fictional. In a sample, // ... stands for fields left out, and requests leave out signature headers unless the sample is about them.