Conversation

Notices

1. AndStatus (andstatus@loadaverage.org)'s status on Sunday, 30-Oct-2016 20:42:48 UTC AndStatus

   • Juanjo Faico
   • Annah's got the Shotgun
   • Constance Variable
   @maiyannah@community.highlandarrow.com I think GNU Social SHOULD change its client API to allow fully use advantages of its federation. Please read this discussion on a new API: https://github.com/andstatus/andstatus/issues/419
   @lambadalambda
   • @mcscx@quitter.se (mcscx@quitter.se)'s status on Sunday, 30-Oct-2016 21:41:23 UTC @mcscx@quitter.se

     in reply to

     • GNU social
     • Eugen 💀
     @gargron btw, apart from TwitterAPI !GNUsocial has another client connection method called #AtomPub http://qttr.at/1jgr
     Joaquim Bernà i Torres repeated this.
   • AndStatus (andstatus@loadaverage.org)'s status on Monday, 31-Oct-2016 15:30:04 UTC AndStatus

     • Juanjo Faico
     • MMN-o ✅⃠
     • @mcscx@quitter.se
     • Annah's got the Shotgun
     • Constance Variable
     • Eugen 💀
     • Penny For The Guy
     @maiyannah I think it would be overkill for us to invent some completely new API. From this position I see two main ways of current API improvement, and we can go both ways, implementing them separately:
     1. Improvement of "Twitter” compatible API. The change that I propose is easily described and it may seem not that deep, but for some reason even @gargron, who, as I thought, is building a new API now, took a long pause on it:
     in ALL API calls get rid of ALL "local IDs" (IDs of people, messages etc...), replacing them with URIs, which are the same for the same identifiable things (i.e. for the same objects) in all GNU Social instances. This requirement is easy to implement, if an URI:
     1.1. Contains unique hostname of the GNU Social instance.
     1.2. Contains type of the identifiable object,
     e.g. ”acct:andstatus@loadaverage.org” - for an "account" ("person"), like in Pump.io.
     The hard part of this change is that it requires changes in request parameters and (or) in data returned of all API calls. I mean we should go through all API calls and replace all local IDs with URIs, which I suspect not always exist in GNU Social for some objects...
     2. Complete and document an API, based on Activity Streams and JSON format. As @mmn wrote me, Activity Streams + JSON are already implemented in GNU Social. But absence of documentation and working examples is a blocker here. This could be the second step of changes...
     @lambadalambda @pennyfortheguy @mcscx