* 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
* 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
This PR adds section for protocol specific information, then always show
both of OStatus and ActivityPub. Specifically, this will help admins to
check PuSH subscription status and unsubscribe manually, even `protocol`
has been changed.
This also includes below changes:
* Add `overflow: hidden` to prevent float leaking
* Add missing fields for ActivityPub
This PR adds section for protocol specific information, then always show
both of OStatus and ActivityPub. Specifically, this will help admins to
check PuSH subscription status and unsubscribe manually, even `protocol`
has been changed.
This also includes below changes:
* Add `overflow: hidden` to prevent float leaking
* Add missing fields for ActivityPub
They are marked as read-only by Rails, but we know what we are doing,
so we are un-marking them as such.
The mastodon:maintenance:update_counter_caches task is not really
supposed to be run anymore (it was a one-time thing during an upgrade)
however, just in case, I have modified it to not touch ActivityPub
accounts.
Also, no point writing to logger from these rake tasks, since they
are not to be run from cron. Better to give stdout feedback.
They are marked as read-only by Rails, but we know what we are doing,
so we are un-marking them as such.
The mastodon:maintenance:update_counter_caches task is not really
supposed to be run anymore (it was a one-time thing during an upgrade)
however, just in case, I have modified it to not touch ActivityPub
accounts.
Also, no point writing to logger from these rake tasks, since they
are not to be run from cron. Better to give stdout feedback.
Keystone V2 is deprecated in favour of V3. This adds the necessary
connection parameters for establishing a V3 connection. Connections
to V2 endpoints are still possible and the configuration should
remain compatible.
This also introduces a SWIFT_REGION variable for multi-region
OpenStack environments and a SWIFT_CACHE_TTL that controls how long
tokens and other meta-data is cached for. Caching tokens avoids
rate-limiting errors that would result in media uploads becoming
unavailable during high load or when using tasks like
media:remove_remote. fog-openstack only supports token caching for
V3 endpoints, so a recommendation for using V3 was added.
Keystone V2 is deprecated in favour of V3. This adds the necessary
connection parameters for establishing a V3 connection. Connections
to V2 endpoints are still possible and the configuration should
remain compatible.
This also introduces a SWIFT_REGION variable for multi-region
OpenStack environments and a SWIFT_CACHE_TTL that controls how long
tokens and other meta-data is cached for. Caching tokens avoids
rate-limiting errors that would result in media uploads becoming
unavailable during high load or when using tasks like
media:remove_remote. fog-openstack only supports token caching for
V3 endpoints, so a recommendation for using V3 was added.
