This will prevent a user with a large number of posts from negatively affecting performance of the outgoing federation queue if they delete their account.
Non-Create/Listen activities had their associated object field
normalized and fetched, but only to use their `id` field, which is both
slow and redundant. This also failed on Undo activities, which delete
the associated object/activity in database.
Undo activities will now render properly and database loads should
improve ever so slightly.
This fixes a race condition bug where keys could be regenerated
post-federation, causing activities and HTTP signatures from an user to
be dropped due to key differences.
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 that field in this situation too.
`context` fields for objects and activities can now be generated based
on the object/activity `inReplyTo` field or its ActivityPub ID, as a
fallback method in cases where `context` fields are missing for incoming
activities and objects.
Incoming Pleroma replies to a Misskey thread were rejected due to a
broken context fix, which caused them to not be visible until a
non-Pleroma user interacted with the replies.
This fix properly sets the post-fix object context to its parent Create
activity as well, if it was changed.
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.
Tries fully-qualifying emoji when receiving them, by adding the emoji
variation sequence to the received reaction emoji.
This issue arises when other instance software, such as Misskey, tries
reacting with emoji that have unqualified or minimally qualified
variants, like a red heart. Pleroma only accepts fully qualified emoji
in emoji reactions, and refused those emoji. Now, Pleroma will attempt
to properly qualify them first, and reject them if checks still fail.
This commit contains changes to tests proposed by lanodan.
Co-authored-by: Haelwenn <contact+git.pleroma.social@hacktivis.me>
In Create validator we do not validate the object data,
but that is because the object itself will go through the
pipeline again, which is not the case for Update. Thus,
we added validation for objects in Update activities.
I first focussed on getting things working
Now that they do and we know what tags there are, I put some thought in providing better names
I use the form <what_it_controls>_<what_it_allows_you_to_do>
:statuses_read => :messages_read
:status_delete => :messages_delete
:user_read => :users_read
:user_deletion => :users_delete
:user_activation => :users_manage_activation_state
:user_invite => :users_manage_invites
:user_tag => :users_manage_tags
:user_credentials => :users_manage_credentials
:report_handle => :reports_manage_reports
:emoji_management => :emoji_manage_emoji
Tries fully-qualifying emoji when receiving them, by adding the emoji
variation sequence to the received reaction emoji.
This issue arises when other instance software, such as Misskey, tries
reacting with emoji that have unqualified or minimally qualified
variants, like a red heart. Pleroma only accepts fully qualified emoji
in emoji reactions, and refused those emoji. Now, Pleroma will attempt
to properly qualify them first, and reject them if checks still fail.
Instead of `Pleroma.User.all_superusers()` we now use `Pleroma.User.all_superusers(:report_handle)`
I also changed it for sending emails, but there were no tests.
* rejected_shortcodes is defined as a list of strings in the
configuration description. As such, database-based configuration was
led to handle those settings as strings, and not as the actually
expected type, Regex.
* This caused each message passing through this MRF, if a rejected
shortcode was set and the emoji did not exist already on the instance,
to fail federating, as an exception was raised, swiftly caught and
mostly silenced.
* This commit fixes the issue by introducing new behavior: strings are
now handled as perfect matches for an emoji shortcode (meaning that if
the emoji-to-be-pulled's shortcode is in the blacklist, it will be
rejected), while still supporting Regex types as before.
Even though latest PleromaFE supports displaying these properly, mobile
apps still exist, so I think we should offer a workaround to those who
want it.
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.
Notes:
- QuestionValidator didn't have a :name field but that seems like a mistake
- `_fields` functions can't inherit others because of some Validators
- bto/bcc fields were absent in activities, also seems like a mistake
(Well IIRC we don't or barely support bto/bcc anyway)
* Policies were put under a new module (Pleroma.Web.ActivityPub.MRF.Policy instead of Pleroma.Web.ActivityPub.MRF), but this wasn't changed in the Pleroma.Web.ActivityPub.MRF @mrf_config_descriptions
* I don't have a unit test to prevent similar problems in the future because I don't find a proper way to do it
* The descriptions in the unit tests are defined in the unit tests, so if someone changes module names in the code, the tests wont see it
* The list is generated in Pleroma.Docs.Generator.list_behaviour_implementations, but I can't do a check in the when clause of the function to see if the provided module is a behaviour or not.
Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3509
* Policies were put under a new module (Pleroma.Web.ActivityPub.MRF.Policy instead of Pleroma.Web.ActivityPub.MRF), but this wasn't changed in the Pleroma.Web.ActivityPub.MRF @mrf_config_descriptions
* I don't have a unit test to prevent similar problems in the future because I don't find a proper way to do it
* The descriptions in the unit tests are defined in the unit tests, so if someone changes module names in the code, the tests wont see it
* The list is generated in Pleroma.Docs.Generator.list_behaviour_implementations, but I can't do a check in the when clause of the function to see if the provided module is a behaviour or not.
Alexander Tumin