Adds Event support in the same way Video objects are handled, with the
name of the object as message header.
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
This reverts commit 1ad71592ad.
Since it had no limit on the number on concurrent processes it OOM killed
instances while rendering hellthreads. When I tried introducing a
concurrency limit with Task.async_stream/manual folds it lead to about 3 times
worse performance on threads larger than 1000 activities (we are talking
30s vs 1.2 minutes), I think this is not worth the about 1.5 times
performance increase on smaller threads when using it.
- Try to normalize the activity instead of object wherever possible
- Put the `user` key on non-home timelines as well so bookmarks and
thread mutes are preloaded there as well
- Skip trying to get the user when rendering mentions if the id ==
as:Public or user's follower collection
- Preload the object when getting replied to activities and do not crash
if it's not present
This almost solves the problem of Pleroma hammering the db with a lot
of queries when rendering timelines, the things left are
1. When rendering mentions and the user is not in cache, save it for
later and request all uncached users in one go
2. Somehow get rid of needing to get the latest follow activity to
detect the value of `requested` in a relationship. (create a database
view for user relationship and cache it maybe?)
In the "pleroma" section of the MastoAPI for status activities you can
see an expires_at item that states when the activity will expire, or
nothing if the activity will not expire.
The expires_at date is only visible to the person who posted the
activity. This is the conservative approach in case some attacker
decides to write a logger for expiring posts. However, in the future of
OCAP, signed requests, and all that stuff, this attack might not be that
likely. Some other pleroma dev should remove the restriction in the code
at that time, if they're satisfied with the security implications of
doing so.
feld