e569668

joined 1 year ago
[–] [email protected] 1 points 8 months ago

As an update, this should be fixed now https://github.com/MbinOrg/mbin/pull/81 and looks to have been rolled out to this instance. The issue can still happen on user covers and magazine inline icons, which I hope to have a PR for soon(tm). realized it happens basically anywhere images with alt text appear so going to take more time auditing everything

[–] [email protected] 2 points 8 months ago* (last edited 8 months ago)

Minor problem: there's a new feature of 2fa, but at least for me, going to https://fedia.io/settings/2fa to set it up shows a broken qr code. looks like it's returning an nginx 404 at the moment

[–] [email protected] 2 points 8 months ago* (last edited 8 months ago) (1 children)

It looks like their instance is having some issues https://programming.dev/post/4308156 granted that says outbound but I just joined their matrix and there are other issues being discussed as well, I might wait on this to see if it's still happening once things get more sorted

edit: i posted in their matrix support channel to see if they noticed anything odd as well 🤞

[–] [email protected] 2 points 8 months ago (2 children)

That is very weird, their /instances page says kbin still... I wonder if they stopped federating / it got marked as an inactive instance by mistake? lemmy.world for instance shows fedia as mbin... I'm not quite sure what this means but they clearly haven't gotten node info in a while

[–] [email protected] 2 points 8 months ago* (last edited 8 months ago) (3 children)

this might be https://github.com/MbinOrg/mbin/issues/35

it was fixed in the docs but requires manual change by instance owners that were affected, which this instance appears to be. tl;dr the docs recommended the nginx config add_header Referrer-Policy "no-referrer" always; which broke the style of redirects that were being used, it's now been changed to recommend add_header Referrer-Policy "same-origin" always;

more info here

edit: I promise I can read... Your description is slightly different, so it might not be this, but still worth trying it out to see if it helps

[–] [email protected] 2 points 8 months ago (2 children)

Both servers are larger than the single server that infosec.pub runs on, yet infosec.pub has about 10x the traffic, and kbin is struggling under the load.

I wonder what the difference is. One thing I have always wondered is if the double comment / post issue is causing tons of double traffic, not to mention double storage / bandwidth / network costs. I really wish there was an easy solution but I haven't been able to find any answers. The random thing I thought was like, it looks like everything federates with both fedia.io and www.fedia.io, so I was like maybe everything is double sending on its side? (E.G. if you look at lemmy.world or lemm.ee etc they all list fedia twice.) But people didn't seem that was likely to be the cause, as hopefully everything is deduped by signing keys rather than hostnames. I don't know enough to investigate further myself.

[–] [email protected] 4 points 8 months ago

I don't know of every instance of course, but from the general purpose ones the order of up-to-date from most to least at the time of posting would be something like: kbin.run, fedia.io, kbin.cafe, artemis.camp (specific API branch), kbin.social.

But there's also other considerations. fedia has a double post/comment issue and a low amount of 500s. Artemis has been giving me a lot of 500s, can't upvote anymore (just reloads the page), commenting doesn't always federate. Many instance admins seem to have disappeared since 3 months ago. I'm not sure what life is like on instances I'm not actively using so there might be issues unknown to me.

Edit: the keys that I look for are localization / ui changes. "more" dropdown now has "more from domain" on updated instances. The UI for the sidebar is different, and most recently the footer is differently styled. There's also the federation list of instances page in the footer now.

[–] [email protected] 1 points 9 months ago

Yeah, Mastodon has separate block and mute functions.

Ah, good to know. I'll have to look into it a bit more, but reading https://docs.joinmastodon.org/user/moderating/#block

If you and the blocked user are on the same server, the blocked user will not be able to view your posts on your profile while logged in.

It looks like the limitation that Pamasich and I sort of expected is there. Blocks are basically only possible at your own instance. If the user is on another instance, there's no way to stop them in the fediverse. And that includes it going out to all other instances they federate with too.

I sort of just experienced how this would work if implemented, in a way. A kbin social user posted to a beehaw org magazine. I replied to it, but my post does not seem to have made it to kbin social. However, it's on my instance, beehaw's, lemmy one, etc, because my instance federates with all of those instances. That's sort of what blocking would be like if the original page refused an incoming comment due to a block, all other instances would still accept it. It's possible there's something I'm missing as I'm not super knowledgable on activity pub or the fediverse, so I'll try to learn more about it

[–] [email protected] 1 points 9 months ago

does the fediverse actually support the kind of block that's being asked for here?

Yea, that's where I'm thinking the hangup on this might be. A block could be implemented, but it'd come with the caveat of that all it's doing is giving you the idea they aren't continuing to engage with you on your instance. On their instance, and any instance that federates with them, they and others will continue to see the replies.

Personally, I would like to see block renamed to mute to be more accurate and a block from replying added with the note about the drawbacks of them being able to tell you blocked them and their posts still going out everywhere else. That at least empowers the user to make the decision themselves on what they're most ok with. My reasoning is: changing the UI for, let's say an aggressor, gives them a reason to retaliate. To me, either blocking method is a lose-lose; either it doesn't stop engagement which some users clearly want it to, or it makes it obvious someone is being blocked which start aggressors down the retaliation path. That's kind of why I'd want users to make their own risk assessment on actions.

Anyways, that's all very unlikely to happen. Most of all I'd like the bug about notifications fixed because that is clearly not working as intended.

[–] [email protected] 3 points 9 months ago (2 children)

I posted in https://kbin.social/m/kbinMeta/t/509976 as well but just to make sure you see it, ernest was pinged so hopefully this will be fixed when he sees it

[–] [email protected] 2 points 9 months ago (1 children)

The good news is this was fixed in latest https://codeberg.org/Kbin/kbin-core/issues/1019 the bad news is it hasn't made it to kbin.social yet so hopefully whenever this instance is updated it will be fixed

[–] [email protected] 3 points 9 months ago

Peeps pinged ernest in matrix so hopefully he can take care of this when he gets the chance. Thanks (to squiblet as well) for bringing it up!

view more: next ›