Yeah, that’s along the lines of what I’m asking about, albeit instead of a subscription check more like, I think, however the instances disabling/removing downvoting have done so, but adjusting the scope strictly to the Local or All views.
Another approach to addressing outsider/passive voting behaviors.
I don’t think that would be possible. The API is only sending “post_id” and “score” for votes, so the backend has no info on what feed a user used to send it. An instance could modify their official frontend to hide the ability to downvote from Local and All but they couldn’t do anything about people using different frontends (e.g. all the various phone apps)
Interesting, thanks! It sounds like you could hide the ability to vote either way then on an instance’s frontend, but as you say, it wouldn’t really do much to address voting activity from either other frontends or instances.
Yeah, that’s along the lines of what I’m asking about, albeit instead of a subscription check more like, I think, however the instances disabling/removing downvoting have done so, but adjusting the scope strictly to the Local or All views.
Another approach to addressing outsider/passive voting behaviors.
I don’t think that would be possible. The API is only sending “post_id” and “score” for votes, so the backend has no info on what feed a user used to send it. An instance could modify their official frontend to hide the ability to downvote from Local and All but they couldn’t do anything about people using different frontends (e.g. all the various phone apps)
Interesting, thanks! It sounds like you could hide the ability to vote either way then on an instance’s frontend, but as you say, it wouldn’t really do much to address voting activity from either other frontends or instances.