Other people in that thread have pointed out that it isn’t showing posts being delivered to Threads despite the block. That should be testable with other instances, but not Threads since it’s not receiving any content from Mastodon at the moment. The concerning thing there is the user still being able to view content from people they’ve blocked, but that seems to be a bug if it’s reproducible.
In the EU companies can’t scrape personally identifiable information without consent, even if it’s already publicly available. IANAL, and there’s probably ways they can sneak around the GDPR, but at least it’s not a free for all. It’s unclear though how it works for federation. It’s definitely not the same legally though.
The reason for not directly federating content to Threads isn’t so nobody there can ever see my amazing posts, it’s so Meta can’t easily profile me. Scraping public posts on a different platform would probably be illegal, at least in the EU, and reposts don’t give them a lot of data about me. Federating content, however, would give them most of the same data that Mastodon has on me without even having to ask.
This post from Eugen Rochko mentions that blocking Threads at the user level “stops your posts from being delivered to or fetched by Threads”. Basically, the user-level instance block is bidirectional.
Limited federation mode is a different feature, at the admin level. It doesn’t really affect the delivery of posts in either direction, it just hides the blocked instance’s content from the global feed. Defederation on the other hand is indeed bidirectional, but again it’s on the admin level rather than users’.
Mastodon instance blocks are already bidirectional AFAIK: if you block an instance your content does not get federated with them. I was actually surprised that this does not seem to be the case for Lemmy. I don’t think this break any core abstraction of AP…
Ah ok this I’m not sure about. I mean, Lemmy added instance blocks as well in the latest release (0.19), but it seems that, unlike Mastodon, this only hides the content from you and doesn’t prevent your content from being sent to that instance. It does seem like a pretty big oversight, but I haven’t found a discussion about this. There might be good reasons why it’s this way.
I don’t think Lemmy does either…? It pushes updates to subs that at least someone on the receiving instance subscribes to (at least that’s how it worked last time I checked). That’s why there are scripts going around for new instances to automatically follow a bunch of popular subs to populate the All feed.
I think Mastodon works in the same way with users, where it sends updates for accounts that someone on the receiving end follows. So if nobody follows you from Threads it wouldn’t send any of your posts there.
ActivityPub doesn’t just push everything on a server to every federated instance like a fire hose. In the first place, as [email protected] said, it only feeds your content to an instance if somebody on that instance follows you, which you can set to require your manual approval. Your posts could also get pushed if somebody else boosts your post and they have followers on the other instance.
However, if you set an instance block, none of your posts get sent to the instance, period. They would have to resort to scraping. In other words, if you don’t want to give meta your data, just set an instance/domain block.
Oh yeah, you’re right on that. If I’m looking for privacy from the subscription manager signing up with a service like this is a terrible choice, because it is fully a financial institution.
I wish they were all on the same day of the month…
Dates aren’t a big concern though. What I was hoping for is something that would update automatically to some extent if (say) some amounts change, or a payment is missed. But I guess indeed that’s basically impossible without access to my payment data.
Given that I have to update it manually though, I would at least like it to be synced remotely. So that I can, say, check it from my laptop on a webpage or desktop app without redoing all the manual data input.
For my use case yes, that would defeat the purpose, but for what it’s trying to do it kinda makes sense… At least, they have to do it to comply with payment regulations. And you’re still only exposing your identity to one service with a decent reputation, rather than plenty of possibly shadier ones. It seems like a fair tradeoff if what you’re looking for is privacy from services you want to pay for.
I guess you’re right, yeah. I was hoping someone had figured out a different solution, perhaps integrating directly with the individual subscription providers. But I guess that’s way too broad of a scope, integrating with countless individual services.
At least a cross-platform, cloud backed “spreadsheet” would be nice to have though.