Additionally, ActivityPub::FetchRemoteStatusService no longer parses
activities.
OStatus::Activity::Creation no longer delegates to ActivityPub because
the provided ActivityPub representations are not signed while OStatus
representations are.
* Whenever a remote keypair changes, unfollow them and re-subscribe to them
In Mastodon (it could be different for other OStatus or AP-enabled software),
a keypair change is indicative of whole user (or instance) data loss. In this
situation, the “new” user might be different, and almost certainly has an empty
followers list. In this case, Mastodon instances will disagree on follower
lists, leading to unreliable delivery and “shadow followers”, that is users
believed by a remote instance to be followers, without the affected user
knowing.
Drawbacks of this change are:
1. If an user legitimately changes public key for some reason without losing
data (not possible in Mastodon at the moment), they will have their remote
followers unsubscribed/re-subscribed needlessly.
2. Depending of the number of remote followers, this may generate quite some
traffic.
3. If the user change is an attempt at usurpation, the remote followers will
unknowingly follow the usurper. Note that this is *not* a change of
behavior, Mastodon already behaves like that, although delivery might be
unreliable, and the usurper would not have known the former user's
followers.
* Rename ResubscribeWorker to RefollowWorker
* Process followers in batches
- Fix assumption that `url` is always a string. Handle it if it's an
array of strings, array of objects, object, or string, both for
accounts and for objects
- `sharedInbox` is actually supposed to be under `endpoints`, handle
both cases and adjust the serializer
Using _: property names is discouraged, as in the future,
canonicalization may throw an error when encountering that instead
of discarding it silently like it does now.
We are defining some ActivityStreams properties which we expect
to land in ActivityStreams eventually, to ensure that future versions
of Mastodon will remain compatible with this even once that happens.
Those would be `locked`, `sensitive` and `Hashtag`
We are defining a custom context inline for some properties which we
do not expect to land in any other context. `atomUri`, `inReplyToAtomUri`
and `conversation` are part of the custom defined OStatus context.
* Fallback to OStatus in FetchAtomService
* Skip activity+json link if that activity is Person without inbox
* If unsupported activity was detected and all other URLs failed, retry with ActivityPub-less Accept header
* Allow mention to OStatus account in ActivityPub
* Don't update profile with inbox-less Person object
* ActivityPub migration procedure
Once one account is detected as going from OStatus to ActivityPub,
invalidate WebFinger cache for other accounts from the same domain
* Unsubscribe from PuSH updates once we receive an ActivityPub payload
* Re-subscribe to PuSH unless already unsubscribed, regardless of protocol
* Add ActivityPub inbox
* Handle ActivityPub deletes
* Handle ActivityPub creates
* Handle ActivityPub announces
* Stubs for handling all activities that need to be handled
* Add ActivityPub actor resolving
* Handle conversation URI passing in ActivityPub
* Handle content language in ActivityPub
* Send accept header when fetching actor, handle JSON parse errors
* Test for ActivityPub::FetchRemoteAccountService
* Handle public key and icon/image when embedded/as array/as resolvable URI
* Implement ActivityPub::FetchRemoteStatusService
* Add stubs for more interactions
* Undo activities implemented
* Handle out of order activities
* Hook up ActivityPub to ResolveRemoteAccountService, handle
Update Account activities
* Add fragment IDs to all transient activity serializers
* Add tests and fixes
* Add stubs for missing tests
* Add more tests
* Add more tests
Akihiko Odaki
Eugen Rochko
ThibG
unarist