From 85b14d82fa25d982dbc0c325d594f0cf4f8f40ff Mon Sep 17 00:00:00 2001 From: silverpill Date: Thu, 9 Oct 2025 00:28:52 +0200 Subject: [PATCH] FEP-ae97: Delete media (#691) - Added "Discovery" section. - Described how media can be deleted. - Specified status codes for authentication and permission errors during media upload. - Specified status code for inbox / outbox permission error. - Changed recommended status codes for non-existent inboxes and outboxes. - Updated `discussionsTo` attribute. Reviewed-on: https://codeberg.org/fediverse/fep/pulls/691 Co-authored-by: silverpill Co-committed-by: silverpill --- fep/ae97/fep-ae97.md | 42 ++++++++++++++++++++++++++++++++++++++---- 1 file changed, 38 insertions(+), 4 deletions(-) diff --git a/fep/ae97/fep-ae97.md b/fep/ae97/fep-ae97.md index 616b3cf..c65d6c8 100644 --- a/fep/ae97/fep-ae97.md +++ b/fep/ae97/fep-ae97.md @@ -5,7 +5,7 @@ type: implementation status: DRAFT dateReceived: 2023-08-14 trackingIssue: https://codeberg.org/fediverse/fep/issues/148 -discussionsTo: https://socialhub.activitypub.rocks/t/fep-ae97-client-side-activity-signing/3502 +discussionsTo: https://codeberg.org/silverpill/feps --- # FEP-ae97: Client-side activity signing @@ -21,6 +21,20 @@ Existing Fediverse servers manage signing keys on behalf of their users. This pr The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119][RFC-2119]. +## Discovery + +A server that supports clients capable of managing signing keys MUST have a discovery endpoint at the path `/.well-known/apgateway`. + +When the server receives an HTTP GET request to this endpoint, it MUST respond with a JSON object containing information about itself. That object MAY be empty. + +Example: + +```json +{ + "uploadMedia": "https://gateway.example/.well-known/apgateway-media" +} +``` + ## Registering an actor Client creates portable actor objects according to [FEP-ef61] and stores them. When a portable actor is created, the client MUST create a key for signing requests (the main actor key) and add a `Multikey` representation of it to the `assertionMethod` array as described in [FEP-521a]. The identifier of that key MUST NOT be a [compatible identifier][CompatibleIdentifiers]. @@ -60,7 +74,9 @@ If activity contains a wrapped object (as in `Create` and `Update` activities), The server MUST deliver activities to their indended audiences without altering them. When signing HTTP requests, the server uses the RSA key generated during the registration. -If the actor of the submitted activity is not registered, the server MUST return a `403 Forbidden` status code. +If the owner of the outbox is not registered, the server MUST return a `404 Not Found` status code. + +If the actor of the submitted activity is different from the outbox owner, the server MUST return a `403 Forbidden` status code. ## Receiving activities @@ -68,9 +84,15 @@ Client receives activities by polling the actor's inbox. Requests to inbox endpoint MUST have an [HTTP signature][HttpSig] created using the main actor key (the one generated by the client, not a server-generated key). -If the owner of the inbox is not registered, the server MUST return a `403 Forbidden` status code. +If the signature is not valid, the server MUST return a `401 Unauthorized` status code. -## Uploading media +If the owner of the inbox is not registered, the server MUST return a `404 Not Found` status code. + +If the actor that generated the signature is different from the inbox owner, the server MUST return a `403 Forbidden` status code. + +## Media API + +### Upload media To upload a media file, the client sends an HTTP POST request to the gateway endpoint at the `/.well-known/apgateway-media` path. The body of the request MUST be the media in the form of binary data. The request MUST contain a `Content-Type` header and MUST be signed with the main key of the actor. @@ -87,10 +109,22 @@ Example: The server MUST serve the processed media file at a `/.well-known/apgateway-media/{hashlink}` path. +If the signature is not valid, the server MUST return a `401 Unauthorized` status code. If the signature is valid, but the actor is not registered, the server MUST return a `403 Forbidden` status code. + If the media type is not supported, the server MUST return a `400 Bad Request` status code. If the media is too large, the server MUST return a `413 Payload Too Large` status code. +### Delete media + +To delete a previously uploaded media file, the client sends an HTTP DELETE request to an endpoint at path `/.well-known/apgateway-media/{hashlink}`. The request MUST be signed with the main key of the actor. + +If the signature is valid and the actor owns the media file, the server MUST delete the file. + +If the signature is not valid, the server MUST return a `401 Unauthorized` status code. If the signature is valid, but the actor is not registered, the server MUST return a `403 Forbidden` status code. + +If the media file doesn't exist or not owned by the actor, the server MUST return a `404 Not Found` status code. + ## Security considerations If the server accepts portable objects with [compatible identifiers][CompatibleIdentifiers], it MUST ensure that all objects served by the gateway are valid and that registered actors are sufficiently isolated from each other. Specifically, the server MUST verify that actors and activities generated by the client are permitted in the [origin-based security model][FEP-fe34]: