Timeline
Post
Remote status
Fetching context…
This post replies to something we haven't fetched yet. We'll try to pull in the missing thread context in the background.
@a
>and they only do this for canQuote (no support for canReply, canLike, canAnnounce, whatever)
That makes mostly sense. Guarding who can Like and Announce is kinda dumb imo. Especially on a network that tries to be social. I understand why it exists, but I don't think the reason justifies its existence.
>it's why i think a block is better off as a local policy like a firewall, where you just drop incoming activities
It already is mostly that outside the Mastodon™ world. And I agree that it should be something like a firewall, mostly because you cannot dictate how others see their own view of the network. You can only do it on a best-effort basis and hope everybody abides by your rules, which creates these issues.
>right, the way it's being presented and "advertised" is the issue that prompted you to write the post i would surmise
There were two motivations. One was the signed fetch one, which I had in mind for over a year now, including the hidden fetching proxy. The second one was the GTS interaction policies, the discourse around Mastodon implementing it and how they basically disregarded most valid criticisms of how it works. I think that having an "approved Like/Announce/Reply" collection in your Objects would be much better than the current *Approval Activity dance and the dumb "result" -> "approvedBy" URI. When you don't know about the referenced Object, you simply fetch it and the correct approvals are already there. And if you know about it already and receive a new Activity referencing it, you refetch the Collection. Approval recovation would then simply be a "Remove" Activity like when you update pinned posts. I think that is much simpler than what GTS/Mastodon do.
>personally i keep thinking about the cwebber quote "we must not claim to prevent what we cannot prevent" -- the ideal language here is something that makes it clear it's just "observers will ignore you" instead of "your interaction will not exist"
Absolutely agreed.
>but this again goes back to people wanting to dumb it down for users expecting it to all work like centralized services
I don't think putting a warning somewhere above the compose text area after selecting a limited scope that says something like "Due to the nature of federated networks, it is possible that unintended users might see this post. For more information see <link>." looks that bad and it accurately represents reality. Or a simple modal when first blocking someone that says something similar about replies with a "never show again" checkbox.
Pleroma already gives you such a warning when you are composing an FO post with your account not set to approve followers first.
>and they only do this for canQuote (no support for canReply, canLike, canAnnounce, whatever)
That makes mostly sense. Guarding who can Like and Announce is kinda dumb imo. Especially on a network that tries to be social. I understand why it exists, but I don't think the reason justifies its existence.
>it's why i think a block is better off as a local policy like a firewall, where you just drop incoming activities
It already is mostly that outside the Mastodon™ world. And I agree that it should be something like a firewall, mostly because you cannot dictate how others see their own view of the network. You can only do it on a best-effort basis and hope everybody abides by your rules, which creates these issues.
>right, the way it's being presented and "advertised" is the issue that prompted you to write the post i would surmise
There were two motivations. One was the signed fetch one, which I had in mind for over a year now, including the hidden fetching proxy. The second one was the GTS interaction policies, the discourse around Mastodon implementing it and how they basically disregarded most valid criticisms of how it works. I think that having an "approved Like/Announce/Reply" collection in your Objects would be much better than the current *Approval Activity dance and the dumb "result" -> "approvedBy" URI. When you don't know about the referenced Object, you simply fetch it and the correct approvals are already there. And if you know about it already and receive a new Activity referencing it, you refetch the Collection. Approval recovation would then simply be a "Remove" Activity like when you update pinned posts. I think that is much simpler than what GTS/Mastodon do.
>personally i keep thinking about the cwebber quote "we must not claim to prevent what we cannot prevent" -- the ideal language here is something that makes it clear it's just "observers will ignore you" instead of "your interaction will not exist"
Absolutely agreed.
>but this again goes back to people wanting to dumb it down for users expecting it to all work like centralized services
I don't think putting a warning somewhere above the compose text area after selecting a limited scope that says something like "Due to the nature of federated networks, it is possible that unintended users might see this post. For more information see <link>." looks that bad and it accurately represents reality. Or a simple modal when first blocking someone that says something similar about replies with a "never show again" checkbox.
Pleroma already gives you such a warning when you are composing an FO post with your account not set to approve followers first.
Replies
0Fetching replies…