Age | Commit message (Collapse) | Author |
|
Bugfix: Elixir 1.14
See merge request pleroma/pleroma!3740
|
|
Use Websockex to replace websocket_client
See merge request pleroma/pleroma!3743
|
|
MastoAPI: POST /api/v1/accounts/:id/remove_from_followers
See merge request pleroma/pleroma!3647
|
|
|
|
Randomness is a huge resource sink, so let's just use
a some that we made earlier
|
|
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.
|
|
Make backups require its own scope
Closes #2892
See merge request pleroma/pleroma!3721
|
|
User: generate private keys on user creation
See merge request pleroma/pleroma!3737
|
|
# Conflicts:
# CHANGELOG.md
|
|
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.
|
|
GoToSocial federation fixes
See merge request pleroma/pleroma!3725
|
|
Fix reply context fixing (Pleroma replies to Misskey threads) and removal of context objects
See merge request pleroma/pleroma!3717
|
|
Streaming fix
Closes #2796
See merge request pleroma/pleroma!3738
|
|
When generating OpenGraph and TwitterCard metadata for a post, the
summary field will be used first if it is set to generate the post
description.
|
|
|
|
Add function to calculate associated object id
Closes #2307
See merge request pleroma/pleroma!3692
|
|
Editing
Closes #1429, #2859, and #2288
See merge request pleroma/pleroma!3678
|
|
Remote interaction with posts
Closes #2807 and #978
See merge request pleroma/pleroma!3587
|
|
|
|
|
|
|
|
This reverts merge request !3649
|
|
Rewrite integration-test websocket client with Mint.WebSocket, closes #2812
Closes #2812
See merge request pleroma/pleroma!3649
|
|
|
|
|
|
|
|
|
|
Fix flaky rate_limiter_test.exs test "it restricts based on config values"
See merge request pleroma/pleroma!3688
|
|
Fix flaky/erratic test/pleroma/config/transfer_task_test.exs
See merge request pleroma/pleroma!3703
|
|
fix flaky participation_test.exs
See merge request pleroma/pleroma!3689
|
|
|
|
fix flaky test filter_controller_test.exs:200
See merge request pleroma/pleroma!3699
|
|
|
|
fix flaky test_user_relationship_test.exs:81
See merge request pleroma/pleroma!3697
|
|
|
|
There are two reasons for adding a GET endpoint:
0: Barely displaying the form does not change anything on the server.
1: It makes frontend development easier as they can now use a link,
instead of a form, to allow remote users to interact with local ones.
|
|
|
|
|
|
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.
|
|
'develop'
Treat MRF rejects as success in Oban worker
Closes #2912
See merge request pleroma/pleroma!3720
|
|
Synchronized settings for apps (frontends)
See merge request pleroma/pleroma!3698
|
|
Backport: bugfix/follow-state
Closes #2902
See merge request pleroma/pleroma!3718
|
|
|
|
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.
|
|
This field replaces the now deprecated conversation_id field, and now
exposes the ActivityPub object `context` directly via the MastoAPI
instead of relying on StatusNet-era data concepts.
|
|
This field seems to be a left-over from the StatusNet era.
If your application uses `pleroma.conversation_id`: this field is
deprecated.
It is currently stubbed instead by doing a CRC32 of the context, and
clearing the MSB to avoid overflow exceptions with signed integers on
the different clients using this field (Java/Kotlin code, mostly; see
Husky and probably other mobile clients.)
This should be removed in a future version of Pleroma. Pleroma-FE
currently depends on this field, as well.
|
|
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.
|
|
|