We’re aware of the pact and will cross that bridge when (or if) it ever really happens. We’re certainly no fans of Meta (or Reddit,or Twitter). So far it seems more likely to affect Mastodon than Lemmy/Kbin.
The “user data” (comments, posts, votes, etc) that would be available to a hypothetical instance owned my Meta is already public for anyone, so not much we have control over there. “Defederating” essentially just means “blanket banning” a bunch of users at once.
Agreed that it’s public now - in the case of up/downvoting publication is instance-dependent — and can be scraped, but as a federated instance Meta can just load it directly.
@StillPaisleyCat Federating only happens through user interactions unless you have agreements between instance hosts IIRC. Not there wouldn’t possibly be a huge amount of Threads users following Mastodon accounts which would then push the Mastodon user’s profile/posts into a federated or “global” feed in Threads. Federation in itself isn’t an all you can eat pass to Fediverse data. Defederation would stop the above example of data sharing though.
@StillPaisleyCat TBH with Threads only having an algorithmic feed I have serious doubts they’ll ever be able to truly “Federate” in any meaningful way beyond being able to tick a checkbox for ActivityPub integration. They aren’t going to want me using a Mastodon client to be able to read their chronological feed and not be served ads.
True, but if Meta (or anyone) wanted to “directly” get that data, it would be as trivial as setting up an instance on something as small as a Raspberry Pi and subscribing to a community here. We would have no way of knowing who it is or stopping them. Defederation is a tool to prevent brigading, not lurking.
If (if) Meta wanted to set a lemmy-style platform, preemptively defederating from it would be a largely symbolic gesture. Doesn’t mean it’s not worth doing, like I said we’ll cross that bridge if and when it becomes relevant.