[-] Nothing4You@programming.dev 1 points 5 days ago

for content that was not federated prior to defederation, yes.

[-] Nothing4You@programming.dev 11 points 1 week ago

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.

[-] Nothing4You@programming.dev 43 points 2 weeks ago* (last edited 2 weeks ago)

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.

[-] Nothing4You@programming.dev 2 points 3 weeks ago

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.

[-] Nothing4You@programming.dev 8 points 3 weeks ago

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.

fyi @SpaceCadet@feddit.nl

[-] Nothing4You@programming.dev 4 points 1 month ago

I've submitted a PR to fix this, it might still make it into 0.19.4.

fyi @DABDA@lemm.ee

[-] Nothing4You@programming.dev 2 points 1 month ago

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.

[-] Nothing4You@programming.dev 3 points 1 month ago

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.

[-] Nothing4You@programming.dev 2 points 1 month ago

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?

[-] Nothing4You@programming.dev 2 points 1 month ago

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.

[-] Nothing4You@programming.dev 3 points 1 month ago

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

[-] Nothing4You@programming.dev 2 points 1 month ago

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)
view more: next ›

Nothing4You

joined 3 months ago