Age | Commit message (Collapse) | Author |
|
Randomness is a huge resource sink, so let's just use
a some that we made earlier
|
|
`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.
|
|
# Conflicts:
# CHANGELOG.md
# test/pleroma/user_test.exs
|
|
|
|
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>
|
|
This reverts merge request !3684
|
|
|
|
EmojiReactValidator: fix emoji qualification
See merge request pleroma/pleroma!3684
|
|
I noticed that pictures taken with Ubuntu-Touch have whitespace in one of the fields
This should just be ignored imo
|
|
The previous pictures were labeled as public domain, but are actually a collage of pictures under other licenses.
I now replaced them with a jpeg of simply a white pixel.
|
|
During attachment upload Pleroma returns a "description" field. Pleroma-fe has an MR to use that to pre-fill the image description field, <https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1399>
* This MR allows Pleroma to read the EXIF data during upload and return the description to the FE
* If a description is already present (e.g. because a previous module added it), it will use that
* Otherwise it will read from the EXIF data. First it will check -ImageDescription, if that's empty, it will check -iptc:Caption-Abstract
* If no description is found, it will simply return nil, just like before
* When people set up a new instance, they will be asked if they want to read metadata and this module will be activated if so
This was taken from an MR i did on Pleroma and isn't finished yet.
|
|
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.
|
|
|
|
|
|
|
|
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
|
|
Support private pinned posts from Mastodon
See merge request pleroma/pleroma!3611
|
|
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
|
|
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.
|
|
Ref: emit-move
|
|
Pipeline Ingestion: Page
See merge request pleroma/pleroma!3097
|
|
|
|
Speeds up recompilation by reducing compile-time deps
|
|
|
|
Pipeline Ingestion: Note
Closes #290
See merge request pleroma/pleroma!2984
|
|
|
|
Pinned posts federation
Closes #521
See merge request pleroma/pleroma!3312
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- save object ids on pin, instead of activity ids
- pins federation
- removed pinned_activities field from the users table
- activityPub endpoint for user pins
- pulling remote users pins
|
|
Sometimes people put emoji in the subject, which results in the subject
looking broken if someone replies to it from a server that does not
have the said emoji under the same shortcode. This patch solves the problem
by extending the emoji set available in the summary to that of the parent
post.
|
|
|
|
|
|
Closes: https://git.pleroma.social/pleroma/pleroma/-/issues/2535
|
|
|
|
grep -rl '# Copyright © .* Pleroma' * | xargs sed -i 's;Copyright © .* Pleroma .*;Copyright © 2017-2021 Pleroma Authors <https://pleroma.social/>;'
|
|
|
|
control characters
|
|
|
|
Validate the content-type of the response when fetching an object,
according to https://www.w3.org/TR/activitypub/#x3-2-retrieving-objects.
content-type headers had to be added to many mocks in order to support
this, some of this was done with a regex. While I did go over the
resulting files to check I didn't modify anything unrelated, there is a
possibility I missed something.
Closes pleroma#1948
|
|
|
|
|
|
|
|
Also, set sensitive to true if we have an nsfw hashtag present.
|
|
|