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.

Home Page:https://developers.app.net

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Feature Request: Report Wrong Account Type Endpoint

duerig opened this issue · comments

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.

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

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

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.