Implement validation logic before queueing messages

[Nothing4You]

we can borrow parts of the validation logic from https://github.com/LemmyNet/activitypub-federation-rust/

this would need to be verified at the very least:

• [x] content type header (a5758a15d0aa1cf5668f3e0977560340086b0dbd)
• [x] body is valid json (4c6d64899dd331fa0847be7b99562c82ec4e7b28)
• [x] every activity probably needs to have an id (a885106e08b48f880dbb70dad1c1667574b1292b)

it should be checked if there are scenarios where lemmy will throw a 5xx status for bad data, as that could fully block the federation queue.

this might be nice to have, but it adds quite a bit of complexity:

• [ ] validate http request signature https://pypi.org/project/http-sf/ can probably be used for this, we'd want to validate just the signature in itself, without validating the signer, as we don't have this information readily available

[Nothing4You]

if signature validation is implemented, the public key of the expected instance could be passed as env var to ensure it's originating from the correct source

[Nothing4You]

https://www.w3.org/TR/activitypub/#server-to-server-interactions

POST requests (eg. to the inbox) MUST be made with a Content-Type of application/ld+json; profile="https://www.w3.org/ns/activitystreams" […]. Servers SHOULD interpret a Content-Type […] of application/activity+json as equivalent to application/ld+json; profile="https://www.w3.org/ns/activitystreams" for server-to-server interactions.

[Nothing4You]

https://www.w3.org/TR/activitypub/#server-to-server-interactions

An Activity sent over the network SHOULD have an id, unless it is intended to be transient (in which case it MAY omit the id).

I don't believe Lemmy is currently able to send activities without ID, although this should be double checked. If Lemmy doesn't need this, this should just be documented to reject activities that don't have an ID. We could return a 5xx status code if it's valid JSON without id to at least have the sender (if they are able to retry activities) not drop the activity.

[Nothing4You]

If I understand the activitypub-federation-rust code right, all activities are expected to have an id:

https://github.com/LemmyNet/activitypub-federation-rust/blob/ee268405f71a74051fbb0b5bd10426b0f5f1a2ac/src/traits.rs#L206-L230

[Nothing4You]

if signature validation is implemented, the public key of the expected instance could be passed as env var to ensure it's originating from the correct source

this is not actually that easy, as the signer could be either the instance itself or any of the actors on it, such as a user or community, in which case a different keypair would be used.

[Nothing4You]

I will ignore signature validation for now in favor of IP whitelisting