Mastodon doesn't like when "@" is percent-encoded (because it doesn't do it, and it checks
that the URL matches the ID without taking care of percent-encoding).
When a `Delete` activity was received and the object was the emitting actor itself, the
signature checking was failing if the actor was unknown (due to the impossibility to
retrieve the actor public key, as it is no more accessible).
To avoid that, those notifications are ignored for now. In the future they should clean
the cache linked to this actor.
if something is going wrong during `checkSignature` (other than signature verification
failing), a `500 Internal Server Error` code is returned, and the connection is properly
closed.
the body is parsed immediately during a `POST` request: this avoids duplication of code,
and allows to check the body data before continuing (will be used to filter some requests
in a future patch).
- XMPP Events <=> AP Events conversion
- `Join`/`Leave` activities are converted to RSVP attachments and vice versa
- fix caching/notification on item published on a virtual pubsub node
- add Ad-Hoc command to convert XMPP Jid/Node to virtual AP Account
- handle `Update` activity
- on `convertAndPostItems`, `Update` activity is used instead of `Create` if a version of
the item is already present in cache
- `events` field is added to actor data (and to `endpoints`), it links the `outbox` of the
actor mapping the same JID with the Events node (i.e. it links to the Events node of the
entity)
- fix subscription to nodes which are not the microblog one
rel 372
- Pubsub Attachments plugin has been renamed to XEP-0470 following publication
- XEP-0470 has been updated to follow 0.2 changes
- AP reactions (as implemented in Pleroma) are converted to XEP-0470
- XEP-0470 events are converted to AP reactions (again, using "EmojiReact" from Pleroma)
- AP activities related to attachments (like/reactions) are cached in Libervia because
it's not possible to retrieve them from Pleroma instances once they have been emitted
(doing an HTTP get on their ID returns a 404). For now those cache are not flushed, this
should be improved in the future.
- `sharedInbox` is used when available. Pleroma returns a 500 HTTP error when ``to`` or
``cc`` are used in a direct inbox.
- reactions and like are not currently used for direct messages, because they can't be
emitted from Pleroma in this case, thus there is no point in implementing them for the
moment.
rel 371
Mastodon in wrongly unquoting URL path in `(request-target)`, and thus Libervia was doing
the same to check signature. However that doesn't work with Pleroma which is using the
path value used in the request (percent-encoded), and thus Pleroma signature were
rejected.
To work around that, signature is first checked without unquoting, and if this fails a new
check is done with unquoting.
Bug has been reported at https://github.com/mastodon/mastodon/issues/18871
rel 371
headers where not lower-cased in `headers` field of signature data, resulting in signature
being rejected by Pleroma (but it was working with Mastodon).
Also add `Content-Type` header.
rel 371
gather data to show according to verbosity and log it all at once with a small `<<<` or
`>>>` indicating the direction. With a verbosity of 3, headers are also shown.
convert `noticed` attachments coming from XMPP to suitable `Like` activities. Virtual node
is created in cache when necessary, and virtual items published to virtual JID mapping AP
accounts are cached too.
rel 370
when a retract item is received, the former item is now retrieve from cache, and if it was
a "repeat" blog post, it is converted to the suitable `Undo` of `Announce` activity
(instead of the default `Delete` activity).
rel 370
priority is needed because we'll need to inspect former items on retract to check the
Acitivy to use (it may be an `Undo` activity is some cases), and this must be done before
the cache is updated by pubsub cache plugin.
rel 370
When a XEP-0372 mention is received, the linked pubsub item is looked after in cache, and
if found, it is send to mentioned entity with `mention` tag added.
However, this doesn't work in some cases (see incoming doc for details). To work around
that, `@user@server.tld` type mention are also scanned in body, and mentions are added
when found (this can be disabled with `auto_mentions` setting).
Mention are only scanned in "public" messages, i.e. for pubsub items, and not direct
messages.
rel 369
when a mentions are found in AP items (either with people specified directly as target, of
with `mention` tags as in
https://www.w3.org/TR/activitystreams-vocabulary/#microsyntaxes), they are converted to
XEP-0372 `mention` references.
This is only done for Pubsub items (i.e. not for private messages).
rel 369
metadata are converted to vCard4 (XEP-0292).
Avatar is converted to User Avatar (XEP-0084), it is downloaded, resized, converted and
cached on first request.
If avatar is bigger than 5 Mio, it won't be used.
rel 368
XMPP identity data (coming from various XEPs, notably XEP-0292 (vCard4) and XEP-0084 (User
Avatar)) are now used to complete actor data.
Avatar files can now be delivered with the `avatar` type in URL.
rel 368
handle retractation of messages. As it is not possible to know from the AP item alone if
we need to to a message retractation (XEP-0424) or a pubsub retractation (XEP-0060), we
now cache sent message, and decide which method to use according to how the item is cached
(i.e. in message history or in pubsub cache).
rel 367
Convert XEP-0424 message retractation request to suitable AP delete activity.
The message workflow and its triggers are now used instead of a direct observer, as it is
now possible to do so with component, and this let other plugin to parse and eventually
update metadata.
rel 367
when an item `retract` is received from a node from which an AP actor is subscribed, a
corresponding `Delete` activity is created and sent to AP followers.
Trying to retract an item from a virtual node of the gateway pubsub service now return a
`forbidden` stanza error (those nodes are handled on AP side and thus are not owned by
XMPP entities).
rel 367
this patch implements those major features:
- `publish` is implemented on virtual pubsub service, thus XMPP entities can now publish
to AP using this service
- replies to XMPP items are managed
- `inReplyTo` is filled when converting XMPP items to AP objects
- `follow` and `unfollow` (actually an `undo` activity) are implemented and mapped to
XMPP's (un)subscribe. On subscription, AP actor's `outbox` collection is converted to
XMPP and put in cache. Subscriptions are always public.
- `following` and `followers` collections are mapped to XMPP's Public Pubsub Subscription
(which should be XEP-0465, but the XEP is not yet published at the time of commit), in
both directions.
- new helper methods to check if an URL is local and to get JID from actor ID
doc will follow to explain behaviour
rel 365
- HTTP signature is checked for incoming messages
- AP actor can now be followed using pubsub subscription. When following is accepted, the
node is cached
- replies to posts are put in cached pubsub comment nodes, with a `comments_max_depth`
option to limit the number of comment nodes for a root message (documentation will come
to explain this).
ticket 364
