The function only uses the host aspect of the instance and re-fetches
the rest from the database anyway, so it does not make sense to require
to pass the whole instance object as an argument everywhere.
Previously, the deliver and inbox queue jobs would also take care of
updating the instance metadata. On a low resource server like mine,
the deliver queue is often the "critical path" and handling this
there is not a good idea.
Instead, this is handled in a separate job and with a slight delay,
to not interfere with bulk delivery jobs.
Implements a simple rendering for ordered and unordered lists.
To properly support nested lists, and lists inside of blockquotes,
this necessitated rewriting the `analyze` function to return text.
This now also means that markup inside of blockquotes will be parsed properly.
Since I don't use them and they never really worked correctly anyway,
there is no real point in keeping them around. Also, removing them
allows to shed quite a bit of "weight" in (dev)dependencies.
ActivityPub through ActivityStreams 2.0 requires the use of the
expansion algorithm from JSON-LD 1.0 which is not able to handle nested contexts.
Fixes commit 21ab8e75ee, thanks to sn0w.
When a web or queue worker exited unexpectedly, the new restarted worker would
not have any mode set and so would try to do web and queue worker stuff at the
same time, which was not the intended behaviour.
Changelog: Fixed
A cache for instances already exists and is exported there. Also the
type annotation here seemed wrong anyway because there did not seem to
be a way for that fetcher to actually ever return `null` as a value.
This should hopefully relieve some of the massive hammering on the
database when mass delivery jobs are running.
However, this also means that instance blocks are applied with a
slight delay on delivery queue. Since the settings page in the
native frontend already warns about this, I think it should be fine.
And the maximum time an instance block would be delayed would be
somewhere around 5min which IMO is also tolerable.
Changelog: Changed
TBH I'm still not quite convinced that this is really necessary but also
since treating an id mismatch like a redirect, I also don't think it
should break anything.
This makes `redirects` contain the number of remaining redirects, which
makes it easier to limit the number of further redirects that should be
allowed.
Especially in the case where the private key is used in an "array deliver",
it makes sense to only get the private key once instead of having the overhead
of fetching the key for each HTTP request.
ActivityPub requests on routes which do not support activitypub
are now replying with HTTP status code 406 "Not Acceptable".
ActivityPub clients are required by the W3C TR to set the `Accept`
header. If this accept header is detected on an unexpected route,
the whole request will be aborted with the status code above.
This is an additional measure for clients who might not be aware of
having to check the content-type header of the reply.
Ref: https://github.com/w3c/activitypub/issues/432
Changelog: Security
The user was already deleted from the user cache, so requesting the
user returned null. Because the key was not null, there was a non-null
return, in turn making further code think, fetching the user was
successful.
This can be useful when adding a feature for admins and moderators
where they will be able to immediately deal with their own report,
i.e. forwarding it to the other instance.
Changelog: Added
It does not make sense to re-request the same resource with the same
parameters and expect a different content-type to be returned. Also
this makes the error message more sensible and understandable.
