As mentioned in Blog Post URIs, I'm a bit concerned about people replying to the 'wrong' URI for a post. That is, using the URL of a HTML page with the post rendered within it, rather than the post's permalink. I couldn't find a Microformats2 term for permalink, which I thought would be the obvious solution. The webmention 'protocol' says that when I recieve a webmention: Check the target is a valid URI on my site after following redirects. In my case, upon recieving a target of a https://rhiaro.co.uk/yyyy/mm/id, to validate it, rather than 'following a redirect' I'll actually be getting it's foaf:topic from the triplestore, which is fine. But in accepting this as the target I'm confirming to the sender that this is the correct URI to reply to. Hypothetically this non-permalink could break, breaking the reply. The permalink URI is one I'm promising won't break, so it's in everybody's interests to send the reply there. But logically, if somebody is linking to me in a post of their own, they're going to want to link to the rendered version, rather than whatever my raw version will look like (probably crappy, but that's on me, and maybe part of the problem). Replying to shortlinks Because I'm a linked data nut, my problem derives from a deliberate differentiation between a blog post and a page about a blog post. The connection between them (or from one to the other) can be discovered through RDF, but there is no HTTP redirection. I suspect this is a very much minority use-case for #indieweb folks. However, use of shortlinks is widespread (and you can see redirects are accounted for in the webmention protocol), and so as soon as someone's URL shortner breaks (or moves) permanently, unless they store the post contents and metadata themselves, they might have to have to think about this a bit. Solution? I'd like to be able to send back the correct URI (303 redirect style) so the sender can either: try again with the correct URI, or update their system with the correct URI, knowing I've accepted the webmention against the correct URI on my end (more like a (2NN)[http://tools.ietf.org/html/draft-prudhommeaux-http-status-2nn-00] than a 303). I haven't looked at any implementations yet or thought about how to do it, so maybe I can just do this. I'm not sure how to anticpate people handling it. Straw poll: What do you/your system do if you send a webmention and it's rejected, though you're sure the target is valid? And if you're going to send your reply as a webmention from your own system, please target this post's permalink - the URI without a year and a month in :)
# Webmention receipt and display This weekend at IndieWebCamp in Brighton, my main goal is to display received [webmentions](http://indiewebcamp.com/webmention) on my posts. Currently I collect them at [webmention.io](http://webmention.io) and will occasionally manually add them to my store when there's a reply I'd particularly like displayed. This is just displayed as a link at the bottom of the post. Initially I thought about just running a cron job to pull from webmention.io into my store. Since webmention.io does all the validating etc, this takes away a lot of work. Maybe I'll do that first, and sort out the display of full comments (not just URLs), and then look at dealing with the whole process myself. Here's the expected flow: ``` // If target not exists // Fail // else If source not exists (404 or 410) // If have had webmention from this source before OR have mentioned this post myself // Delete // -> Remove $source from local store // else // Fail // else If source not contains link to target // Fail // // else If have had webmention from this source before // This is an update: what has changed? // Content - edit "$source-author edited their {inferred post type} of/to $target" // -> Store updated $source for display // {property} - edit or addition of property "$source-author edited/added {property} of their {inferred post type} of/to $target" // -> If this is a property I store/display, store update // Replies/comments - new reply (receiving salmention) "$reply-author {inferred post type}d $source-author's post that mentions $target" // -> Store for future threading display purposes.. // // else Infer mention type // Content - mention "$source-author mentioned $target in a post." // like-of - like "$source-author liked $target" // repost-of - repost "$source-author reposted $target" // bookmark-of - bookmark "$source-author bookmarked $target" // category - tag "$source-author tagged $target in a post" / "$source-author tagged a post with $target" // in-reply-to - reply "$source-author replied to $target" // {other property} - {other} "$source-author {other}-ed $target" // -> Store necessary $source contents for display // -> Resend webmentions to all links in $target (send salmention) ``` Once automatic display is working, one way or another, I'll also: * add a form to let people send webmentions to my posts from my site. * display all mentions aggregated at [/mentions](https://rhiaro.co.uk/mentions) (including homepage mentions aka person mentions). * some sort of push notifications hack, possibly an email, SMS or a poke from an IRC bot. Other things I might get around to this weekend: * Displaying reposts properly. * Fixing my micropub endpoint; it's currently rejecting Teacup posts for unknown reasons. * Automatically sending bridgy webmentions for likes and reposts of tweets.
This weekend at IndieWebCamp in Brighton, my main goal is to display received webmentions on my posts. Currently I collect them at webmention.io and will occasionally manually add them to my store when there's a reply I'd particularly like displayed. This is just displayed as a link at the bottom of the post. Initially I thought about just running a cron job to pull from webmention.io into my store. Since webmention.io does all the validating etc, this takes away a lot of work. Maybe I'll do that first, and sort out the display of full comments (not just URLs), and then look at dealing with the whole process myself. Here's the expected flow: // If target not exists // Fail // else If source not exists (404 or 410) // If have had webmention from this source before OR have mentioned this post myself // Delete // -> Remove $source from local store // else // Fail // else If source not contains link to target // Fail // // else If have had webmention from this source before // This is an update: what has changed? // Content - edit "$source-author edited their {inferred post type} of/to $target" // -> Store updated $source for display // {property} - edit or addition of property "$source-author edited/added {property} of their {inferred post type} of/to $target" // -> If this is a property I store/display, store update // Replies/comments - new reply (receiving salmention) "$reply-author {inferred post type}d $source-author's post that mentions $target" // -> Store for future threading display purposes.. // // else Infer mention type // Content - mention "$source-author mentioned $target in a post." // like-of - like "$source-author liked $target" // repost-of - repost "$source-author reposted $target" // bookmark-of - bookmark "$source-author bookmarked $target" // category - tag "$source-author tagged $target in a post" / "$source-author tagged a post with $target" // in-reply-to - reply "$source-author replied to $target" // {other property} - {other} "$source-author {other}-ed $target" // -> Store necessary $source contents for display // -> Resend webmentions to all links in $target (send salmention) Once automatic display is working, one way or another, I'll also: add a form to let people send webmentions to my posts from my site. display all mentions aggregated at /mentions (including homepage mentions aka person mentions). some sort of push notifications hack, possibly an email, SMS or a poke from an IRC bot. Other things I might get around to this weekend: Displaying reposts properly. Fixing my micropub endpoint; it's currently rejecting Teacup posts for unknown reasons. Automatically sending bridgy webmentions for likes and reposts of tweets.
Amy added http://bblfish.net/tmp/2011/05/09/ to https://rhiaro.co.uk/bookmarks/
Let the records show that I will never click or tap the twitter heart icon. Apparently it explodes or something? Dumb. All twitter likes are henceforth (finally) [*fully automated*](https://bitbucket.org/rhiaro/slogd/commits/67c1fe366988a9fe13cd08fd9c07899508d14fc6) via [bridgy](https://brid.gy). (And a million thanks to [kylewm](https://kylewm.com/) for spontaneous inclusion of error logs in bridgy profile pages!)
Let the records show that I will never click or tap the twitter heart icon. Apparently it explodes or something? Dumb. All twitter likes are henceforth (finally) fully automated via bridgy. (And a million thanks to kylewm for spontaneous inclusion of error logs in bridgy profile pages!)
Amy wrote about Kyle Mahan, hacking, indieweb, slogd, twitter, webmention, bridgy, & like
# Social Web WG 4th face-to-face summary *This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG!* See also [day 1 minutes](https://www.w3.org/wiki/Socialwg/2015-12-01-minutes) and [day 2 minutes](https://www.w3.org/wiki/Socialwg/2015-12-02-minutes). What follows is more detail on my perspective of the main conversations we had over the two days. Clarifications and corrections welcome. ## tl;dr ## * Most AS2 issues are closed! CR-blocking issues are now due by 15th December. * We took a bunch of things to Editor's Draft and are pushing for FPWDs as soon as is viable. * Some of the drafts overlap but there's a general feeling that since there are keen editors we should work on everything and iron out issues and redundancies as we go, rather than holding out and waiting for clarity. * Go check out the specs and build bits of them and give the editors feedback! ## ActivityStreams 2 We steamrollared through AS2 issues, which included core simplifications, vocabulary changes and reductions and editorial clarifications. James made most edits during the meeting, so there's [a much updated working draft](http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams-core/index.html) available now. You should read it and post any issues you see to be CR-blocking by the 15th of December. JSON-LD related stuff has been moved to its own section; since it is optional, having references sprinkled throughout was confusing for people who don't necessarily want to deal with it. [Chris](https://dustycloud.org) pointed out that even for extensions, if you know the extension you want to handle you can still do that in plain JSON. Still some consternation about which alternative syntax examples should be in the spec. Since they're non-normative/editorial anyway they're not a CR-blocker so left alone for the time being. We don't need a verison number in the URL because any future widely-deployed extensions that want to make it into the core will likely be incorporated as part of a full new version (ie. AS3). At some point we should start a registry for extensions; James is keeping track himself on github, we could move this to a wiki page and ultimately a CG when the WG wraps up. Lots of discussion about testing frameworks and how to meaningfully test production and consumption of syntax and vocabulary. I refer you to the minutes, as this is beyond my ability to summarise well enough, but it seemed like the people working on this gained some clarity and a plan to move forwards. ## Social API ### Editor's Draft all the things There's some contention around what it means to accept a spec as an Editor's Draft in the WG. Our general consensus was that it means a spec isn't necessarily going to be rec-track, or even the direction the group is going to take, but it's in-scope and worth some portion of our attention, even if that is just to inform other things. Most specs we've picked up are work that the editors were doing anyway, and this just means the WG should explicitly not ignore them. It's expected that the specs will change significantly going forward, in response to input from the WG. As such, it's okay that some of our now-ED specs currently cover overlapping territory. We hope that WG attention will serve to refine, cut, expand, merge, and otherwise sort this out. We may end up multiple small specs derived from our current set of EDs which cover pieces of the social puzzle, or several specs will demonstrate multiple viable ways of doing the same thing. My preference is for the former, but the latter is better than nothing. (I tentatively extrapolate the latter into either one gets wide adoption and the others quietly fade out, or they all get equal adoption and people build bridges between them, either way not a total loss). ### Social Web Protocols I finally convinced people to stop calling this "Amy's SocialAPI Document" and renamed everything to [Social Web Protocols](https://w3c-social.github.io/social-web-protocols/social-web-protocols). This document describes the individual componants we are trying to standardise (based on user stories), covering both the API and Federation. Given the potential for the WG to produce multiple small specs, work on this is to continue to describe and serve as a guide to each building block. This should highlight both points of convergence between separate specs, and gaps that no existing specs are filling adequately. Issues filed should be to that end. Point out obvious points of commonality between specs that I haven't noted, or where it would be worth replacing the vague overview with more spec-like details. I aim to take this to FPWD next week (which does *not* imply WG consensus on the contents yet) with the expectation that this is currently an overview document: a guide to the different areas being standardised by the WG. If we end up with a bunch of small (or overlapping) specs, this could end up as a Note, detailing how they relate to each other as a guide to implementors. If we end up with one spec that covers everything, either this becomes it following input from the other drafts, or this has done its job at converging things and is dropped completely. The rationale behind going to FPWD with this document is to better advertise and explain the different angles of work the WG is doing to other WGs and the public, and to seek wider feedback thereon. The issues become a place to discuss features based on *functionality*, where they are not specific to one of the other individual specs. ### ActivityPump and Micropub Both now EDs. Micropub covers a subsection of functionality of ActivityPump, but is uncoupled from any other pieces of functionality, whereas ActivityPump intertwines lots of things. There are distinct similarities - both POST JSON to a specific endpoint to create, update and delete content. The editors are keen to cooperate so there's value in working on them both in sync. ### jf2 jf2 is a social syntax to complement (*not* compete with!) AS2, where jf2 is content-centric and AS2 is activity-centric. The editors of both agreed that it would be beneficial to work on these in conjunction. I've written more about [the relationship between them here](/2015/12/things-happenings). ### Post type discovery PTD is an algorithm to help consumers who find themselves with implicitly typed objects to derive explicit AS2 types, if that's what they prefer to work with. My concern is that it's biased towards the microformats2 vocabulary and currently useful for a niche - but a very small niche. However, James pointed out that types are actually optional in AS2 in general, so it could be expanded to help go from untyped AS2 objects to typed ones as well. My other concern is that this space is such a moving target, and having a fixed algorithm to derive post types based on properties is going to get dated really fast. A constantly shifting algorithm doesn't fit into W3C workflow, and of course brings its own problems (who has implemented which version as it changes over time). I don't have an answer to this. ## Federation: Realisations and moving forward Evan forced us to slow down and really think about what we meant by federation. I don't know if anyone else did, but I had a bit of a lightbulb during this discussion. Bogged down in the particular bits of federation that are within reach to me (basically, notifications), I forgot there are a great many other things one might want to federate, like search, following topics, user discovery, recommendations... The WG is not required to tackle all of these, as a 'federation protocol' is the icing on our charter cake, but we absolutely don't want to de-prioritise federation completely as it's important and actually ties in well with a lot of the work we're already doing. But taking a step back to reassess - and clarify to the outside world - what we're actually doing is important, and there's some effort going into that now. ### Webmention Webmention has been an ED for a short while, and there were some issues to work through. Some really interesting points have been raised around technical details, security concerns and functionality enhancements, and lots of different ways to refine this spec are emerging. We talked through open issues, and group resolutions were made for most of them. The one I'm most interested in is addition of the [`property` parameter](http://csarven.ca/webmention) for better disambiguation of the assertion being made by a webmention. It surfaces a need of people outside of the current core webmention implementors to send and verify claims more precisely, whilst adding minimal additional overhead for those who don't need it. Since bringing this spec to the WG is an effort to gain wider adoption and investigate broader use cases than what we have at present, taking these kinds of expansions seriously is good. The benefits were positively acknowledge overall, and I was hoping we'd see this added to the current version, even if marked 'at risk' pending future implementations. But the decision was taken to leave it out, in the same vein as AS2 currently relegating all *addition* suggestions to extensions. On the plus side, the webmention spec will link to all proposed extensions which are written up as specs, and if any extensions see enough adoption over the course of the work they can be integrated into the core. ## Cooperation Bridging between worlds has been an ongoing theme in this WG. [Chris](https://dustycloud.org) has done some great work on [Activipy](http://activipy.readthedocs.org), a Python library for handling AS2, and overnight between meeting days he added support for jf2 as well by simply passing in an alternative JSON-LD context. This means you can pass in AS2 and serialize out again as jf2, and vice versa! More or less, at least... this might even be improved by adding PTD in between for where mappings aren't already obvious. In general, tensions between specs that could be overlapping have changed to editors supporting each other to drive all of the work forward, and, I'm hoping, to optimise where redundancies exist. We all have the same goals, after all. We've still got a long way to go, but we ended on the feeling that we can probably get there. And we played almost no SocialWG bingo, so it must have been a good meeting.
This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG! See also day 1 minutes and day 2 minutes. What follows is more detail on my perspective of the main conversations we had over the two days. Clarifications and corrections welcome. tl;dr Most AS2 issues are closed! CR-blocking issues are now due by 15th December. We took a bunch of things to Editor's Draft and are pushing for FPWDs as soon as is viable. Some of the drafts overlap but there's a general feeling that since there are keen editors we should work on everything and iron out issues and redundancies as we go, rather than holding out and waiting for clarity. Go check out the specs and build bits of them and give the editors feedback! ActivityStreams 2 We steamrollared through AS2 issues, which included core simplifications, vocabulary changes and reductions and editorial clarifications. James made most edits during the meeting, so there's a much updated working draft available now. You should read it and post any issues you see to be CR-blocking by the 15th of December. JSON-LD related stuff has been moved to its own section; since it is optional, having references sprinkled throughout was confusing for people who don't necessarily want to deal with it. Chris pointed out that even for extensions, if you know the extension you want to handle you can still do that in plain JSON. Still some consternation about which alternative syntax examples should be in the spec. Since they're non-normative/editorial anyway they're not a CR-blocker so left alone for the time being. We don't need a verison number in the URL because any future widely-deployed extensions that want to make it into the core will likely be incorporated as part of a full new version (ie. AS3). At some point we should start a registry for extensions; James is keeping track himself on github, we could move this to a wiki page and ultimately a CG when the WG wraps up. Lots of discussion about testing frameworks and how to meaningfully test production and consumption of syntax and vocabulary. I refer you to the minutes, as this is beyond my ability to summarise well enough, but it seemed like the people working on this gained some clarity and a plan to move forwards. Social API Editor's Draft all the things There's some contention around what it means to accept a spec as an Editor's Draft in the WG. Our general consensus was that it means a spec isn't necessarily going to be rec-track, or even the direction the group is going to take, but it's in-scope and worth some portion of our attention, even if that is just to inform other things. Most specs we've picked up are work that the editors were doing anyway, and this just means the WG should explicitly not ignore them. It's expected that the specs will change significantly going forward, in response to input from the WG. As such, it's okay that some of our now-ED specs currently cover overlapping territory. We hope that WG attention will serve to refine, cut, expand, merge, and otherwise sort this out. We may end up multiple small specs derived from our current set of EDs which cover pieces of the social puzzle, or several specs will demonstrate multiple viable ways of doing the same thing. My preference is for the former, but the latter is better than nothing. (I tentatively extrapolate the latter into either one gets wide adoption and the others quietly fade out, or they all get equal adoption and people build bridges between them, either way not a total loss). Social Web Protocols I finally convinced people to stop calling this "Amy's SocialAPI Document" and renamed everything to Social Web Protocols. This document describes the individual componants we are trying to standardise (based on user stories), covering both the API and Federation. Given the potential for the WG to produce multiple small specs, work on this is to continue to describe and serve as a guide to each building block. This should highlight both points of convergence between separate specs, and gaps that no existing specs are filling adequately. Issues filed should be to that end. Point out obvious points of commonality between specs that I haven't noted, or where it would be worth replacing the vague overview with more spec-like details. I aim to take this to FPWD next week (which does not imply WG consensus on the contents yet) with the expectation that this is currently an overview document: a guide to the different areas being standardised by the WG. If we end up with a bunch of small (or overlapping) specs, this could end up as a Note, detailing how they relate to each other as a guide to implementors. If we end up with one spec that covers everything, either this becomes it following input from the other drafts, or this has done its job at converging things and is dropped completely. The rationale behind going to FPWD with this document is to better advertise and explain the different angles of work the WG is doing to other WGs and the public, and to seek wider feedback thereon. The issues become a place to discuss features based on functionality, where they are not specific to one of the other individual specs. ActivityPump and Micropub Both now EDs. Micropub covers a subsection of functionality of ActivityPump, but is uncoupled from any other pieces of functionality, whereas ActivityPump intertwines lots of things. There are distinct similarities - both POST JSON to a specific endpoint to create, update and delete content. The editors are keen to cooperate so there's value in working on them both in sync. jf2 jf2 is a social syntax to complement (not compete with!) AS2, where jf2 is content-centric and AS2 is activity-centric. The editors of both agreed that it would be beneficial to work on these in conjunction. I've written more about the relationship between them here. Post type discovery PTD is an algorithm to help consumers who find themselves with implicitly typed objects to derive explicit AS2 types, if that's what they prefer to work with. My concern is that it's biased towards the microformats2 vocabulary and currently useful for a niche - but a very small niche. However, James pointed out that types are actually optional in AS2 in general, so it could be expanded to help go from untyped AS2 objects to typed ones as well. My other concern is that this space is such a moving target, and having a fixed algorithm to derive post types based on properties is going to get dated really fast. A constantly shifting algorithm doesn't fit into W3C workflow, and of course brings its own problems (who has implemented which version as it changes over time). I don't have an answer to this. Federation: Realisations and moving forward Evan forced us to slow down and really think about what we meant by federation. I don't know if anyone else did, but I had a bit of a lightbulb during this discussion. Bogged down in the particular bits of federation that are within reach to me (basically, notifications), I forgot there are a great many other things one might want to federate, like search, following topics, user discovery, recommendations... The WG is not required to tackle all of these, as a 'federation protocol' is the icing on our charter cake, but we absolutely don't want to de-prioritise federation completely as it's important and actually ties in well with a lot of the work we're already doing. But taking a step back to reassess - and clarify to the outside world - what we're actually doing is important, and there's some effort going into that now. Webmention Webmention has been an ED for a short while, and there were some issues to work through. Some really interesting points have been raised around technical details, security concerns and functionality enhancements, and lots of different ways to refine this spec are emerging. We talked through open issues, and group resolutions were made for most of them. The one I'm most interested in is addition of the property parameter for better disambiguation of the assertion being made by a webmention. It surfaces a need of people outside of the current core webmention implementors to send and verify claims more precisely, whilst adding minimal additional overhead for those who don't need it. Since bringing this spec to the WG is an effort to gain wider adoption and investigate broader use cases than what we have at present, taking these kinds of expansions seriously is good. The benefits were positively acknowledge overall, and I was hoping we'd see this added to the current version, even if marked 'at risk' pending future implementations. But the decision was taken to leave it out, in the same vein as AS2 currently relegating all addition suggestions to extensions. On the plus side, the webmention spec will link to all proposed extensions which are written up as specs, and if any extensions see enough adoption over the course of the work they can be integrated into the core. Cooperation Bridging between worlds has been an ongoing theme in this WG. Chris has done some great work on Activipy, a Python library for handling AS2, and overnight between meeting days he added support for jf2 as well by simply passing in an alternative JSON-LD context. This means you can pass in AS2 and serialize out again as jf2, and vice versa! More or less, at least... this might even be improved by adding PTD in between for where mappings aren't already obvious. In general, tensions between specs that could be overlapping have changed to editors supporting each other to drive all of the work forward, and, I'm hoping, to optimise where redundancies exist. We all have the same goals, after all. We've still got a long way to go, but we ended on the feeling that we can probably get there. And we played almost no SocialWG bingo, so it must have been a good meeting.
# Week in review ## 30 November - 6 December * Added some RDFa to my site templates; needs more work though. * SocialWG face-to-face ([notes](/2015/12/socialwg4-summary)). * [Indiewebcamp SF](https://indiewebcamp.com/2015/SF) * Fixed a paging bug (December was an edge case, apparently). * Added sessions so indieauth logins ot my site persist. * Made progress on my [webmention endpoint](/q) which in addition to the base webmention spec accepts the `property` parameter and will be able to verify mentions marked up with RDFa. * Wrote about different social web worldviews and how that affects data models: [Things and happenings](/2015/12/things-happenings). * Attempted to figure out https with letsencrypt on two different server setups. One was [not terrible](/2015/12/https-terrible), the other was [pretty terrible](/2015/12/https-what).
30 November - 6 December Added some RDFa to my site templates; needs more work though. SocialWG face-to-face (notes). Indiewebcamp SF Fixed a paging bug (December was an edge case, apparently). Added sessions so indieauth logins ot my site persist. Made progress on my webmention endpoint which in addition to the base webmention spec accepts the property parameter and will be able to verify mentions marked up with RDFa. Wrote about different social web worldviews and how that affects data models: Things and happenings. Attempted to figure out https with letsencrypt on two different server setups. One was not terrible, the other was pretty terrible.
This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG! See also day 1 minutes and day 2 minutes. We met in Boston on 16 and 17 March. What follows is more detail on my perspective of the main conversations we had over the two days. Clarifications and corrections welcome. ActivityStreams2 AS2 is inching closer to CR. Evan has made a validator at as2.rocks and done a lot of work on conformance criteria which we went through as a group and updated a little; mostly changing SHOULDs to MUSTs. Discussed and not necessarily resolved a few new open issues, including: considering dropping the Relationship object and reviving it as an extension if necessary; a proposal for a new property to say when something was deleted; weakening the SHOULD requirement on name; clarifying scope and context. Stay tuned for a new working draft sometime soon. SocialPub The most exciting thing I thought was agreeing on the potential for convergence between the create, update and delete parts of Activitypub and Micropub. Micropub started life as a super small and simple way for clients and servers to agree how to create content on a website by POSTing form encoded parameters to an endpoint. As a result of this simplicity, there are dozens of client and server implementations, allowing people to use each others posting clients to add posts to their site, from simple text-only posts to photos, events, RSVPs, likes, bookmarks, reposts. When Micropub needed update and delete, it grew beyond what form-encoded parameters could sensibly handle, and added in a JSON syntax which I think to date only the editor has implemented. Activitypub uses a JSON syntax (ActivityStreams2) from the outset for create, update and delete, and when you compare this with the Micropub JSON they look remarkably similar. My posting endpoint implements create the AP way, and endpoint discovery the MP way. It also catches Micropub form-encoded requests and translates them to AS2 JSON before proceeding, so I can still use simple Micropub clients. My posting clients burrow (checkins), obtainium (purchases), replicator (food) and seeulator (events, RSVPs, travel plans) all post AS2 JSON... after discovering the endpoint via rel=micropub. Next on my list, and well overdue at this point, is adding update and delete to both server and clients. So I proposed we write a document that unifies the common parts of AP and MP, iron out the smaller differences, and hope this coalesces into a small create/update/delete spec which both AP and MP can reference rather than duplicate. Because modularity is good, and common modules are better! I dubbed this temporarily (or is it?) SocialPub. So what's left in Micropub? I hear you cry. The super simple form-encoded create which is what made Micropub do so well in the first place is really what makes Micropub micro, so I'd like to see this be the bulk of the Micropub spec, with just a pointer to SocialPub for people who want to level up to JSON. There are still more than a few issues to be dealt with, though we handled a few during the meeting (such as media uploads). I'll be writing SocialPub up into the Social Web Protocols doc next week, stay tuned. Demos Jessica and Chris demo'd Media Goblin federating with pump.io! Which is cool. Which brings them a huge step closer to implementing things with AS2/AP and federating that way. They discussed how one of their main impediments had been database schema migration. Aaron demo'd his Micropub editing UI, which allows partial edits on the post, only for data he is most likely to want to edit (tags, syndication URLs and date). Aaron also demonstrated a new event posting interface in Quill which uses Micropub, and showed how RSVPs from Woodwind (a feed reader) work via Webmention. Tantek and Ben also demo'd RSVPs from their sites. And Ben demo'd how he can post reactjis as replies, exemplified with the poop emoticon, and there is no question that the future of the social web is in safe hands. Frank demonstrated federation between OwnCloud servers, which uses WebDAV and CalDAV, and talked through their access control. Admin/Process We also had a couple of admin/process related discussions. The first included agreeing to meet at TPAC in Lisbon in September as it already looks like there'll be critical mass to make it worthwhile. Sandro has made a list of issue labels for github which we painstakeingly went through to make sure everyone understands them and editors are willing to use them on specs. This should help people to figure out at a glance what the current state of a spec is from the issues, as well as help passers-by to jump in if they want to get involved.
This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG! See also day 1 minutes and day 2 minutes. We met in Portland on 6th and 7th June. What follows is more detail on my perspective of the main conversations we had over the two days. Clarifications and corrections welcome. This doesn't cover everything we talked about in detail; as well as the following, we resolved (or at least discussed) issues on all of the specs, and took a few to new Working Draft status. Demos I demoed my ActivityPub implementations; clients Burrow for checkins, Obtainium for consumption/purchase logging, Replicator for food logging and Seeulator for journeys and events. These all do create only by sending either appropriate activities (including some extensions) to my activitypub endpoint (aka outbox, but not discoverable as such yet). Seeulator creates the right kind of activity based on what attributes are filled in or left blank, essentially doing post-type discovery - albeit my own algorithm rather than tantek's spec from the user input to generate the right as:Activity. The newer thing I worked on was a client that only does updates of existing AS2 data. I wanted this so I could add captions to all my photos at img.amy.gy, so Morph does just that. This also means it has to be able to read/consume the AS2 data published at img.amy.gy about as:Collections of photos. Aaron demoed the Webmention test suite at webmention.rocks and notes that there are Webmention Rocks stickers available for people submitting implementation reports.. Aaron also demoed a new feature in the Micropub spec which is the media endpoint. After some discussion recently it was established that all mainstream social APIs seem to post media (like images) that have been embedded in a post to a separate endpoint, then embed the returned URL in the post content, and MediaGoblin does this too. Aaron's implementation in Quill is really swish looking, uploading the file to the discovered media endpoint whilst you're typing the rest of the blog post, then embedding it back in the UI so you can see it straight away. I should probably implement something along these lines, and sync it up with what ActivityPub is doing (which is going to be basically the same); it's especially useful as I host my images on a completely different domain and stack from my blog posts and right now I have a by-hand process of uploading images to one server, then copying the URL into a blog post to embed. Evan showed the Wordpress plugin implementation of AS2 by pfefferle, demonstrated on his fuzzy.ai blog. We all noticed a few bugs and AS1-isms in the implementation, but all correctable and all good flags for when we give advice for people switching existing implementations from AS1 to AS2. Modularising ActivityPub For a while I've been pushing to break ActivityPub up into several separate specs for each part, modularised by functionality, reasoning that this will lower the barrier to both CR and conforming implementations. I feel strongly that distinct functionalities should not be dependent upon one another to conform to the spec; ie. if I only want to implement subscribing/reading in my application, I shouldn't be required to implement creating new content as well. I've been back and forth on this with Chris and Jessica for at least a year and we're all getting closer to understanding one another. The WG resolved at this meeting to split into ActivityPub (reading, creating, updating, deleting content) and ActivitySub (name pending; subscription and delivery of content). It took me a little longer than it should have to really grok how closely tied 'delivery' and 'notifications' are, but now I realise that regardless of what triggers 'delivery' of an activity, the process of 'delivery' to someone's inbox is the same. The triggering part can be a subscription (a special side effect of receiving a Follow activity) or a notification (an activity or object is created which is addressed to or links to a user or other activity/object). Thus I anticipate ActivitySub describing how the triggers work, then how delivery works upon a trigger. I'd still like to be able to conform to the 'delivery' part without worrying about the 'trigger' part (maybe I want to implement an entirely different subscription trigger mechanism) but this can be achieved with conformance classes if splitting the spec up further is too much. New work The working group wraps up at the end of 2016. There's still time for us to work on new specs, but the ideal is that anything new being presented to the group will have been incubated (worked on, tested, implemented) outside of the group beforehand, either in a CG or other community or organisation. Coming soon to an editor's draft near you: PubSubHubbub! Next meeting We confirmed we'll meet on Thursday and Friday at TPAC in Lisbon in September. We'll also run a social web breakout session on the plenary day (Wednesday) like we did last year.
Updated working draft of Social Web Protocols published ahead of the Social Web WG face-to-face next week: https://www.w3.org/TR/social-web-protocols/ This describes and explains the various specs the WG is working on. Far from done, but we're making progress..
Amy wrote about phd, socialwg, resume, cv, solid, social, web, micropub, webmention, decentralised, activitypub, swwg, & protocols
Published a big update to Social Web Protocols. Read if you want to understand what the W3C Social Web WG is up to.
Amy wrote about web, phd, activitypub, socialwg, social, solid, decentralised, micropub, protocols, swwg, & webmention
The demos at today's decentralised social web breakout session went suspiciously well. Some things weren't pretty, but everything basically worked, and none of us had done any special coordinating before hand. We just showed the stuff we worked on, and it fit together fairly coherantly. Aaron demoed posting a reply with Micropub and behind-the-scenes Webmention sending. I showed my site feeds and individual posts as ActivityStreams 2.0, plus a screenshot of Chris's emacs-based reader displaying it: Chris... Just live demo'ed ActivityPub client-to-server stuff and server-to-server stuff at TPAC and it worked. Yay for live demos not blowing up! - @dustyweb on twitter demonstrated Pubstrate posting via ActivityPub to his local site, and peer to peer to another. - @t</> on twitter</> Sarven showed LDN, Solid, Web Annotations in dokieli, notifications sent to me displayed in OnScreen, and the LDN spec self-dogfooding with its own annotations on the side. We had some good questions/discussion about abuse prevention, and uptake. Hopefully this energy can be sustained through the next two days of WG meetings!
Decentralised Social Web Demos at TPAC2016
This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG! We met in Lisbon, Portugal, during the last two days of the W3C's annual TPAC conference on the 22nd and 23rd of September. See also day 1 minutes and day 2 minutes. tl;dr It's crunch time, but we're on track. We have a selection of specifications which essentially cover creating content and then pinging people about it in various different ways. Many people in the group are using one or more of these specs to power their own personal online social stuff. There are so many more Social Web problems to solve, and we're just trying to dig some foundations and plant some posts in the ground to get everyone else started. Wednesday demos The first time the Social WG gathered last week was for an hour on Wednesday, to demo the products of all of our specs to the broader audience of TPAC attendees. We had a full house. Everything went smoothly, and our demos were fairly coherent. Aaron showed Micropub and Webmention working together in the context of posting a reply to his site (with Micropub), which automatically sent a Webmention to post he was replying to, and after a few seconds his reply showed up there (on the site of someone who isn't a WG member, and had implemented Webmention receiving independently). My site returns ActivityStreams 2.0 for everything when you request application/activity+json or application/ld+json, so I showed collections and individual objects at the commandline. Dumping a blob of JSON on the screen isn't a particularly compelling demo, but Chris was able to furnish me with a screenshot of his AS2 consumer, emacs-based, rendering one of my posts. Maybe you want to make an AS2 reader so you can design your own reading experience for my posts? Chris showed how he is able to create notes on his site using an emacs-based posting client, which prompts his server to send the message on to the inbox of anyone addressed, all using ActivityPub. Sarven showed dokieli; sharing an article with someone (automatically pulled from the contacts list in his profile) which sends an ActivityStreams Announce to their Inbox using LDN. Also annotating an article, whereby he could save the annotation in his own personal datastore (via LDP) and optionally send a copy to the AnnotationService provided by the publisher (using the Annotations protocol, plus send a notification to the publisher with LDN. What followed was some discussion of how we're planning to tackle spam and abuse. ActivityPub includes a mechanism for blocking another user; LDN encourages imposing constraints on one's inbox to filter what ends up there; and self-hosted or known/trusted hosts for you content can give you more control over what shows up where, but there's way more to be done here, and we're not close to tackling that yet. Wide review Guidance was recently issued that specifications should ask for horizontal review (review by other W3C groups) three months before going to Candidate Recommendation. We're obviously far too late for that, so we're doing the best we can with the time remaining. Horizontal review is part of 'wide review', which specifications must also demonstration before they can transition to CR. Wide review invovles having input and feedback from a variety of different sources outside of the Working Group, and even W3C. We can demonstrate this through issues raised on github, implementations reported to us, and feedback on public mailing lists. As such, if you're going to send any of us a message about any of our specs, please do so somewhere that is public! The public-socialweb list is archived by W3C, so that's a good one to CC if you don't want to raise an issue on github directly. Pointing out typos, requests for clarification, and pledges to implement are welcome too. The Security & Privacy groups provide a questionnaire to guide through common issues that might be flagged during review by those groups. We collectively decided to carry out this questionnaire and add it to the 'Security and Privacy Considerations' section of all of our specs. The Internationalisation (i18n) WG also provide a checklist to run through which helps them perform their review more quickly. Specs in CR ActivityStreams 2.0 (core and vocab), Webmention, and Micropub are currently in Candidate Recommendation (CR), which means we're actively soliciting implementations and accepting reports. They all have test suites in some stage of readiness, and the implementation report templates are provided in the respective repos, and designed largely around reporting which tests your implementation passes. Issues raised during CR which require substantive spec changes and may affect existing implementations require restarting the CR period (pushing back CR exit for a minimum of four weeks), so the earlier we hear about those the better. We went through issues raised on our CR specs to determine whether they result in normative changes, and for the most part they were editorial. Webmention dropped returning a human-readble message in response to a sender's POST request, because anything involving human-readable text opens internationalisation challenges. This message was primarily for developer debugging as it's unlikely to ever been seen by an end user, and it was optional anyway, really only mentioned as a possibility, so this was always at the implementations' discretion. Servers are expected to 'do HTTP properly' and send and honour Accept headers for language if they are sending human-readable responses, which doesn't need explicitly calling out in the Webmention spec. There was discussion of requiring a "backoff" strategy when trying to discover a Webmention endpoint. This also applies to LDN, and any other specs which requiring probing at webpages to determine if they accept whatever the discover-er is trying to send. The issue is that a sender may be triggered to attempt discovery multiple times on the same URL, or for different URLs on the same domain. There's a point at which they should stop trying if they fail, or risk the server being probed blocking them completely for an unreasonable amount of GET or HEAD requests. Webmention has added a suggestion to include a User-Agent header which mentions "webmention" with the initial discovery request, so that an unsuspecting target may at least have some idea of what all of these requests are about, and can act on more information than just assuming it's some kind of DOS attack. This isn't a requirement though, as implementations in JavaScript are unable to edit the User-Agent, and implementations that are part of some other system may already have a custom User-Agent that they can't or don't want to replace. Consequently I've added a section to Social Web Protocols to give additional general guidance about not making enemies when you're looking for endpoints, including honouring eg. Retry-After headers on the server. The biggest Micropub issue concerned the media type of the (very specific) JSON structure returned in the event of an error. The conclusion was not to do anything special now, but if there are future versions of Micropub which modify the structure, they will use a profile to indicate which version they are, so implementations encountering that error know how to interpret it. During our crossover meeting with the i18n WG we noticed that Micropub's dependency on Microformats2 means that it has no way to indicate content language. This is being worked on in mf2 though, and Micropub will get a note to indicate this, and any improvements to mf2 will be incorporated in Micropub by reference. This seems at first glance a bit fishy since we're only supposed to reference 'stable' external specs, but this was resolved earlier in the year by the various mf2 sub-specs documenting their change policy, and committing to clearly indicate which parts are 'stable' and how they are updated. ActivityStreams 2.0 has acquired a bunch of editorial comments since going to CR, and these have been addressed. There's a bigger question of how to manage (append-only) extensions after the close of the WG, and we settled on Proposal 2 in issue 370. I'll be writing this up in the (pending) human-readable namespace document shortly. Then there was an even bigger question of whether or not name is a required property for all objects and activities. At the time of the meeting it was required, but given some implementor experience - in particular with people adding dummy meaningless names to activities just to pass the validator - we revised this. The usefulness of a name for every entity is giving consumers something to display even if they don't understand any other properties. A drawback of developers adding auto-generated or dummy names is that a consumer can't tell the difference between this and an actually meaningful name, so it can't make a sensible decision on whether it can overwrite it with something more useful (eg. in a different language, or something particular to the application at the time). We decided to shift the burden of assigning names to unnamed entities from publishers to consumers, as consumers are more aware of the context in which the entity is being used or displayed. Publishers can of course assign a name, which should be consistently respected by consumers as they'll now have confidence the name was assigned deliberately. We still think there should be a name for Article type objects. So we resolved to switch to having two properties: one which is required, expected to be machine-generated, and can be replaced by consumers if they think they can do it better. one which is optional, expected to be human-generated and meaningful, and consumers should respect it. We haven't decided exactly what the names for these two properties are yet. Probably 2. is name and I like fallbackName for 1., but others up for discussion are title and label... but watch this space... (and issue 312). We really need implementation reports for AS2 by the way... in case that was news. Let us know what you're working on! Specs imminently entering CR The most substantive issue we discussed on ActivityPub was adding a source property, to indicate the original input the user made in case it is converted from something else to HTML for the content field. The obvious use case for this is letting users author their content in markdown. Storing the original markdown alongside the converted HTML lets the client present the markdown back again for the user to edit in future. Current pump.io implementations have problems with letting users create content at first with markdown, but presenting HTML back to them later, which can be confusing. Personally I think a client that offers markdown editing and can do the conversion to HTML to send to the server should also be able to take that HTML content and convert it back to markdown for the user in the case of editing an existing post. Apparently going back the other way is more challenging though. And Chris's use case was for having a representation of the content in emacs org mode, not markdown. I was worried that the source and content fields could get out of sync if editing the same content is done by multiple different clients. That's (probably?) fairly edge though (though I'm already using multiple APish clients on the same content). We compromised by saying that clients which find source and don't understand it must prompt the user to let them know the original source will be lost of they proceed with editing, as a feature "at risk". I'm a bit wary about specifying a UI thing in the spec, but we'll try it out and see how it goes. But maybe all it really is is a requirement that clients MUST understand this particular property; so far there aren't any properties a client can't ignore. We got agreement to add ActivityPub terms which are extra to AS2 into the AS2 namespace and JSON-LD context, which will simplify things for implementors. This also stands as an initial experiment with how AS2 extensions can be done in the future. Chris also proposed to define the media endpoint of AP as "at risk" as, even though they need it in MediaGoblin, it's not worth potentially holding the rest of AP up for, and they can easily develop it as an extension afterwards. There may also be a possibility of convergence between the Micropub and AP media endpoints. We began our LDN discussion by learning that Kjetil, who had attended the first day of our meetings and then had to leave, implemented a portion of an LDN sender/consumer on his flight back to Norway. LDN is addressing the "backoff" issue previously mentioned for Webmention by referring the new section in Social Web Protocols, and stressing that implementations should anticipate and respect relevant HTTP status codes. After all, it's only polite. We briefly discussed LDN's need to add inbox to the LDP namespace, but we had a session on the Wednesday plenary day about extensibility of W3C namespaces in general, including a bunch of LDP people in the room, none of whom objected. We also had support in our github issue about this. The WG agreed to go ahead with whatever the relevant W3C and Semantic Web communities consent to. Hindsight addendum: I added inbox (at risk pending PR) to the LDP namespace a week or so later. Nobody has complained and the Web still seems to be up. In LDN we had a section ("Security, Privacy and Content Considerations") which mixes normative and non-normative content, and I was getting confused about what kinds of things are supposed to be which. The experts in the room helped us to untangle this section, and we decided to move all normative content into the appropriate parts of the spec; to move some of the informative content into green 'note' boxes if they pertain to something specific, and anything that was left should apply to the spec in general and we could mark the entire section as entirely non-normative. Both LDN and AP will have complete or partial test suites, or a detailed plan for a test suite, before they can enter CR. Specs in earlier stages Post Type Discovery right now defines a 'mapping' from combinations of properties a post might have (based on mf2 properties, though many of them are explicitly unstable so we can't actually reference them normatively) to a 'type' currently presented as an English-language string. We discussed at length the purpose of Post Type Discovery and came to the conclusion that it ultimately needs to be possible to generate ActivityStreams 2.0 types (rather than arbitrary strings, which are essentially yet another vocabulary). Many of us thought it was supposed to be doing this anyway, and were surprised that it hasn't yet. So this should see some significant updates in the near future towards this. PubSubHubbub is raring to go as a FPWD, thanks to Julien's hard work in updating it to W3C spec format. We just have to jump some process hurdles, and that'll be published soon. Now is a great time to raise issues on it if you have or intended to implement it! We spent some time discussing a new name which is friendlier to non-English language speakers, and we're probably going to go with PubSub. We also decided to close the PuSH community group, as any further discussion around the spec should take place in the WG. The future There's a general consensus that we've barely scratched the surface, but we formally resolved not to try to take on any more recommendation track documents henceforth. We need to focus on getting what we have to rec! However, to continue work after the group closes at the end of the year, including for managing errata and extensions, we'll open a Community Group. We'll do this towards the end of our charter, but if you're interested in being a part of it, drop an email to the public list. We're planning another face-to-face sometime in on the 17 and 18 of November in either San Francisco or Boston. Whence we'll hopefully be wrapping things up! There's another writeup here by Chris.