@a
>i think this is a consequence of the federation model and not the software per se -- nothing new here, it's all ancient history for irc.
It is a consequence of decentralized networks. You cannot blame the software for doing something the protocol it is using never guarded against, nor can it really guard against it properly. My point was that when a user from a centralized social media comes to Fedi, they expect it to work that same, ie. You cannot reply to a post that has replies disabled, you cannot ignore blocks etc. But that is simply not possible here. When you see Mastodon giving you an FO scope option, a user thinks that only the followers will be able to see, but the reality is simply not that, anybody can view the post if they know where to look at.
It's this creation of a false sense of safety that I don't like. I get that if you put a warning next to the FO scope, that it in certain cases it can leak to the public, it isn't a great look, but it's the reality. And you cannot hide from that. You are effectively gaslighting your own users by ignoring it.
>...similar, i guess? not exactly the same.
Last time I read the FEP, they were using the same thing as GTS I think. A Quote Activity instead of Create(Object(Note)) and QuoteApproval as the validation. Except that difference it works the same way, doesn't it?
>i don't think you talk about Block activities and how they shouldn't be federated but often are, but this problem already occurs.
No I don't talk about that, neither do I really know what the issue is. I guess that if you block someone, they learn about it? But that is the whole point of it when compared to mutes. On Xitter/Bluesky, if you block someone, they cannot view your posts, or reply. Mastodon does the post hiding, not sure about the reply. For that to work, you have to federate it. And of course if you block someone, you expect the possibly existing follow relationship to also be severed. For that to work, you also have to federate it. Another issue can be blockbots I guess. But I think that's the same issue, but in a different gift wrap. Instead of learning about the block by looking at someone's profile, you get a notification.
Muting simply hides the user for you and both have vastly different use cases at least for me.
>interactionPolicy
That is not the way I see it marketed. I don't see it marketed as a way to mute harassers, I see it marketed as a way to stop "replyguys" from talking to you, or attempt to stop harassment. Similar to how you can lock your threads on Twitter where only your followers can reply. I see it as a GTS attempt on that feature. That is what the first sentence in the "Danger" box means to me at least. If it was advertised as a mute, I wouldn't have much problems with it.
Speaking of Collections and reconstructing threads based on that, it could work for missing parts of a thread your instance does not know about, but you would also have to eliminate the usual way of federation for that. Another instance would still learn of an unwanted reply when it gets pushed to it. In that sense, it's not a good solution I think. What would work though is a simple "replies" Collection of approved replies to the parent. That would also eliminate the need for the dumb validation dance, since if you request the parent once after receiving a reply to it, without knowing about the parent, you would have the validation right there and included. Approval revocation would be federated the same way as other updates to a Collection get federated, namely the "featured" one.
>this is called a proxy
That is true, but proxy has a wide meaning. nginx is a proxy, squid is a proxy. That's why I gave it a name, although a kinda stupid one. To differentiate between the meaning of everything else.
>i think this is a consequence of the federation model and not the software per se -- nothing new here, it's all ancient history for irc.
It is a consequence of decentralized networks. You cannot blame the software for doing something the protocol it is using never guarded against, nor can it really guard against it properly. My point was that when a user from a centralized social media comes to Fedi, they expect it to work that same, ie. You cannot reply to a post that has replies disabled, you cannot ignore blocks etc. But that is simply not possible here. When you see Mastodon giving you an FO scope option, a user thinks that only the followers will be able to see, but the reality is simply not that, anybody can view the post if they know where to look at.
It's this creation of a false sense of safety that I don't like. I get that if you put a warning next to the FO scope, that it in certain cases it can leak to the public, it isn't a great look, but it's the reality. And you cannot hide from that. You are effectively gaslighting your own users by ignoring it.
>...similar, i guess? not exactly the same.
Last time I read the FEP, they were using the same thing as GTS I think. A Quote Activity instead of Create(Object(Note)) and QuoteApproval as the validation. Except that difference it works the same way, doesn't it?
>i don't think you talk about Block activities and how they shouldn't be federated but often are, but this problem already occurs.
No I don't talk about that, neither do I really know what the issue is. I guess that if you block someone, they learn about it? But that is the whole point of it when compared to mutes. On Xitter/Bluesky, if you block someone, they cannot view your posts, or reply. Mastodon does the post hiding, not sure about the reply. For that to work, you have to federate it. And of course if you block someone, you expect the possibly existing follow relationship to also be severed. For that to work, you also have to federate it. Another issue can be blockbots I guess. But I think that's the same issue, but in a different gift wrap. Instead of learning about the block by looking at someone's profile, you get a notification.
Muting simply hides the user for you and both have vastly different use cases at least for me.
>interactionPolicy
That is not the way I see it marketed. I don't see it marketed as a way to mute harassers, I see it marketed as a way to stop "replyguys" from talking to you, or attempt to stop harassment. Similar to how you can lock your threads on Twitter where only your followers can reply. I see it as a GTS attempt on that feature. That is what the first sentence in the "Danger" box means to me at least. If it was advertised as a mute, I wouldn't have much problems with it.
Speaking of Collections and reconstructing threads based on that, it could work for missing parts of a thread your instance does not know about, but you would also have to eliminate the usual way of federation for that. Another instance would still learn of an unwanted reply when it gets pushed to it. In that sense, it's not a good solution I think. What would work though is a simple "replies" Collection of approved replies to the parent. That would also eliminate the need for the dumb validation dance, since if you request the parent once after receiving a reply to it, without knowing about the parent, you would have the validation right there and included. Approval revocation would be federated the same way as other updates to a Collection get federated, namely the "featured" one.
>this is called a proxy
That is true, but proxy has a wide meaning. nginx is a proxy, squid is a proxy. That's why I gave it a name, although a kinda stupid one. To differentiate between the meaning of everything else.