this post was submitted on 15 Jun 2023
41 points (100.0% liked)
/kbin meta
16 readers
2 users here now
Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign
founded 1 year ago
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
So when beehaw says they're degenerating from
sh.itjust.worksandlemmy.world, the way that works is that any content from those specific servers will not be ingested into beehaw's view of the fediverse. That includes content and comments. It's identical to how if a Mastodon instance setup for LGBTQ communities and a Mastodon instance set up for far right extremists decided to defederate from each other, they would just never see any content that originated from each other's servers. Sincekbin.socialis notsh.itjust.worksorlemmy.world, we should be fine in sharing back and forth with those communities, and becausekbin.socialhasn't defederated from those servers, content will flow back and forth between them fine. beehaw users should be able to see content fromkbin.socialminus any contributions from the defederated servers.It's a very powerful tool in toolbox for the Fediverse, and one that absolutely brings an eye to the moderation of servers when it's used. I think it's a bit of a bigger deal in this part of the Fediverse right now because there aren't a ton of options yet for federated link aggregators; it's pretty trivial now to move to a different Mastodon server if you disagree with the instances being defederated from the one you're on. That said, it's very much a "with great power comes great responsibility" thing; I think that it's fantastic that servers are able to engage or disengage with whomever they want. Most will get along just fine and it's not really an issue.
I also think that as part of a "community taking back the internet from billionaires" movement, defederation is one of our most powerful tools. If Meta comes into the scene and starts scraping the Fediverse and building marketing profiles and training their AI chatbots on our data, it'll take about 3 minutes until people are maintaining a blocklist on git* for all server administrators to simply block Meta from accessing the majority of the Fediverse. There is a challenge in deciding what the scope of "generally acceptable behaviour" is, but we did it before centralized social media and we can do it again. If anything, I think some of the challenges of the last 10-20 years was this idea that diametrically opposed communities should occupy the same "space" on the internet. Get a big general pool, and give flexibility for communities to push in a direction they want if they want to go outside that space.
Some of these things will iron themselves out as more instances of lemmy or kbin or whatever decides to interoperate with these two spin up. In the end, I think these are tools that allow us to develop healthier communities. In the long game, it won't matter for any one server if they can't access beehaw because good content will be distributed amongst a ton of servers. And if the people from
lemmy.worldorsh.itjust.worksreally want that beehaw content, then they can work to address some of the issues that beehaw feels are worth defederating them for!This is confusing to me as well.
Where I still struggle is in the details of defederation for a service like kbin because it's more interactive than Mastodon. Here are some examples that confuse me.
For these, let's assume we have Servers A, B, and C. Server A has defederated from (i.e. blocked) Server B, but otherwise they are all connected to each other.
Anyone who can shed light on this will be greatly appreciated. :-)
The fediverse has, generally, done a very poor job of explaining itself and how it works. There's a huge disconnect between most peoples' mental model of the space, and what actually happens.
During the Twitter migration, the mental model that people seemed to have was that of a mainfarme. That is, that "Mastodon" lived in one specific place, and that everyone was just "logging on" to it via portal, or dumb terminal.
Here, people seem to be better understanding that things live on multiple different websites -- in big part, I think, due to remote community/mamgazine names having the full address shown in the sidebars (Mastodon's UI goes to some lengths to hide when people are on other instances). But how it ends up looking is that you are viewing remote websites through your local instance, kind of as if your local instance is a Fediverse web browser. In this sense, viewing, say, politics@lemmy.ml is the equivalent of browsing to a separate website and viewing or interacting with that content directly.
This is not what happens, though.
Really, that's not what happens with Firefox or Chrome, either. When using a web browser, you request content from a remote computer (the web server), that content gets downloaded and stored on your local hard drive as your browser cache, and then you view the local copy of of that page. If the website is dynamic in some sense, updates from that website get repeatedly pushed to your computer.
This is also how federation works here.
When you view politics@lemmy.ml from, say, lemmy.world, or kbin.social, if you pay special attention to the address bar, you'll notice you're actually viewing kbin.social/m/politics@lemmy.ml. That's a magazine hosted locally on kbin.social. All of the posts and comments you see there are stored locally on kbin.social; when you engage with them, you're merely engaging with a local copy. These copies remain synchronized with other sites by passing messages back and forth.
Defederation is just refusing to accept messages from, or send messages to, a certain website.
With this in mind:
This is likely correct, yes. Server C will likely send a message to Server A with the comment, but Server A will not have the post in order to properly assign it, so it will probably just get dropped.
No. Server A is not sending messages to Server B, so Server B does not get the post, and the copy of the community that is mirrored on Server B will never be updated with that post.
Server A will receive the messages send by Server C, so the original post, and the comment originating on Server C. It will have blocked the comment from Server B, though, so it will not know what to do with the comment from Server C. The comment from Server C will include metadata that tells Server A that it's a reply to a comment that Server A doesn't have a record of. So, in all likelihood, the comment will get dropped on Server A.
Thank you!!! This is exactly what I needed. I really appreciate the thoughtful and thorough reply.
Don't mention it. It all clicked for me when I set up a Calckey instance and explored the database. It really hammered home that everything in this space is local. Remote users have entires in the user table. Rmeitr posts are stored right along side those originating elsewhere. Everything I looked at, everyone I spoke to, it was all there.
And with that, the entire project snapped into focus, and all of the weird quirks of the space made perfect sense.
Everything is local. Anything that looks otherwise is an illusion.