{"@context":{"rdf":"http://www.w3.org/1999/02/22-rdf-syntax-ns#","rdfs":"http://www.w3.org/2000/01/rdf-schema#","owl":"http://www.w3.org/2002/07/owl#","foaf":"http://xmlns.com/foaf/0.1/","dc":"http://purl.org/dc/elements/1.1/","dct":"http://purl.org/dc/terms/","sioc":"http://rdfs.org/sioc/types#","blog":"http://vocab.amy.so/blog#","as":"https://www.w3.org/ns/activitystreams#","mf2":"http://microformats.org/profile/","ldp":"http://www.w3.org/ns/ldp#","solid":"http://www.w3.org/ns/solid#","view":"https://terms.rhiaro.co.uk/view#","asext":"https://terms.rhiaro.co.uk/as#","dbp":"http://dbpedia.org/property/","geo":"http://www.w3.org/2003/01/geo/wgs84_pos#","doap":"http://usefulinc.com/ns/doap#","time":"http://www.w3.org/2006/time#"},"@graph":[{"@id":"https://rhiaro.co.uk/2016/03/socialwg5-summary","@type":"as:Article","as:content":"
This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG!
\r\nSee also day 1 minutes and day 2 minutes.
\r\nWe 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.
\r\nAS2 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.
\r\nDiscussed 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.
\r\nThe most exciting thing I thought was agreeing on the potential for convergence between the create, update and delete parts of Activitypub and Micropub.
\r\nMicropub 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.
\r\nActivitypub 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.
\r\nMy 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.
\r\nSo 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.
\r\nThere 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.
\r\nJessica 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.
\r\nAaron 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).
\r\nAaron 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.
\r\nFrank demonstrated federation between OwnCloud servers, which uses WebDAV and CalDAV, and talked through their access control.
\r\nWe 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.
\r\nSandro 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.
","as:name":"5th Social WG F2F Summary","as:published":{"@type":"http://www.w3.org/2001/XMLSchema#dateTime","@value":"2016-03-29T10:43:39+01:00"},"as:tag":[{"@id":"https://rhiaro.co.uk/tags/activitypub"},{"@id":"https://rhiaro.co.uk/tags/activitystreams"},{"@id":"https://rhiaro.co.uk/tags/as2"},{"@id":"https://rhiaro.co.uk/tags/meeting"},{"@id":"https://rhiaro.co.uk/tags/micropub"},{"@id":"https://rhiaro.co.uk/tags/phd"},{"@id":"https://rhiaro.co.uk/tags/social+web+protocols"},{"@id":"https://rhiaro.co.uk/tags/social+web"},{"@id":"https://rhiaro.co.uk/tags/socialpub"},{"@id":"https://rhiaro.co.uk/tags/socialwg"},{"@id":"https://rhiaro.co.uk/tags/standards"},{"@id":"https://rhiaro.co.uk/tags/w3c"},{"@id":"https://rhiaro.co.uk/tags/webmention"}]},{"@id":"https://rhiaro.co.uk/2016/09/socialwg7-summary","@type":"as:Article","as:content":"This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG!
\r\n\r\nWe 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.
\r\n\r\n\r\n\r\nIt'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.
\r\n\r\nThe 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).
\r\n\r\nMy 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.
\r\n\r\nSarven 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.
\r\n\r\nGuidance 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.
\r\n\r\nActivityStreams 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.
\r\n\r\nWebmention 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.
\r\n\r\nDuring 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.
\r\n\r\nActivityStreams 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.
\r\n\r\nThen 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:
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!
\r\n\r\nThe 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.
\r\n\r\nChris 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.
\r\n\r\nWe 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.
\r\n\r\nLDN 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.
\r\n\r\nWe 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.\r\n\r\n
Both LDN and AP will have complete or partial test suites, or a detailed plan for a test suite, before they can enter CR.
\r\n\r\nPost 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.
\r\n\r\nPubSubHubbub 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.
\r\n\r\nThere'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.
\r\n\r\nWe'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.
","as:name":"7th Social WG F2F Summary","as:published":{"@type":"http://www.w3.org/2001/XMLSchema#dateTime","@value":"2016-10-15T18:41:00-07:00"},"as:tag":["https://rhiaro.co.uk/tags/as2",{"@id":"http://csarven.ca/#i"},{"@id":"http://tantek.com"},{"@id":"https://aaronpk.com"},{"@id":"https://dustycloud.org"},{"@id":"https://rhiaro.co.uk/tags/activitypub"},{"@id":"https://rhiaro.co.uk/tags/activitystreams"},{"@id":"https://rhiaro.co.uk/tags/indieweb"},{"@id":"https://rhiaro.co.uk/tags/ldn"},{"@id":"https://rhiaro.co.uk/tags/micropub"},{"@id":"https://rhiaro.co.uk/tags/post+type+discovery"},{"@id":"https://rhiaro.co.uk/tags/pubsub"},{"@id":"https://rhiaro.co.uk/tags/social+web+protocols"},{"@id":"https://rhiaro.co.uk/tags/socialwg"},{"@id":"https://rhiaro.co.uk/tags/w3c"},{"@id":"https://rhiaro.co.uk/tags/webmention"},{"@id":"https://rhiaro.co.uk/tags/work"}]},{"@id":"https://rhiaro.co.uk/2016/11/socialwg8-summary","@type":"as:Article","as:content":"This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG!
\r\n\r\nWe met at MIT in Cambridge, MA, on the 17th and 18th of November. See also day 1 minutes and day 2 minutes.
\r\n\r\nEverything is progressing. Naming things is hard. We need your implementations please or features may be dropped from some specs. We hope to extend by 6 months, not so we all make more work to do, but just so that the newest spec has time to make it to rec given process timing requirements. We're transitioning any other work into a CG.
\r\n\r\nThe Social Web Incubator Community Group, should be pronounced swi-kig, but by the end of the meeting everyone had taken to calling it swish. I think it was Evan's fault. Anyway it's live, and is where we'll continue to develop on top of the things we started in the WG, as well as think about how to tackle things we haven't got to yet. Aaron and Chris are chairing it, and plan for discussion to take place primarily on github and IRC, with mailing lists for broadcast only. You should join.
\r\n\r\nAt the last face-to-face we renamed PubSubHubbub to PubSub. We subsequently realised this is too generic a term for quite a specific spec, and as a result is hard to search the Web for, and hard to find/name libraries and packages for. Renaming it again took the better part of a month. Heh. A few weeks ago we developed a fairly long shortlist on the wiki, listing pros and cons, and a few people voted and left their rationale. On day one of this face-to-face, we ruled out every single one of those suggestions, and came up with three new ones (WebSub, WebFollow and WebSubscribe).
\r\n\r\n\r\n\r\nWe slept on it, and just before lunch of day 2, voted between these three. WebSub won. I like it for its closeness to PubSub; WebFollow is a good name for a user-facing feature that implements the WebSub protocol. Then we proceeded to brainstorm more names in the google doc, progressively making the font smaller and introducing columns so we could see them all at once.
\r\n\r\n\r\n\r\nIn less important news, we added Aaron as a coeditor of the WebSub spec, resolved a bunch of issues, and there's an updated working draft up.
\r\n\r\nWe decided to go ahead with a new CR for ActivityStreams 2.0. Though it's frustrating to increase the time to exit, it's also not infeasible that getting implementation reports which sufficiently cover all features will take another month anyway. Plus, this extra time ensures that the ActivityPub implementations will make it into AS2 implementation reports.
\r\n\r\nSo we have a bunch of changes to AS2 since we entered CR, although none of them affect implementations or are technically normative changes, which is why we could get away without restarting CR if necessary. But we decided updating the spec with these changes (mostly editorial, clarifications, etc, which do not change the intent of the spec) is important enough not to save them all for the PR publication. Personally I think we should publish a version with the new wording around name
and summary
(a plaintext summary
for all objects is required in the absence of name
) as soon as possible.
Another useful clarification is explicitly stating that the value of the @context
key may be a plaintext string, an array, or an object. We added examples of each of these, so it's clear for consumers what to look for. This is particularly important for making sure implementations which include extensions - for which the @context
is necessarily an array or an object - are not completely dropped on the floor by consumers. Consumers can of course ignore extension properties they don't understand, but they should not ignore standard AS2 properties just because there are extensions alongside it.
This also means that it's possible to use the JSON-LD @language
construct properly (inside the @context
object) to set the base language for a whole AS2 object. As there are other ways to set the language, for individual objects or for specific values, setting the @language
is not required. Further, you should not set a language if you don't actually know what it is. And we haven't dumped language tags in all of the examples in the spec, in order to avoid people copying and pasting the examples without updating the language tags we use. Apparently this phenomenon is seen all over the Web, with EN
language markers alongisde text that is most certainly not EN.
We skimmed through a few issues for each of Micropub, LDN and ActivityPub, and checked in on how test suites and implementation reports are doing. The editors (Aaron, Sarven, and Chris respectively) are working exceptionally hard on building the test suites and chasing implementors. They are all at various stages of progress, and we know we have at least some implementations of some features of each.
\r\n\r\nThe Working Group's charter expires at the end of this year. Due to minimum time constraints on various parts of the publication process, as WebSub was late to join the WG we need until at least April to take it through to a recommendation, and that's with absolutely nothing going wrong. We were aiming, obviously, for all of our other specs to be wrapped up before the various December holidays, but it'd be tight. Adding buffer time for unexpected issues, and editors-not-having-to-make-themselves-ill-with-allnighters time, we figured they'll be exiting CR in January or early February at the latest. So we expect to get an extension of 6 months, and reduce our telecon time to monthly after January. The extra time on top of April means we won't need to freak out if for any reason WebSub has to have a second CR. This also overlaps with the opening of the Community Group, so it should help with the transition.
\r\n\r\n\r\n\r\nAn extra shoutout to anyone who is thinking of or starting to implement any part of any of our specs! Please let us know, either by filing implementation reports (even partial ones are helpful) or pinging us on IRC (#social) or the mailing list so we know to chase you at some point in the future. If you don't want a feature of a spec to be dropped, ie. because you want to use it, we have to prove it has been implemented. If possible, don't wait around for us to exit CR, because we need your implementations to make it that far.
","as:generator":{"@id":"https://rhiaro.co.uk/sloph"},"as:name":"8th Social WG F2F Summary","as:published":{"@type":"http://www.w3.org/2001/XMLSchema#dateTime","@value":"2016-11-24T20:49:00-05:00"},"as:tag":[{"@id":"http://csarven.ca/#i"},{"@id":"https://aaronpk.com"},{"@id":"https://dustycloud.org"},{"@id":"https://rhiaro.co.uk/tags/aaronpk"},{"@id":"https://rhiaro.co.uk/tags/activitypub"},{"@id":"https://rhiaro.co.uk/tags/activitystreams"},{"@id":"https://rhiaro.co.uk/tags/as2"},{"@id":"https://rhiaro.co.uk/tags/csarven"},{"@id":"https://rhiaro.co.uk/tags/cwebber"},{"@id":"https://rhiaro.co.uk/tags/evanpro"},{"@id":"https://rhiaro.co.uk/tags/julien"},{"@id":"https://rhiaro.co.uk/tags/ldn"},{"@id":"https://rhiaro.co.uk/tags/micropub"},{"@id":"https://rhiaro.co.uk/tags/phd"},{"@id":"https://rhiaro.co.uk/tags/pubsub"},{"@id":"https://rhiaro.co.uk/tags/pubsubhubbub"},{"@id":"https://rhiaro.co.uk/tags/sandro"},{"@id":"https://rhiaro.co.uk/tags/social+web+protocols"},{"@id":"https://rhiaro.co.uk/tags/social+web"},{"@id":"https://rhiaro.co.uk/tags/socialwg"},{"@id":"https://rhiaro.co.uk/tags/standards"},{"@id":"https://rhiaro.co.uk/tags/swicg"},{"@id":"https://rhiaro.co.uk/tags/tantek"},{"@id":"https://rhiaro.co.uk/tags/w3c"},{"@id":"https://rhiaro.co.uk/tags/websub"}]},{"@id":"https://rhiaro.co.uk/2017/12/swp","@type":"as:Note","as:content":"I published Social Web Protocols as a Social Web Working Group Note today.
It's supposed to be a one-stop shop for understanding the various specs of the WG. Hopefully it makes your life easier not harder.
","as:published":{"@type":"http://www.w3.org/2001/XMLSchema#dateTime","@value":"2017-12-25T16:08:00+01:00"},"as:tag":[{"@id":"https://rhiaro.co.uk/tags/w3c"},{"@id":"https://rhiaro.co.uk/tags/socialwg"},{"@id":"https://rhiaro.co.uk/tags/social+web+protocols"}]},{"@id":"https://rhiaro.co.uk/2017/12/weeks-in-review","@type":"as:Article","as:content":"ActivityPub and WebSub went to REC this week and the work of the Social Web WG in general has been getting a lot of attention, including AP making it to the top of hackernews. There are lots of good comments, but of course it's the negative ones that stick around when you release your babies into the harsh wilds of the Web for the last time.
\r\n\r\nThere was a lot of conflict inside the SocialWG, and a lot of compromise. The comments that irk me the most are the ones that suggest we made decisions on a whim without thinking about things at length, or ignored prior art.
\r\n\r\nSure we standardised multiple ways of doing similar things, but the decision to do that came only after much wailing and gnashing of teeth* and faced with the prospect of not standardising anything at all in this space. Or alternatively one- to two-thirds of the group meeting with suspicious accidents in lieu of consensus. It wasn't for funsies. We weren't trolling implementors. We were just trying to cope.
\r\n\r\nAnyway, what reassures me in the end is that, as we could never make everyone happy, at least we've somehow succeeded in making nobody at all happy.
\r\n\r\nThe art of consensus.
\r\n\r\n* and over a year of work, dozens of telecons and several face-to-face meetings around the world often at participants' own expense, and not a little yelling.
","as:published":{"@type":"http://www.w3.org/2001/XMLSchema#dateTime","@value":"2018-01-25T18:15:00+01:00"},"as:tag":[{"@id":"https://rhiaro.co.uk/tags/standards"},{"@id":"https://rhiaro.co.uk/tags/websub"},{"@id":"https://rhiaro.co.uk/tags/social+web+protocols"},{"@id":"https://rhiaro.co.uk/tags/socialwg"},{"@id":"https://rhiaro.co.uk/tags/activitypub"},{"@id":"https://rhiaro.co.uk/tags/w3c"}]},{"@id":"https://rhiaro.co.uk/tags/social+web+protocols","@type":"as:Collection","as:totalItems":{"@type":"http://www.w3.org/2001/XMLSchema#nonNegativeInteger","@value":"6"}},{"@id":"https://rhiaro.co.uk/tags/social+web+protocols?before=https://rhiaro.co.uk/2018/01/social&limit=16","@type":"as:CollectionPage","as:items":[{"@id":"https://rhiaro.co.uk/2018/01/social"},{"@id":"https://rhiaro.co.uk/2017/12/swp"},{"@id":"https://rhiaro.co.uk/2017/12/weeks-in-review"},{"@id":"https://rhiaro.co.uk/2016/11/socialwg8-summary"},{"@id":"https://rhiaro.co.uk/2016/09/socialwg7-summary"},{"@id":"https://rhiaro.co.uk/2016/03/socialwg5-summary"}],"as:name":"social web protocols","as:partOf":{"@id":"https://rhiaro.co.uk/tags/social+web+protocols"}}]}