Except ActivityPub data is by in large already not private, it is handed out to any tom dick and harry who run a server and have subscribed to actors on this one, and most of the time, it doesn’t even really require extra authorization. That is fundamentally how ActivityPub and federation work, but you can’t have any expectation of privacy in this system when it comes to the content shared. Expecting it to be private because it’s labeled is as dumb as expecting your website not to get scraped because you said so in robots.txt.
I didn’t say it was private, I said it wasn’t public, there’s a difference. If you asked me what number I was thinking of I’d tell you, but that’s not the same thing as the number I’m thinking of being public information. ActivityPub is, at its core, about consent. We have consented to having our data be sent to any person able to serve 200 responses on an inbox endpoint by using instances with open federation. We could, if that makes us uncomfortable, moved to a closed federation system where we only accept request from an allowlisted set of instances, with software that follows the spec’s public addressing system.
I think you’re misunderstanding just like the Mastodon users who think every tool should be opt-in. The consent piece IS moving to a closed system with whitelisted federation. If you’re giving data out publicly with no restrictions but trying to put stipulations on how it’s used, it’s the same as trying to enforce control through robots.txt, which is by the way a standard protocol.
So if you’re going to whine about votes being shown, you should be using a whitelist to block those actors from seeing it, and should be using authorized fetch to limit access to those whitelisted instances specifically, otherwise this is every stupid argument about “why robots.txt should be respected”.
The comparison doesn’t work because both Lemmy and Mbin are implementing the same standard, while robots.txt is mostly an honour system.
Information not being private isn’t the same thing as information being public.
Except ActivityPub data is by in large already not private, it is handed out to any tom dick and harry who run a server and have subscribed to actors on this one, and most of the time, it doesn’t even really require extra authorization. That is fundamentally how ActivityPub and federation work, but you can’t have any expectation of privacy in this system when it comes to the content shared. Expecting it to be private because it’s labeled is as dumb as expecting your website not to get scraped because you said so in robots.txt.
I didn’t say it was private, I said it wasn’t public, there’s a difference. If you asked me what number I was thinking of I’d tell you, but that’s not the same thing as the number I’m thinking of being public information. ActivityPub is, at its core, about consent. We have consented to having our data be sent to any person able to serve 200 responses on an inbox endpoint by using instances with open federation. We could, if that makes us uncomfortable, moved to a closed federation system where we only accept request from an allowlisted set of instances, with software that follows the spec’s public addressing system.
I think you’re misunderstanding just like the Mastodon users who think every tool should be opt-in. The consent piece IS moving to a closed system with whitelisted federation. If you’re giving data out publicly with no restrictions but trying to put stipulations on how it’s used, it’s the same as trying to enforce control through robots.txt, which is by the way a standard protocol.
So if you’re going to whine about votes being shown, you should be using a whitelist to block those actors from seeing it, and should be using authorized fetch to limit access to those whitelisted instances specifically, otherwise this is every stupid argument about “why robots.txt should be respected”.
I’m not sure that is a realistic expectation these days.