Fix reading `sharedInbox` from remote ActivityPub profiles. This caused public payloads not
to be deduplicated when sending public payloads to remote ActivityPub servers. Refetching
profiles should now fix this.
Closes#124
This should stop invalid payloads being sent out, like shares
to the Diaspora network that have no target_guid (due to originating
from the AP side).
Temporary solution until mock posts are automatically created for
better cross-compatibility.
Refs: https://git.feneas.org/socialhome/socialhome/issues/522
Since we're going to reuse the Diaspora style mentions syntax
(without the display name part), pull out the mentions extract code
from the Diaspora mixins to the base mixins.
No point having a separate object type when the features
of it match the entity Image type.
Also send out Image instead of Document for image type
attachments. Lets see if Mastodon and others are fine
with this.
Refs: https://git.feneas.org/socialhome/socialhome/issues/522
Entities with `raw_content` now also contain a `_media_type` and
`rendered_content`.
The default `_media_type` is `text/markdown` except for ActivityPub
originating posts it defaults to `text/html`. If the ActivityPub
payload contains a `source`, that mediaType will be used instead.
If we rip out embedded images from raw_content then mark them as
pyfed:inlineImage. Receiving side will know then that those
attachments are included as inline images should they wish to
exclude those, if they support inline images via markdown or html.
Also rip out all embedded images, not just the ones from the
senders domain.
Entities processed by inbound mappers will now have a list of
receivers in `_receivers`. This replaces the
`_receiving_actor_id` which was previously set for Diaspora entities.
UserType now has a `receiver_variant` which is one of `ReceiverVariant`
enum. `ACTOR` means this receiver is a single actor ID.
`FOLLOWERS` means this is the followers of the ID in the receiver.
Contains terrible hack to figure out if ActivityPub to/cc contains
a reference to the followers collection of the sender 🙈 . Will replace
"later" with proper fetch+cache solution, once we have a cache.
Refs: https://git.feneas.org/socialhome/socialhome/issues/522
Retraction produces a { Delete { Tombstone }} and receiving
one produces a Retraction. Retraction.entity_type is set as
"Object" since we don't know it just by looking at the payload.
With two elements, `private` and `public`. These should be URL's
indicating where to send payloads for the recipient.
ActivityPub profiles will parse these values from incoming profile
documents. Diaspora entities will default to the inboxes in the
specification.
When receiving an ActivityPub Follow, send back an Accept activity
automatically. Due to application hook needed to fetch sending
user private key (for signing), this is only available if Django
is installed since currently application hooks exist only for
Django configuration.
Django applications should include a new configuration item
"get_private_key_function" which points to a function which takes
a user identifier (fid, handle or guid) and returns a private key
in RSA object format.
Alain St-Denis