MSC: Federation endpoint for retrieving current extremities
Travis Ralston
2 months ago
parent
ea0aef0aa3
commit
fea82572d0
@ -0,0 +1,141 @@
|
|||||||
|
# MSC4370: Federation endpoint for retrieving current extremities
|
||||||
|
|
||||||
|
[MSC4284: Policy Servers](https://github.com/matrix-org/matrix-spec-proposals/pull/4284) introduces
|
||||||
|
an idea for an extremely lightweight server implementation to be developed to reduce the amount of
|
||||||
|
spam which ends up persisted in a room's DAG. In these server implementations, knowing the "current"
|
||||||
|
state of the room can be important for factoring into deciding whether an event is spammy.
|
||||||
|
|
||||||
|
"Current state" is not a concept which exists over federation, however: servers are expected to calculate
|
||||||
|
and heal their copy of the DAG to resolve a definition of "current state" for the room. A policy server
|
||||||
|
might not be persisting or tracking the DAG for a room though, especially because it typically only
|
||||||
|
concerns itself with impact to *current* users in the room at the time the policy server is asked to
|
||||||
|
scan an event.
|
||||||
|
|
||||||
|
To avoid the burden of persisting (and calculating, healing, resolving, etc) the room DAG, policy
|
||||||
|
servers have two options:
|
||||||
|
|
||||||
|
1. Attach themselves to a full homeserver implementation via the Client-Server API, calling endpoints
|
||||||
|
like [`GET /state`](https://spec.matrix.org/v1.16/client-server-api/#get_matrixclientv3roomsroomidstate).
|
||||||
|
2. Wait for a "trusted" server to ask an event to be scanned, then call [`GET /state/:roomId`](https://spec.matrix.org/v1.16/server-server-api/#get_matrixfederationv1stateroomid)
|
||||||
|
against that server using the just-scanned event ID as a reference (after waiting a little bit so
|
||||||
|
the remote server can persist its now-approved event).
|
||||||
|
|
||||||
|
The first option is fiddly for policy servers which operate at the Federation layer natively, like
|
||||||
|
the Foundation's own policyserv implementation, because managing a bot account for this one information
|
||||||
|
source can be a lot of overhead.
|
||||||
|
|
||||||
|
The second option relies on the policy server receiving an event from a server it trusts before it
|
||||||
|
can "learn" the state of the room. If the room has a lot of traffic from other servers, its view of
|
||||||
|
"current state" may drift significantly and produce inaccurate spam determinations. This is the approach
|
||||||
|
policyserv currently uses.
|
||||||
|
|
||||||
|
This MSC introduces a new endpoint that (primarily) policy servers can use to retrieve the *current*
|
||||||
|
extremities a given server has so it may then retrieve the current state for the room. Policy servers
|
||||||
|
which require historical context of room state (or the DAG in general) should behave like a normal
|
||||||
|
homeserver and resolve the DAG to that point in time - this MSC will not be overly useful to them.
|
||||||
|
|
||||||
|
By allowing a server to retrieve the current extremities, that server can request (and cache) current
|
||||||
|
state whenever it feels it needs to rather than waiting for a remote server to become active. This
|
||||||
|
could be on a timer, after a certain number of events have been scanned in the room, after specific
|
||||||
|
event types are seen, or a combination of all 3 - when to call the new endpoint is left as an implementation
|
||||||
|
detail.
|
||||||
|
|
||||||
|
This MSC expects that the current extremities for a room are highly cached or easily discovered by
|
||||||
|
a given server implementation - it's the exact same information it would populate in `prev_events`
|
||||||
|
if it were to send an event at that time.
|
||||||
|
|
||||||
|
Though not primary drivers for this proposal, this MSC's new endpoint also enables two bonus features:
|
||||||
|
|
||||||
|
1. A server which has lost its copy of the DAG, but has a room ID and server name, can call the new
|
||||||
|
endpoint to get current extremities and work backwards from there to rebuild the DAG. This doesn't
|
||||||
|
fix a scenario where the server has a total loss of room information, but a step towards recovery
|
||||||
|
is always better than none. A server may use this feature after data loss if a user happens to have
|
||||||
|
a cache of their room list still, for example.
|
||||||
|
|
||||||
|
Other MSCs in this space include:
|
||||||
|
* [MSC2316: Federation queries to aid with database recovery](https://github.com/matrix-org/matrix-spec-proposals/pull/2316)
|
||||||
|
* [MSC2314: A method to backfill room state](https://github.com/matrix-org/matrix-spec-proposals/pull/2314)
|
||||||
|
(**MSC2314 is a strong alternative to this MSC.**)
|
||||||
|
|
||||||
|
2. If a lightweight server were to want to send an event, such as a redaction or a ban, it can use
|
||||||
|
this MSC's new endpoint to get accurate-enough `prev_events` for its event, then inspect current
|
||||||
|
state to populate `auth_events` and send the event to all other servers in the room.
|
||||||
|
|
||||||
|
Currently policy servers manage a bot account to accomplish this task - see above regarding how
|
||||||
|
fiddly that can be. Eliminating the need to manage a bot account is a desirable feature for the
|
||||||
|
Foundation's policyserv implementation.
|
||||||
|
|
||||||
|
## Proposal
|
||||||
|
|
||||||
|
A new endpoint is added to the [Server-Server API](https://spec.matrix.org/v1.16/server-server-api/)
|
||||||
|
to retreive the current extremities (as event IDs) the server has in the given room. The endpoint
|
||||||
|
requires normal authentication for federation endpoints and MAY be rate limited. "Current" is at the
|
||||||
|
time of the request and has no guarantee of being accurate after the request is completed.
|
||||||
|
|
||||||
|
Servers should note that this endpoint returns the same information which would be supplied in the
|
||||||
|
`prev_events` for an event, if they were to send one.
|
||||||
|
|
||||||
|
Request shape:
|
||||||
|
|
||||||
|
```
|
||||||
|
GET /_matrix/federation/v1/extremities/{roomId}
|
||||||
|
Authorization: X-Matrix ...
|
||||||
|
```
|
||||||
|
|
||||||
|
(there are no query parameters or request body)
|
||||||
|
|
||||||
|
Response shape:
|
||||||
|
|
||||||
|
```
|
||||||
|
Content-Type: application/json
|
||||||
|
{
|
||||||
|
"prev_events": ["$event1", "$event2"]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
The response is contained in an object for future expansion. `prev_events` is required, and MUST have
|
||||||
|
at least one event ID entry in its array.
|
||||||
|
|
||||||
|
The following errors may be returned:
|
||||||
|
|
||||||
|
* 403 / `M_FORBIDDEN` - The requesting server is not in the room, or is excluded from the room via
|
||||||
|
`m.room.server_acl`.
|
||||||
|
* 404 / `M_NOT_FOUND` - The server is not aware of the room.
|
||||||
|
|
||||||
|
Servers SHOULD NOT attempt to fully resolve the DAG before returning a response - the calling server
|
||||||
|
is expected to handle the extremities as needed. For minimal/lightweight policy server implementations,
|
||||||
|
this may mean requesting state at each event and merging the results for a good enough representation
|
||||||
|
of current state - specific handling is left as an implementation detail.
|
||||||
|
|
||||||
|
## Potential issues
|
||||||
|
|
||||||
|
Lightweight server implementations may find it difficult to handle responses where `prev_events` has
|
||||||
|
more than a single entry. They could attempt to run state resolution over the information they learn,
|
||||||
|
or they could do a "simple" merge to get to somewhere close enough depending on their use case. They
|
||||||
|
may also decide to just wait a little bit and hope that the remote server self-resolves the DAG or
|
||||||
|
try another server.
|
||||||
|
|
||||||
|
## Alternatives
|
||||||
|
|
||||||
|
The major alternatives are discussed in the introduction for this proposal.
|
||||||
|
|
||||||
|
## Security considerations
|
||||||
|
|
||||||
|
**Author's note**: Specifics on how to exploit Matrix or this MSC are intentionally omitted from this
|
||||||
|
proposal. Refer to the [Security Disclosure Policy](https://matrix.org/security-disclosure-policy/)
|
||||||
|
to discuss such concerns and details.
|
||||||
|
|
||||||
|
Spammers can already use a few different tools to flood a room and this MSC makes it easier to do so.
|
||||||
|
This MSC does not have mitigation for such spam and instead expects that other aspects of Matrix will
|
||||||
|
take care of it. Features such as rate limits, policy servers, moderation tooling generally, and
|
||||||
|
server-side (implementation-specific) DAG/room simplification may be of interest to server developers
|
||||||
|
and communities on Matrix.
|
||||||
|
|
||||||
|
## Unstable prefix
|
||||||
|
|
||||||
|
While this proposal is not considered stable, implementations should use
|
||||||
|
`/_matrix/federation/unstable/org.matrix.msc4370/extremities/{roomId}` in place of the stable endpoint.
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
|
||||||
|
This MSC has no direct dependencies, but is primarily intended to be useful to [MSC4284: Policy Servers](https://github.com/matrix-org/matrix-spec-proposals/pull/4284).
|
||||||
Loading…
Reference in New Issue