Consider supporting post content other than "text"

[appdotnet]

Consider supporting post content other than "text"

[ricardobeat]

Isn't it bad to throw HTML around? This encourages API consumers to trust that the data is completely safe without filtering. One bad proxy can ruin it - this could become a vulnerable point for XSS attacks.

[markwilcox]

That's a good point but the "html" field is not part of my suggestion, it's already in the spec.

I'm not sure if the protocol field is really needed - if you've got to filter out protocols then we might as well just use some common hashtag and have it as a convention to filter that if you only want human readable stuff. I quite like the idea of using #! e.g.
#! /games/chess E-2 E-4

[CocoaPriest]

The keyword here is "Metadata". I think, it's a must-have feature – it would be reaaaaaly cool if we could ember some sort of meta-data objects and make it indexable.

[markwilcox]

Metadata is a very broad thing. What sorts of use cases do you want metadata for and could they be covered by:
https://github.com/appdotnet/api-spec/blob/master/objects.md#annotations (which are not yet really defined).

What sort of indexing do you want, currently no filters are defined for annotations either, but that would be a natural progression. Might be worth creating a new issue?

[CocoaPriest]

You're right, what I mean are annotations. Sorry, didn't see it before.
Simple use-case: an app posts a book review, has some annotations like { "ISBN":"73287328", "Rating":4}
The same app (or whatever client) makes a search for all posts with ISBN=73287328 && Rating > 3

[fields]

Binary payloads would go hand in hand with the idea that certain posts are only meant for certain (or certain groups of) applications.

[ryanschneider]

I'd really like to see private annotations like in #51. Your example of #! /games/chess works for "open" games like chess, but not for asynchornous games like Diplomacy or Apples To Apples, where each player commits to a move, but the moves aren't revealed until all players commit. Being able to add private annotatons that only certain groups/apps/users can see would allow this.

Maybe something like:

{
//...
"annotations": {
        // @user:key annotations are only visible by @user
        "@apples2apples:play-card" : {
            "id" : 1234
        },
        // #!app:key annotations are visible by app
        "#!diplomacy:move" : {
           "army" : "Gal -> Vie"
         },
        // un-prefixed namespaces are public
        "wellknown:geo": {
            "type": "Point",
            "coordinates": [102.0, .5]
        }
    }
//...
}

This would allow games and other apps with non-public information to use app.net as a platform.

[JoshBlake]

@ryanschneider Disagree, permissions on annotations is the wrong scope. It'd be better to simply have permissions on posts, like #33 is discussing, then your game client could sent a private message to the game bot or public comments to other players. I imagine most traditional asymmetrical game mechanics would be better off private messaging a game bot and the game bot rebroadcasting subsets of the message (commentary, or partial information states) to other game player clients.

[markwilcox]

I'm in complete agreement with @JoshBlake on this one. I'd thought about Diplomacy (and similar games) specifically as a use case and concluded it would be best to do them via game bots. Architecturally I think having private parts of a public post is going to get very messy very fast.

I like the concept of per user/group and per "post type" or "protocol" access control that is evolving in #33.

[ryanschneider]

Yup #33 seems to meet my needs as well. My key requirements are structured data (which annotations offer) and limited visibility, which 33 offers and I agree sounds easier to architect.

On Aug 14, 2012, at 6:57 AM, Mark Wilcox [email protected] wrote:

I'm in complete agreement with @JoshBlake on this one. I'd thought about Diplomacy (and similar games) specifically as a use case and concluded it would be best to do them via game bots. Architecturally I think having private parts of a public post is going to get very messy very fast.

I like the concept of per user/group and per "post type" or "protocol" access control that is evolving in #33.

�
Reply to this email directly or view it on GitHub.

[rrbrambley]

@fields I agree with the binary payloads concept. This would essentially create unlimited possibilities for the types of posts, and built on top of a solution that addresses #33, we have a hugely robust API that would enable apps to format data however they want.

[markwilcox]

@rrbrambley @fields JSON does't support binary payloads directly. They were very much included in my original thinking here but you have to base64 encode or similar on the client side.

[thingsinjars]

Is there any more movement around this? Particularly in relation to referenced issue #60 - headless peeps?

Non-text posts seem to be such an important step but the spec doesn't appear to have advanced much in that area in the last couple of weeks. Unless I've missed a discussion in another thread, of course.