- `shareInbox` is now used when available, thus tests now check for that
- `client._ap_storage` is used, thus is added to the mockClient
`ap_const.NS_AP_PUBLIC` is now in `cc` instead of `to` field
rel 371
- reactions data has been updated following changes in XEP-0470 plugin
- it is now possible to remove a reaction using uppercase `-R`
- short option from `--replace` has been removed, as it is more handy to use `-R` to
remove reactions
rel 371
- 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.
`tools.datetime.format_datetime` was expecting aware datetime objects while
`tools.utils.xmpp_date` was returning naive datetime objects. A check has been added to
the former one, and latter one has been modified to return aware datetime objects.
Includes implementation of XEP-0082 (XMPP date and time profiles) and tests for both new plugins.
Everything is type checked, linted, format checked and unit tested.
Adds new dependency xmlschema.
fix 377
Add tests for
- XMPP blog post repeat => AP Announce conversion and vice versa
- XMPP pubsub `noticed` attachment => AP like conversion and vice versa
rel 370
`pubsub/attachments` subcommands has a `get` and a `set` subcommand to manage attachments
of a pubsub item.
`blog` has the same subcommands, the only difference is that if `--node` is not specified,
the default blog namespace will be used.
rel 370
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
domish.Element.elements should be called with namespace and element name as 2 arguments,
but it has been confused in several places with the call to `domish.Element.addElement`
which is often done with a `(namespace, name)` tuple. Unfortunately calling with a tuple
is accepted and doesn't raise any error in `elements`, but this result in a wrong element
returned.
This patch fixes the erroneous calls.
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
Priority lets order the callback list when an event is received. This is important in some
use case, notably when a plugin needs to check the former item before it is deleted from
cache or updated.
rel 370
