Future of the StatusNet API

Brainstorming points

• Things we may or may not want to do -- a discussion.
• autodiscovery of API base
  • <link rel="twiapi" link="/mublog/index.php/api">
  • Is anyone else doing this?
    • 0.9.x: Implemented per API discovery using RSD; should be compatible with WordPress's implementation
• versioning issues...
  • some other implementors are already providing multiple versions
  • but harder to maintain
  • and can make discovery harder?
• account creation via api from clients?
• realtime -> use Meteor/Orbited/etc?
• "lite" API methods?
  • drop junk that's not usually needed like profile background image url on friends timeline
  • smaller, faster api returns
• URL shortening fun...
  • make stats of targetted urls available, more analysis
  • built-in shortener (inside the firewall)
• some visible way to request firehose xmpp access
  • [will pubsub replace that?]
    • most likely yes, but we don't have firehose pubsub yet I think

API improvements

• Awesome API documentation (generated via Doxygen)
  • Integrated into rest of the machine-readable doc source
    • 0.9.x: this is starting: http://status.net/docs/api/
• OAuth for protected API resources
  • 0.9.x: implemented
• API versioning (version indicated in the URLs)
  • Different clients can use different versions of API
  • That way changes can be made without breaking existing clients
  • Evan's Concern: If we have global versioning, then a single addition of a parameter means we have to add another version of each other method
    • Decided to keep it Twitter compatible, which is global
    • Also, we already have extension that can check StatusNet version, we could do things like this anyway
      • For example: "Geolocation didn't exist before 0.9, so this one won't have it"
• Discovery
  • Would be excellent
    • 0.9.x: implemented RSD: API discovery
• rate limiting
• API resource(s) for autocomplete/type-ahead data
  • Third party clients can have access to all the info we have.
• API for administrative commands (create/delete users, suspend users, other admin functions)
  • Set up a new StatusNet instance via API?
  • Corporate installs possibly create users in batch?
  • Also, third party clients can have "Connect account, or create one"
• Suggestions API (suggest a user/group, etc., list existing suggestions)
• Resources for leader boards / stats
• Emulate the Twitter real time web API?
  • Could be done with Meteor / Comet
  • Can we do this with a layer on to of xmpp? (wait, that sounds crazy)
    • implement our own track? (call it "gillmor" instead of "track")
  • Needs more design
• Improve the search API
  • support operators -- booleans, from: to:, etc.
  • trends
    • Let people save searches
    • That way you can figure out what's the most popular searches.
• URL Search API
• API for conversations
  • Need whole conversation, and conversation from this point and all children
• Resource to request latest attachments from a user / group?
  • Ask for last X attachments from a user, could be used for PodCasting, etc.
• Twitter API very wordy, lots of hard to compute data
  • Most people don't care about most data
    • Don't need entire User Object every time
  • Could be value in making "Lite" methods
    • Cuts down on our bandwidth, processing
    • Makes API return faster, clients snappier
• As we go forward, add extensions, how to make changes ethical, works with other clients
  • Conversation ID for each Notice, some clients may not understand.
  • If doing versioning, StatusNet extensions could only be in StatusNet versions only
• Could add HTML into XML API outputs
  • Then clients don't need to parse it themselves
• RSS 1.0 has lots of great data, Twitter Compliant RSS2.0 one has less.
  • Could do a lot more with our own StatusNet one.
• Some ATOM could change with OMB 0.9, marked up with ActivityStreams, PuSH, Salmon, etc.
  • Need to decide if decorate Twitter API, or if have separate ones.
    • 0.9.x: implemented these extensions to Atom feeds for OStatus at existing Twitter API URLs
• Could be easy to use StatusNet as base for lite versions of other networks, like Last.fm
  • This would require other APIs
  • Doing this would require completely separate API, not a lot of reuse possible
• While talking about API, typically talk about Twitter API
  • We have other things, RSS 1.0, FOAF, Microformats stuff
  • Most devs aren't aware of that, but it could be useful to them
  • Should go in documentation
• Web Service Discovery
  • Probably not useful
  • Might be, though
• Might be useful to have a URL shortener inside
  • In this case, API required
  • Somewhat required for "Inside the Firewall" installs
• If a post is linked to with ShortURL, it is fetched to deshorten the URL.
  • This data could be made available to people
  • Could also be used to find who has authority, because we know who posted a link, who follows it, etc.
  • Pagerank for people with Twitter
    • Trim: Does something like this
  • One of reasons we don't do it is it's not our business
    • Someone else with StatusNet site could do that, if they wanted
  • Could be plugin for Stats gathering
• As much as we can get Devs to want to use our API for fun and cool things, the better.