GoToSocial federation fixes
keyId
heuristics for GoToSocial
GoToSocial exposes a stubbed Actor containing only a public key via /users/:username/main-key
, and uses this as the keyId
for incoming requests.
AkkomaDev/Akkoma's (FloatingGhost's, precisely) heuristic commit has been cherry-picked, which supports this extra route in the same way Pleroma supports guessing the original Actor URI from the Misskey /users/:id/publickey
keyId
s.
Note that guessing Actor URIs/IDs from the keyId
is absolutely wrong, and has stayed as such in Pleroma for surprisingly long; Key
objects should be properly supported in the same way Mastodon does, fetching objects from the given keyId
, and if a Key
is returned, to assign it to its owner accordingly.
replies
field fixing
Fixes to Some software, like GoToSocial, expose replies as ActivityPub
Collections, but do not expose any item array directly in the object,
causing validation to fail via the ObjectID validator. Now, Pleroma will
drop the incoming replies
field in this situation too.
A better fix for this issue would be to implement Collection
dereferencing
for such fields.
Changes to HTTP signatures
The (request-target)
used by Pleroma is non-standard, but many HTTP
signature implementations do it this way due to a misinterpretation of
the draft 06 of HTTP signatures: path
was interpreted as not having
the query, though later examples show that it must be the absolute path
with the query part of the URL as well.
This behavior is kept to make sure most software (Pleroma itself,
Mastodon, and probably others) do not break, but Pleroma now accepts
signatures for a (request-target)
containing the query, as expected by
many HTTP signature libraries, and clarified in the draft 11 of HTTP
signatures.
Additionally, the new draft renamed (request-target)
to @request-target
.
We now support both for incoming requests' signatures.
Outgoing requests remain unchanged.