GoToSocial sends 'tag' values as a single object if there is only one
user mentioned, rather than an array with an object inside it.
This causes Bookwyrm to reject the tag since it comes through as a
dict rather than a list.
This commit fixes this at the point the incoming AP object is transformed
so that "mention" tags are turned into a mention_user.
Bookwyrm keyIds are at `userpath/#main-key`, however when signing AP objects we have claimed in the headers that the keyId is at `userpath#main-key`.
This is incorrect, and makes GoToSocial's strict checking break.
Simply updating the signatures to use the correct KeyId breaks legacy Bookwyrm's signature checks, becuase it assumes that the keyId path is the same as the user path plus a fragment.
This commit allows for either option, by sending the request a second time with the incorrect keyId if sending with the correct one causes an error.
Previously the 'tag' value in an activitypub object was assumed to be a List (array).
Some AP software sends 'tag' as a Dict (object) if there is only a single tag value.
It's somewhat debatable whether this is spec compliant but we should aim to be robust.
This commit puts an individual mention tag inside a list if necessary.
Fixes#2801
Related to #2794
It is legitimate to use any url for the user's key id. We have been assuming this id is the user id plus a fragment (#key-id) but this is not always the case, notably in the case of GoToSocial it is at /key-id. This commit instead checks the remote user's information to see if the key id listed matches the key id of the message allegedly received from them.
Whilst troubleshooting this it also became apparent that there is a mismatch between Bookwyrm users' keyId and the KeyId we claim to be using in signed requests (there is a forward slash missing). Since everything after the slash is a fragment, this usually slips through but we should be consistent so I updated that.
This is the header described in the ActivityPub spec, which should fix
some federation problems with GoToSocial and potentially other picky
services.
Related: #2794, superseriousbusiness/gotosocial#1676
This is still slow in some cases, despite #2723, so this information
should give useful data about how it could be optimized more.
This also adds some abstraction around getting the tracer, just to
follow the advice in the OpenTelemetry documentation not to use __name__
directly to set the tracer name. The advice is ignored in most of their
examples, so it probably doesn't matter, but IDK, seems reasonable to
try to follow it.
Related: #2720
This wasn't a problem in the past, since we only enabled automatic
instrumentation when this was set up, but it does cause errors when
trying to add manual instrumentation.
