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, [email protected] 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 [email protected] 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/[email protected]. 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:

Someone from Server B originates a thread. Someone from Server C sees it and comments on it. I assume people on Server A don’t see the post at all, even though there are comments from Server C people.

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.

Someone from Server A originates a thread. I assume people from Server B can see it and comment on it? That is, the blocking is only one-way?

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.

Someone from Server C originates a thread. Someone from Server B comments on it, and someone from Server C replies to that comment. What can people from Server A see?

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.