Skip to content
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

Open
duerig opened this issue Oct 7, 2013 · 6 comments
Open

Feature Request: Report Wrong Account Type Endpoint #351

duerig opened this issue Oct 7, 2013 · 6 comments

Comments

@duerig
Copy link
Contributor

duerig commented Oct 7, 2013

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.

@larand
Copy link

larand commented Oct 7, 2013

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.

@kosso
Copy link
Contributor

kosso commented Oct 7, 2013

While I agree that distinguishing account types could be better - and done
earlier, but surely the thing with Pourover is that people can (and do)
connect their 'own' (human) account to the Pourover service which posts to
their account, along with their own manual posts. The same can be said for
IFTTT posts and twitterfeed, etc. sending posts (often) among their manual
'human' posts.

Hmm..

On 7 October 2013 16:24, larand notifications@github.com wrote:

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.


Reply to this email directly or view it on GitHubhttps://github.com//issues/351#issuecomment-25817794
.

@duerig
Copy link
Contributor Author

duerig commented Oct 7, 2013

@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.

@kosso
Copy link
Contributor

kosso commented Oct 7, 2013

@duerig True. But that client filter is only available in the Search and
Streaming API isn't it? (checks API docs) ;)

I've added a little marker in the next version of #PAN to show when a feed
is set as a 'feed'.
It also has a built-in client filter, which I did like to use a lot
(especially for the 'spammy' ones). Trouble is, that sometime those clients
can actually post some very interesting stuff. In fact, I'd go as far to
say that those feeds are often the most useful for me in global now.

Noisy accounts, with no relevance to me get instamuted. ;)

On 7 October 2013 16:40, Jonathon Duerig notifications@github.com wrote:

@kosso https://github.com/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.


Reply to this email directly or view it on GitHubhttps://github.com//issues/351#issuecomment-25819290
.

@duerig
Copy link
Contributor Author

duerig commented Oct 7, 2013

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.

@ghost
Copy link

ghost commented Oct 7, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants