-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Report Wrong Account Type Endpoint #351
Comments
This is an issue that really needs to be addressed. There's not much point in having three different types of accounts if the proper designations aren't enforced and nobody is policing it, or providing a reporting method. |
While I agree that distinguishing account types could be better - and done Hmm.. On 7 October 2013 16:24, larand [email protected] wrote:
|
@kosso There are already ways to filter out posts made by particular clients (like PourOver and IFTTT) since posts are marked by client. The difference between 'human' and 'feed' is really whether I can expect a response/conversation if I reply to it. If a human includes some pourover posts, they are still likely to respond to me if I talk to them about those posts. A feed (from whatever client) will never respond. The difference is read/write vs. read-only in a sense. |
@duerig True. But that client filter is only available in the Search and I've added a little marker in the next version of #PAN to show when a feed Noisy accounts, with no relevance to me get instamuted. ;) On 7 October 2013 16:40, Jonathon Duerig [email protected] wrote:
|
There are not a lot of places to filter based on client id in the API. But that information is attached to every post so a client can filter it or display it differently regardless. This is currently not the case for account types because feed account do not mark themselves. This latter problem is what I am trying to rectify in this issue. Agreed that more server-side filtering options are useful no matter what. |
I just want to voice my support for this. I had no idea actually that accounts can be labeled in this manner, but I am delighted to know that they can be and that this can help de-clutter someone's feed, someone who wants to follow both feeds AND real humans without missing anything important from either group. This would tremendously improve the user experience for me and I know it would improve it for many other ADN users too. |
Problem
There are more and more feed account types using PourOver to auto-post RSS items. This in itself is a perfectly fine use of the service, but the ToS states that these accounts should mark themselves of type 'feed'. Almost all of them mark themselves as 'human'. This is probably partly due to ignorance and partly due to lack of incentives.
When an account is mislabeled, clients and apps cannot distinguish feeds from non-feeds for filtering or display to the user. And while this is a violation of the ToS, it is a different kind of violation than spam or harassment.
Solution
To this end, we need a different report endpoint to specifically call out an account for being mislabeled. This endpoint should not mute the account because I may still want to follow a feed even if it is mislabeled. And the endpoint does not attach to an individual post (for example, some accounts use PourOver, but also participate in conversations) but to the behavior of the account over many posts.
The endpoint might also provide an argument letting the user state what kind of an account they believe it should be marked as.
Benefits
If more accounts are properly labelled, clients will be able to split a user stream into feed and conversation items. Or mark them as different colors. Or allow filtering for just feed items or just human items.
The text was updated successfully, but these errors were encountered: