this is by design. actor ids (unique identifier for accounts) should not be reused due to undefined behavior for how other instances will deal with that.
if you want to have a more technical explanation, https://socialhub.activitypub.rocks/t/reuse-of-identity-channel-addresses-revocation-reissue-of-keys/2888 does a decent job at explaining some of the issues with this.
it should be noted that these bans are community bans, not instance bans. your title makes it look like people are getting instance banned from lemmy.world, while the examples you’ve shown are about community bans.
if i’m not mistaken, several/most of the lemmy.ml bans/ban complaints have been about instance bans, which affect all communities on the instance.
except instance A will actively reject such content from B users when it hears about it from C.
generally it should be expected not to see any new content from B, but historic content will still exist and basically be in a frozen state.
the main problem is still that reports are not reliably getting to remote moderators: https://github.com/LemmyNet/lemmy/issues/4744
other than that it should be working.
It should be noted that the (visibility of) community bans are a result of better enforcement of site bans in 0.19.4, which for now is implemented by sending out community bans for local communities when a user gets instance banned: https://github.com/LemmyNet/lemmy/pull/4464
Prior to this, when a user got instance banned from .ml, they were also implicitly banned from .ml communities, but this was only known to the instance they were banned on. As a result, users were still able to post, comment, and vote on those communities, but it would be visible only on that user’s instance, not federated anywhere else. Visibility of this ban was exclusively on the banning instance’s modlog.
I’ve submitted a PR to fix this, it might still make it into 0.19.4.
fyi @DABDA@lemm.ee
curious, what do you mean by checking them?
if you open https://lemmy.world/api/v3/user/unread_count after being logged in, it should at least tell you what kind of unread message it is.
with that information it can probably be narrowed down a bit.
i don’t think this is related to an inconsistency with blocked users, as that is only being fixed in 0.19.4 or 0.19.5: https://github.com/LemmyNet/lemmy/issues/4227
moderated or deleted comments as mentioned by others don’t look like they would be the case when i’m looking at the 0.19.3 code.
the bot reply mentioned by @DABDA@lemm.ee seems like a very plausible explanation, as bot accounts are hidden from the comment reply list in the api, but they’re not currently excluded from the notification count.
i’ll have a look at whether that is still the case in the current development version in a bit and submit a pr to fix that if it is.
starting with 0.19.4, at least user settings will default to their browser’s accepted languages on registration: https://github.com/LemmyNet/lemmy/pull/4550
this doesn’t solve actually tagging content, but it some progress at least.
lemmy currently only sends one activity per receiving instance at a time, so there is a round trip for every single post, comment, vote, etc., before the next activity will be sent. you wouldn’t see any increased number of connections, as there’s only a single one.
do you have access logs for /inbox with the lemmy.world’s user agent? you might be able to derive some information from that if requests increased over time or something, maybe also response status codes?
I can’t tell you why you’re lagging but you’re clearly lagging quite a bit behind.
which country is your instance located in?
did you (or someone else on your instance) recently subscribe to a bunch of high traffic communities on lemmy.world, which would make lemmy.world send more activities to you?
lemmy by default only sends activities in a community to another instance if there’s at least one subscriber to the community on that instance. if you’re located far from finland, where lemmy.world is located, you might have been able to keep up just enough before this, although this isn’t the first time as the graphs above show.
ah i was misreading your comment, i thought you were talking about the sending side. for the receiving side i agree, but the reason for the duplicate activities is yet to be found: https://github.com/LemmyNet/lemmy/issues/4609
records can’t be duplicated in the database, the activity id is a unique key:
lemmy=# \d sent_activity
Table "public.sent_activity"
Column | Type | Collation | Nullable | Default
-----------------------------+--------------------------+-----------+----------+-------------------------------------------
id | bigint | | not null | nextval('sent_activity_id_seq'::regclass)
ap_id | text | | not null |
data | json | | not null |
sensitive | boolean | | not null |
published | timestamp with time zone | | not null | now()
send_inboxes | text[] | | not null |
send_community_followers_of | integer | | |
send_all_instances | boolean | | not null |
actor_type | actor_type_enum | | not null |
actor_apub_id | text | | |
Indexes:
"sent_activity_pkey" PRIMARY KEY, btree (id)
"sent_activity_ap_id_key" UNIQUE CONSTRAINT, btree (ap_id)
for content that was not federated prior to defederation, yes.