Go all-in on annotations

[beccadax]

This is not really a serious proposal so much as a pie-in-the-sky suggestion that could give us an idea for a serious proposal.

I think that the machine_only parameter is a step in the wrong direction. It's a mistake to think of some posts as being for human consumption and others as being for machine consumption. It's better to think of your App.net stream as a mix of different post types, and clients should show whatever subset of those post types they understand. A chess post is for human consumption, but only through a client that understands chess.

Therefore, I (modestly) propose two changes:

• Deprecate text, entities, and html, and move them into a new net.app.core.alpha annotation.
• Deprecate the machine_only parameter, and replace it with a posts_with_annotations parameter. posts_with_annotations takes a list of annotation types (perhaps comma separated). In order to appear in the response, the post must contain at least one of the annotation types listed in the request.

Alpha clients should specify posts_with_annotations=net.app.core.alpha; chess clients should provide posts_with_annotations=games.chess; Alpha clients for chess enthusiasts that also show chess moves should provide posts_with_annotations=net.app.core.alpha,games.chess.

Note that posts_with_annotations does not specify that other annotation types should be omitted from posts. If a post has net.app.core.crosspost and net.app.core.alpha, an Alpha client should still receive the net.app.core.crosspost annotation, because it might use that information even though it doesn't want all crossposted posts. In SQL terms, it's a WHERE clause, not a SELECT clause. It controls which posts are included in the response, not which annotations are included in the posts.

[neuroscr]

Sounds like how the Channels are set up in a way, each having a type.

Also when we have user side filtering, then we'll hopefully be able to filter posts by annotation types