tantek (3 out of 3)

8th Social WG F2F Summary

This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG!

We met at MIT in Cambridge, MA, on the 17th and 18th of November. See also day 1 minutes and day 2 minutes.

tl;dr

Everything 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.

Community Group

The 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.

The spec formally known as PubSubHubbub

At 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).

We 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.

In 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.

ActivityStreams 2.0

We 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.

So 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.

Other CRs

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.

Micropub: Tests, Implementation reports
LDN: Tests, Implementation reports
ActivityPub: Tests, Implementation reports

Extension

The 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.

Implementations

An 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.

🏷 Sarven Capadisli https://aaronpk.com https://dustycloud.org aaronpk activitypub activitystreams as2 csarven cwebber evanpro julien ldn micropub phd pubsub pubsubhubbub sandro social web protocols social web socialwg standards swicg tantek w3c websub

Thu 24th of November 2016 at 8:49pm (-05:00)

Post created with https://rhiaro.co.uk/sloph

Decentralisation considered harmful

As I work - on writing standards, writing code, studying centralised and decentralised systems - and as I read the news and watch events unfold around me, bubbling away under the surface is always an unease. What if we're making it worse? We all have blind spots, limited experiences. And especially so since many of us working on decentralisting the Web are not amongst those who would benefit most from the purported advantages. Some of us have been working (or watching) in this space for years, decades, longer than the Web. But more of us, an only ever increasing number, have not. We are privileged, we are nerds, most of us don't have all that much experience, and we do not know best. We've jumped on this decentralisation thing as a solution to lots of global problems.

Towards the end of last week, Tantek prompted me to actually articulate some of what were previously just subconscious discomfort. How are the decentralised technologies we're working on going to make people more vulnerable?

Smaller attack surfaces: Large centralised systems have robust network architectures; lots of money and expertise to keep things running even if under attack (except when someone uses all of the Web-enabled kettles to DDOS them, but that aside). Many decentralised architectures imagine smaller 'pods' which federate. It's possible many of these servers will be run by volunteers, hobbyists, or small/poor organisations, and could be easily knocked over and kept down by malicious actors.

Quieter takedowns: We want it to be easier for small communities, perhaps vulnerable minorities, to create safe spaces in their own corner of the Web, and to be able to keep out those who jeopardise that. If these communities are 'disappeared' (perhaps made easier by the previous point) the rest of the Web might not notice until it's too late.

Illusion of control: We promote decentralisation as a way to control who has access to your personal/social data, and to be able to move it somewhere else if you want. But a key part of decentralisation is federation, or enabling access to your data by other systems, ie. so that you and your friends can use a different applications for the same thing, without that getting in the way of your interactions. This involves open data formats and standard APIs and likely complex access control setups. Most people tell me they can't get a handle on their Facebook privacy settings, and these are for a single unified system. Just because you could move your data to a different service, doesn't mean it's safe where it is.

Illusion of control 2: Normies look at me like I'm nuts when they find out I share more about myself on my personal website than they do on social media. I tell them I know exactly what I'm sharing, rather than having it slurped up by algorithms which monitor everything they click or hover over. My explicit sharing is greater, but my implicit sharing is reduced. Or so I think. Related to the previous point, my data is all public and nicely marked up to be machine readable. The confidence I have about the fact that I have to jump through inconvenient hoops of my own making to get it online is dangerous. If social media has normalised dangerous oversharing, and the general populace is starting to clock the 'dangerous' part, then decentralised social media runs the risk of convincing people their oversharing is 'safe' again, setting us back a decade.

The filter bubble: The easier we make it for people to avoid abuse online (just imagine for half a second that the decentralisation efforts are even close to solving this, k?), the easier we make it for people to filter out diverse points of view. The first thing I noticed when Twitter introduced its recent phrase filtering thing was a bunch of privileged liberals screaming about the filter bubble and completely missing the point. But anyway. If this is an either/or we're in trouble.

This is doubtless just the beginning of a very long list, and there are others thinking/writing about this as well. I'll update this post to list other articles as I come across them.

🏷 http://tantek.com decentralisation indieweb phd politics silos social media social web socialwg tantek web