30 to 70% of the objects in the object table are simple JSON objects
containing a single field, 'id', being the context's ID. The reason for
the creation of an object per context seems to be an old relic from the
StatusNet era, and has only been used nowadays as an helper for threads
in Pleroma-FE via the `pleroma.conversation_id` field in status views.
An object per context was created, and its numerical ID (table column)
was used and stored as 'context_id' in the object and activity along
with the full 'context' URI/string.
This commit removes this field and stops creation of objects for each
context, which will also allow incoming activities to use activity IDs
as contexts, something which was not possible before, or would have been
very broken under most circumstances.
The `pleroma.conversation_id` field has been reimplemented in a way to
maintain backwards-compatibility by calculating a CRC32 of the full
context URI/string in the object, instead of relying on the row ID for
the created context object.
Mastodon uses the Reject activity also for the purpose of removing
a follower, in addition to reject a follow request. We should
also update the original Follow activity in this case.
Made `Pleroma.Web.MastodonAPI.AccountView.render("show.json", _)` demand :for or :force option in order to prevent incorrect rendering of empty map instead of expected user representation with truish :restrict_unauthenticated setting.
The hack with caching the follow relationship was introduced
when we still were storing it inside the follow activity, resulting in
slow queries. Now we store follow state in `FollowRelationship` table,
so this is no longer necessary.
Every time someone tries to use it, it goes mad and tries to scrape the
entire fediverse for no visible reason, it's better to just remove it
than continue shipping it in it's current state.
idea acked by lain and feld on irc
Closes#1595#1422
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>
