search

appdotnet / api-spec

App.net API Documentation is on the web at https://developers.app.net. Source for these docs is in the new-docs branch here. Please use the issue tracker and submit pull requests! Help us build the real-time social service where users and developers come first, not advertisers.
https://developers.app.net
950 stars 98 forks source link

Feature Request: Report Wrong Account Type Endpoint #351

Open duerig opened 11 years ago

duerig commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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/appdotnet/api-spec/issues/351#issuecomment-25817794 .

duerig commented 11 years ago

@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 commented 11 years ago

@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/appdotnet/api-spec/issues/351#issuecomment-25819290 .

duerig commented 11 years ago

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 commented 11 years ago

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.