Stop exposing if a user blocks you over the API. #553

Merged
floatingghost merged 1 commit from XxXCertifiedForkliftDriverXxX/akkoma:feature/hide-blocked_by into develop 2023-05-28 22:02:33 +00:00

Hi there,

As a certified forklift driver, I believe that it is important to remove any information about which user blocks another from the API.
This information serves no practical or safety-related purpose for me as a forklift driver, and it has the potential to cause unnecessary tension or conflict among users.

I suggest that we remove this information from the API altogether, in order to promote a safer and more harmonious fediverse environment. Thank you for considering my input.

Best regards, Certified Forklift Driver

(Fixes #552)

Hi there, As a certified forklift driver, I believe that it is important to remove any information about which user blocks another from the API. This information serves no practical or safety-related purpose for me as a forklift driver, and it has the potential to cause unnecessary tension or conflict among users. I suggest that we remove this information from the API altogether, in order to promote a safer and more harmonious fediverse environment. Thank you for considering my input. Best regards, Certified Forklift Driver (Fixes #552)
XxXCertifiedForkliftDriverXxX added 1 commit 2023-05-28 22:00:03 +00:00
Stop exposing if a user blocks you over the API.
Some checks are pending
ci/woodpecker/pr/woodpecker Pipeline is pending
1b560d547a

thanks forklift-driver-sama

given how poorly visibility seems to have been received, I'll accept this as-is

thanks, saved me a bit of work tomorrow~

thanks forklift-driver-sama given how poorly visibility seems to have been received, I'll accept this as-is thanks, saved me a bit of work tomorrow~
floatingghost merged commit fb8081e1a3 into develop 2023-05-28 22:02:33 +00:00
floatingghost deleted branch feature/hide-blocked_by 2023-05-28 22:02:34 +00:00
First-time contributor

Can stuff like this not be up to admins?

There's the option to not federate blocks already in admin-fe if someone receives harassment and now you're stripping a feature that even Mastodon has just because one instance (snowdin) requested it when so many others might enjoy this feature to not reply to people who block them

This kind of decision forces admins to have to strip commits when updating and that's not how development should be handled

Can stuff like this not be up to admins? There's the option to not federate blocks already in admin-fe if someone receives harassment and now you're stripping a feature that even Mastodon has just because one instance (snowdin) requested it when so many others might enjoy this feature to not reply to people who block them This kind of decision forces admins to have to strip commits when updating and that's not how development should be handled
Author
Contributor

Can stuff like this not be up to admins?

There's the option to not federate blocks already in admin-fe if someone receives harassment and now you're stripping a feature that even Mastodon has just because one instance (snowdin) requested it when so many others might enjoy this feature to not reply to people who block them

This kind of decision forces admins to have to strip commits when updating and that's not how development should be handled

As a certified forklift driver, I understand your disappointment. However, it seems like the requested feature is not feasible due to toxicity issues. No one wants it back. Please keep in mind that this is a community project made for friends, and pleasing everyone is not a goal of the project. If you still want it, feel free to maintain your own fork or consider using a different solution.

As someone who has undergone forklift operator certification, I would like to share my thoughts on this topic. Showing users who block them can be considered toxic behavior, and it can lead to unnecessary conflicts and negativity on the platform. To solve the issue of users replying to them unknowingly of the block, I would suggest that they should just be hidden from the user instead.

This approach can help to avoid unnecessary drama and misunderstandings, while also ensuring that users feel safer and more protected while using the platform. By taking a proactive approach to this issue, we can create a more positive and supportive environment for all users, and help to build a stronger and more cohesive community.

Keep up the good work on the project!

> Can stuff like this not be up to admins? > > There's the option to not federate blocks already in admin-fe if someone receives harassment and now you're stripping a feature that even Mastodon has just because one instance (snowdin) requested it when so many others might enjoy this feature to not reply to people who block them > > This kind of decision forces admins to have to strip commits when updating and that's not how development should be handled As a certified forklift driver, I understand your disappointment. However, it seems like the requested feature is not feasible due to toxicity issues. No one wants it back. Please keep in mind that this is a community project made for friends, and pleasing everyone is not a goal of the project. If you still want it, feel free to maintain your own fork or consider using a different solution. As someone who has undergone forklift operator certification, I would like to share my thoughts on this topic. Showing users who block them can be considered toxic behavior, and it can lead to unnecessary conflicts and negativity on the platform. To solve the issue of users replying to them unknowingly of the block, I would suggest that they should just be hidden from the user instead. This approach can help to avoid unnecessary drama and misunderstandings, while also ensuring that users feel safer and more protected while using the platform. By taking a proactive approach to this issue, we can create a more positive and supportive environment for all users, and help to build a stronger and more cohesive community. Keep up the good work on the project!
Sign in to join this conversation.
No description provided.