mirror of
https://github.com/versia-pub/docs.git
synced 2026-03-13 02:49:16 +01:00
docs: 📝 Add docs about federation
This commit is contained in:
Jesse Wierzbinski
parent
0856fd4fd9
commit
d1fd5c585c
14 changed files with 189 additions and 40 deletions
78
app/federation/http/page.mdx
Normal file
78
app/federation/http/page.mdx
Normal file
|
|
@ -0,0 +1,78 @@
|
|||
export const metadata = {
|
||||
title: 'HTTP',
|
||||
description:
|
||||
'How Lysand uses the HTTP protocol for all communications between instances.',
|
||||
}
|
||||
|
||||
# HTTP
|
||||
|
||||
Lysand uses the HTTP protocol for all communications between instances. HTTP requests must conform to certain standards to ensure compatibility between different implementations, as well as to ensure the security and integrity of the data being exchanged.
|
||||
|
||||
## Communication
|
||||
|
||||
ALL kinds of HTTP requests/responses between instances **MUST** include a [Signature](/signatures), signed with either the relevant [User](/entities/users)'s private key or the [Server Actor](/entities/server-actor)'s private key.
|
||||
|
||||
## Requests
|
||||
|
||||
<Row>
|
||||
<Col>
|
||||
<Properties>
|
||||
<Property name="Accept" type="string" required={true}>
|
||||
Must include `application/json`.
|
||||
</Property>
|
||||
<Property name="Content-Type" type="string" required={true}>
|
||||
Must include `application/json; charset=utf-8`, if the request has a body.
|
||||
</Property>
|
||||
<Property name="Signature" type="string" required={false} typeLink="/signatures">
|
||||
Request signature, if the request is signed.
|
||||
</Property>
|
||||
<Property name="Date" type="ISO8601" required={true}>
|
||||
Date and time of the request.
|
||||
</Property>
|
||||
<Property name="User-Agent" type="string" required={false}>
|
||||
A string identifying the software making the request.
|
||||
</Property>
|
||||
</Properties>
|
||||
</Col>
|
||||
<Col sticky>
|
||||
```http {{ 'title': 'Example Request' }}
|
||||
POST /users/1/inbox HTTP/1.1
|
||||
Accept: application/json
|
||||
Signature: keyId="https://example.com/users/1",algorithm="ed25519",headers="(request-target) host date digest",signature="..."
|
||||
Date: Thu, 01 Jan 1970 00:00:00 GMT
|
||||
User-Agent: CoolServer/1.0 (https://coolserver.com)
|
||||
```
|
||||
</Col>
|
||||
</Row>
|
||||
|
||||
## Responses
|
||||
|
||||
<Row>
|
||||
<Col>
|
||||
<Properties>
|
||||
<Property name="Content-Type" type="string" required={true}>
|
||||
Must include `application/json; charset=utf-8`.
|
||||
</Property>
|
||||
<Property name="Signature" type="string" required={false} typeLink="/signatures">
|
||||
Response signature, if the response is signed.
|
||||
</Property>
|
||||
<Property name="Date" type="ISO8601" required={true}>
|
||||
Date and time of the response.
|
||||
</Property>
|
||||
<Property name="Cache-Control" type="string" required={false}>
|
||||
Must include `no-store` on entities that can be edited directly without a `Patch`, such as `Users`.
|
||||
|
||||
**SHOULD** include a large `max-age` on entities that are not expected to change frequently, such as `Notes`, or CDN resources.
|
||||
</Property>
|
||||
</Properties>
|
||||
</Col>
|
||||
<Col sticky>
|
||||
```http {{ 'title': 'Example Response' }}
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: application/json; charset=utf-8
|
||||
Date: Thu, 01 Jan 1970 00:00:00 GMT
|
||||
Signature: keyId="https://example.com/users/1",algorithm="ed25519",headers="(request-target) host date digest",signature="..."
|
||||
Cache-Control: no-store
|
||||
```
|
||||
</Col>
|
||||
</Row>
|
||||
18
app/federation/page.mdx
Normal file
18
app/federation/page.mdx
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
import { Guides, Guide } from '@/components/Guides';
|
||||
|
||||
export const metadata = {
|
||||
title: 'Federation',
|
||||
description:
|
||||
'Description of federation behavior in Lysand.',
|
||||
}
|
||||
|
||||
# Federation
|
||||
|
||||
Being a federation protocol, Lysand defines a set of rules for exchanging data between instances. This document outlines the behavior of instances in a Lysand federated network. {{ className: 'lead' }}
|
||||
|
||||
Federation is built on the [HyperText Transfer Protocol (HTTP)](https://tools.ietf.org/html/rfc7230) and the [JavaScript Object Notation (JSON)](https://tools.ietf.org/html/rfc7159) data format. Instances communicate with each other by sending and receiving JSON payloads over HTTP.
|
||||
|
||||
<Guides>
|
||||
<Guide name="HTTP Guidelines" href="/federation/http" description="Guidelines for HTTP communication in Lysand." />
|
||||
<Guide name="Validation" href="/federation/validation" description="Validation rules for Lysand implementations." />
|
||||
</Guides>
|
||||
31
app/federation/validation/page.mdx
Normal file
31
app/federation/validation/page.mdx
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
export const metadata = {
|
||||
title: 'Validation',
|
||||
description:
|
||||
'Validation rules for Lysand implementations.',
|
||||
}
|
||||
|
||||
# Validation
|
||||
|
||||
Implementations **MUST** strictly validate all incoming data to ensure that it is well-formed and adheres to the Lysand Protocol. If a request is invalid, the server **MUST** return a `400 Bad Request` HTTP status code.
|
||||
|
||||
<Note>
|
||||
Remember that while *your* implementation may disallow or restrict some user input, other implementations may not. You **should not** apply those restrictions to data coming from other instances.
|
||||
|
||||
For example, if your implementation disallows using HTML in posts, you should not strip HTML from posts coming from other instances. You *may* choose to display them differently, but you should not modify the data itself.
|
||||
</Note>
|
||||
|
||||
Things that should be validated include, but are not limited to:
|
||||
|
||||
- The presence of **all required fields**.
|
||||
- The **format** of all fields (integers should not be strings, dates should be in ISO 8601 format, etc.).
|
||||
- The presence of **all required headers**.
|
||||
- The presence of a **valid signature**.
|
||||
- The **length** of all fields (for example, the `username` field on a `User` entity should be at least 1 character long).
|
||||
- Do not set arbitrary limits on the length of fields that other instances may send you. For example, a `bio` field should not be limited to 160 characters, even if your own implementation has such a limit.
|
||||
- If you do set limits, they should be reasonable and well-documented.
|
||||
- The **type**, **precision** and **scale** of all numeric fields.
|
||||
- For example, a `size` field on a `ContentFormat` structure should be a positive integer, not a negative number or a floating-point number.
|
||||
- The **validity** of all URLs and URIs (run them through your favorite URL parser).
|
||||
- The **time** of all dates and times (people should not be born in the future, or in the year 0).
|
||||
|
||||
It is your implementation's duty to reject data from other instances that does not adhere to the strict spec. **This is crucial to ensure the integrity of your instance and the network as a whole**. Allowing data that is technically valid but semantically incorrect can lead to the degradation of the entire Lysand ecosystem.
|
||||
Loading…
Add table
Add a link
Reference in a new issue