Notices tagged with atompub
-
#GNUsocial has supported both #ActivityStreams JSON and #AtomPub w/ AS XML extensions in the client API for years now; for example: https://loadaverage.org/api/statuses/home_timeline/andstatus.as https://loadaverage.org/api/statuses/home_timeline/andstatus.atom
-
@mcscx @gargron If I was constructing a new GS client, I'd target #AtomPub (with #OAuth) and ignore the #Twitter compatible API.
-
@gargron btw, apart from TwitterAPI !GNUsocial has another client connection method called #AtomPub http://qttr.at/1jgr
-
@gargron btw, apart from TwitterAPI !GNUsocial has another client connection method called #AtomPub http://qttr.at/1jgr
-
!gnusocial - I'm playing with #AtomPub a bit again, and am having a little trouble with this: in the JSON representation of a post, the local conversation ID is always easily found in the "statusnet_conversation_id" property; however, in the Atom representation, that information is sometimes absent. The <status_net> element only ever contains a "notice_id" property and no conversatio…
-
@taknamay @nbd @maiyannah If you use a client that posts with the #AtomPub protocol it can create whatever HTML it likes, and it'll just be filtered through #HTMLPurifier.
-
@navigium The #AtomPub input was actually filtered before, but a recent commit removed that accidentally (because I assumed it was "purified" before entering that function). That change has now been reverted. Also, it only affected the AtomPub API (afaik, but I'm reasonably sure :P) during that short period.
But yeah, all !gnusocial users are recommended to update (both master and nightly branches).
-
@laemeur Btw, if you have a neat library-ish thing for #AtomPub I'd love to know about it, regardless of language. I think that's the best way to implement rich formatted notices from clients rather than using plugins that just try to interpret plain text from the Twitter-based API.