but i wanna

@twinspin6 would never happen here

@snacks no deletes?

@twinspin6 akkoma doesn't stop you from replying to deleted stuff, i've also never seen a 429 here

@snacks this only started after the latest update
also running akkoma 👁

@twinspin6 never update

@snacks

@twinspin6 if it doesn't say it's a security update i sleep

@twinspin6 i updated debian 2 days ago. That outta do

@snacks DEBIAN

@twinspin6 @snacks i feel like if your instance has poa or st in the url it increases your chances of getting attacked 100x
how many vulnerabilities did they get exploited by

@twinspin6 they can't throttle you!!!! you must fav!!!!

@cell @snacks i mean that's true of course

@kaia i was going so hard on that left click you don't even know

@cell @snacks @twinspin6
>how many vulnerabilities did they get exploited by
Two I think. The MediaProxy XSS and unpatched SSH.

@phnt @snacks @twinspin6 come of think of it, how come we don't hear much about big mastodon instances getting exploited

@snacks @twinspin6 wait u run akkoma ?????

@fiore @twinspin6 no, i'm in a coma

@fiore @twinspin6 we switched to akkoma at some point for uhhhhhhhhhhh emoji reactions?

@snacks @twinspin6 good choice snacks

@fiore @twinspin6 yeah, now i don't have to reply with nothing but an emoji anymore and i get pleromafe classic™

@fiore @twinspin6 it also didn't get the weird follow bugs pleroma got

@fiore @twinspin6 just feels like pleroma oldstable

@snacks @twinspin6 and the loading screen . oh how i dread that loading screen

@snacks @fiore there are still valid reasons to reply with just an emoji (it allows the other person to reply to you)

@twinspin6 @fiore

@twinspin6 @snacks

@snacks @fiore

@cell @snacks @twinspin6 There were some in the same timeframe, but I guess Mastodon isn't as attractive. They also have researchers actually auditing their codebase from time to time, like the recent signature bypass was found by someone from Qualys I think. The rest doesn't have that, they have to audit it themselves, throw an LLM at it or pay someone to do it. The last two involve money and potentially lots of it, so your smaller Fedi project won't do it.

@phnt @snacks @cell @twinspin6 btw every fedi software should do LLM audits from time to time. from the 6 different systems i looked at, only 2 did not have any catastrophic issues (mastodon and mitra).

@snacks @fiore @twinspin6 it looks like Pleroma and Akkoma are doing the same things and I don't see that my fix for the core issue actually got merged. The MR is mangled from the gitlab to forgejo migration and doesn't show my diffs.

So I think it's technically still broken on both. The more crashy your server is the more likely you'll hit the bug.

Bug being: all logic for timeline rendering, filtering, etc etc uses the FollowingRelationships table to decide the truth.

But when you look at an account directly it uses the last Follow activity instead!

So it can show that you're following someone because there is an accepted Follow activity in the database, but the server crashed before it updated the FollowingRelationships table.... so it *says* you're following them, but timelines and everything else is still operating under the assumption you are *not* following them.

@lain @snacks @cell @twinspin6 They should, but also not everyone is willing to spend 200USD on a capable frontier model on a project they do for fun on the weekends. That's the imbalance I meant.

@phnt @snacks @cell @twinspin6 they can use the free stuff on opencode, that's more than enough

@feld @fiore @snacks @twinspin6 I think that was merged in the 2.7.X cycle, or at least something similar to it.

@lain if you have a model open, tell it to read this PR and check that the change was actually merged. I don't think it was. I think this was lost and I don't even have a copy of the branch anymore.

https://git.pleroma.social/pleroma/pleroma/pulls/7628

@phnt @fiore @snacks @twinspin6 well I'm looking at the code right now and it seems that User.get_follow_state/2 is still doing the wrong thing by calling Utils.fetch_latest_follow

@feld fable: feld's fix was merged. phnt is right in the thread. The Gitea PR looks empty because of the migration, but the commits are in develop via the merge of the following-state-bug branch on 2024-09-06, and shipped in v2.8.0. The changelog entry "Resolved edge case where the API can report you are following a user but the relationship is not fully established" is from that MR. The current account view still has the fix: following and followed_by come from the FollowingRelationship table only.

feld's latest post is about code his MR never touched. They say User.get_follow_state/2 still calls fetch_latest_follow. That is true, but the original MR only changed the account view and its test. The Follow-activity fallback in get_follow_state dates from Egor's 2020 commit that introduced the function, and it only fires when there is no FollowingRelationship row and the target is remote. After the merged fix, it influences only two things:

- The requested flag in the account relationship view, and only when following is already false. A stale pending Follow activity with no table row shows as "requested" rather than as "following", which is the milder failure.
- User.do_unfollow, which decides whether an unfollow is allowed. A stale accepted Follow lets the unfollow proceed, which actually helps users clean up the ghost state, since the ActivityPub unfollow then cancels the stale activity.

So the "says following but timelines disagree" bug feld describes is fixed on Pleroma develop and all releases since 2.8.0. What remains is a legacy fallback that could be removed so requested and unfollow also trust the table alone. That would be a small follow-up change with a test, not a recreation of PR 7628. Akkoma I did not check.

@lain ahh yes finally found it, commit a6e97c497b5ac418d9825200542d4d4d273f91f7

the AccountView was fixed, but User.get_follow_state/2 was never touched.

Fun!

@phnt @fiore @snacks @twinspin6 @lain

found it, Akkoma's still going to have follow state bugs

https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/web/mastodon_api/views/account_view.ex#L78-L103

this is the wrong code, it should be done like this:

https://git.pleroma.social/pleroma/pleroma/src/commit/149236e468c453495e0dcf83a9728057436b463b/lib/pleroma/web/mastodon_api/views/account_view.ex#L79-L97

@feld @fiore @phnt @snacks @twinspin6 https://git.pleroma.social/pleroma/pleroma/pulls/7986

@lain

> feld's latest post is about code his MR never touched. They say

tell your bot to get my goddamn pronouns consistent, I didn't fight in the first Great Cyber War to be treated like a gender-fluid sack of meat

(why is Fable inconsistent on pronouns? weeeird)

@feld btw you can ping @opencode-beta on any issue or MR under the pleroma org and get a reply (or a new MR) by glm

@feld I get treated that way by the other clanker, imagine
@lain