I'm interested in hearing from #ActivityPub developers who've successfully mapped #OpenGraph properties from <meta> tags in Web pages onto the Page type and its properties in AS2.
Overall, mapping to ActivityStreams was pretty easy. Sherlock is the key component in #Emissary that helps it participate in many different social webs.
The intent was to extend the #ActivityStream JSON-LD vocabulary to add a business layer, like GraphQL. Both text and image are the returned content. The app value comes from generating an image from GET parameters. The parameters convert to an SQL query to obtain an image for the user.
I wanted to use the Actor Type of Service, rather than Person. The spec says Service is treated as a bot.
The #fediverse exists as the antithesis to centralised networks. Which is why, IMHO, it is absolutely not needed to welcome #Meta#facebook. Fox, henhouse and stuff. If they want to implement some sort of gateway using #activitypub — let them build it. But we are under no obligation to help them. Or discuss with them under NDA. Simple. They are not friends or allies. They will extend, embrace, extinguish what we have under the disguise of cooperation should you help them.
@jwildeboer Just my "+1". One thing I have learned actually from you (thank you!) is that open formats and protocols are actually more important than open source. If #Meta, #Google, #Microsoft, or anybody else want to create proprietary project working 100% with #ActivityPub and #ActivityStream, it is The Good Thing™ (of course, Embrace, Extend, and Extinguish is always an option, after all, that’s how Google killed #XMPP ).
What am I reading for some nice light late night reading? Why, it is the #ActivityPub spec! And #ActivityStream! And #ActivityVocabulary! I want an ActivityPub project to work on. Starting here:
In den letzten Tagen hat Facebook einige so spannende Ankündigungen gemacht, dass ich sogar kurz mal meinen Umzugsstress unterbrechen und darüber bloggen muss 🙂
Die Facebook Open Stream API
Die erste Ankündigung betrifft Facebooks der spätestens seit dem letzten Redesign das zentrale Feature von Facebook geworden zu sein scheint. Mit der Open Stream API führt Facebook diese Strategie fort und öffnet die Aktivitäten auch für externe Applikationen und Services. Besonders lobenswert ist, dass Facebook neben einer proprietären API (zum lesen und schreiben) auch einen Atom-Feed+Activity Extension1 zum weiterverarbeiten des Activity Streams anbietet. Leider ist aber auch der Atom-Feed über den Facebook-Authentifizierungsprozess geschützt und kann dadurch nicht ohne weiteres mit z.B. einem Feedreader abonniert werden.
Dass Facebook die proprietäre Open Stream API entwickelt, statt die OpenSocial RESTFul API einzusetzen ist leider zu verstehen, immerhin ist OpenSocial als Googles Antwort auf die Facebook-Apps entstanden. Schade!
OpenID Login
Als Facebook letztes Jahr der OpenID-Foundation beigetreten ist, um sie speziell in Sachen Usability/User Experience zu unterstützt, hatte ich natürlich große Hoffnung, dass Facebook in naher Zukunft auch selbst auf OpenID umstellen würde. Seit Montag ist jetzt klar, dass Facebook an einem OpenID-Login arbeitet, der hoffentlich auch irgendwann ein fester Bestandteil von Facebook-Connect wird.
Aber Facebook wäre nicht Facebook, wenn sie einfach nur einen klassischen OpenID-Login umsetzen würden. Wie Carsten Pötter auf SpreadOpenID beschreibt, plant Facebook eine Art OpenID-Auto-Discovery:
Facebook will automatically check to see if users have logged into any OpenID account when they hit Facebook.com, and give them the option to automatically login to Facebook without entering new information.
Leider ist dieses Feature, wohl nicht global für alle OpenID-Provider und definitiv nicht ohne Directed Identity möglich… aber man wird sehen (vielleicht spinn ich hier im Blog demnächst mal ein paar Szenarien (Worst-Cases) durch).