Posts with tag "standards"

Vote for Amy Guy on the W3C TAG (if you can)

By Chris Lemmer-Webber on Mon 21 December 2020

My friend Amy Guy is running for election on the W3C TAG (Technical Architecture Group). The TAG is an unusual group that sets a lot of the direction of the future of standards that you and I use everyday on the web. Read their statement on running, and if you can, ie if you're one of those unusual people labeled as "AC Representative", please consider voting for them. (Due to the nature of the W3C's organizational and funding structure, only paying W3C Members tend to qualify... if you know you're working for an organization that has paying membership to the W3C, find out who the AC rep is and strongly encourage them to vote for Amy.)

So, why vote for Amy? Quite simply, they're running on a platform of putting the needs of users first. Despite all the good intents and ambitions of those who have done founding work in these spaces, this perspective tends to get increasingly pushed to the wayside as engineers are pressured to shift their focus on the needs of their immediate employers and large implementors. I'm not saying that's bad; sometimes this even does help advance the interest of users too, but... well we all know the ways in which it can end up not doing so. And I don't know about you, but the internet and the web have felt an awful lot at times like they've been slipping from those early ideals. Amy's platform shares in a growing zeitgeist (sadly, still in the wispiest of stages) of thinking and reframing from the perspective of user empowerment, privacy, safety, agency, autonomy. Amy's platform reminds me of RFC 8890: The Internet Is For End Users. That's a perspective shift we desperately need right now... for the internet and the web both.

That's all well and good for the philosophical-alignment angle. But what about the "Technical" letter in TAG? Amy's standing there is rock-solid. And I know because I've had the pleasure of working side-by-side with Amy on several standards (including ActivityPub, of which we are co-authors.

Several times I watched with amazement as Amy and I talked about some changes we thought were necessary and Amy just got in the zone, this look of intense hyperfocus (really, someone should record the Amy Spec Editing Zone sometime, it's quite a thing to see), and they refactored huge chunks of the spec to match our discussion. And Amy knows, and deeply cares, about so many aspects of the W3C's organization and structure.

So, if you can vote for, or know how to get your organization to vote for, an AC rep... well, I mean do what you want I guess, but if you want someone who will help... for great justice, vote Amy Guy to the W3C TAG!

Content Addressed Vocabulary

By Chris Lemmer-Webber on Wed 26 February 2020

How can systems communicate and share meaning? Communication within systems is preceded by a form of meta-communication; we must have a sense that we mean the same things by the terms we use before we can even use them.

This is challenging enough for humans who must share meaning, but we can resolve ambiguities with context clues from a surrounding narrative. Machines, in general, need a context more explicitly laid out for them, with as little ambiguity as possible.

Standards authors of open-world systems have long struggled with such systems and have come up with some reasonable systems; unfortunately these also suffer from several pitfalls. With minimal (or sometimes none at all) adjustment to our tooling, I propose a change in how we manage ontologies.

How we deal with ambiguous terms today

Consider Note, a seemingly simple term in ActivityStreams, the vocabulary used by ActivityPub. The meaning of Note, as described by the ActivityStreams vocabulary, seems simple enough: Represents a short written work typically less than a single paragraph in length.

Here is how an ActivityStreams usage of Note might look (a bit simplified from what it would probably look like in practice):

  {"@context": "",
   "@type": "Note",
   "content": "Would you read me a bedtime story about the great ontology wars?"}

What's that @context thing? This is some JSON-LD thing, which tries to be "more exact" about what Note we must be talking about. It does so by mapping Note to by something like the following:

  {"as": "",
   "Note": "as:Note",
   "content": "as:content",

The choice to use JSON-LD has been semi-controversial in ActivityPub land; historically there was some debate about whether or not we needed to be "more exact" at all as to what terms mean. This post really isn't about JSON-LD as much as it is the more general topic of vocabularies and vocabulary mapping systems. There are other concerns people raise about JSON-LD, usually around the tooling... that's not the scope of this post. This blogpost could as easily apply to XML or Turtle or whatever; the protocol I've worked on just happens to use JSON-LD to do that, so I've used it as my illustration.

That said, the ActivityPub spec tries to make things as simple as possible for the default case of ActivityPub usage by saying that the ActivityStreams context is implied, so that if you're not doing anything complicated, so:

  {"@type": "Note",
   "content": "Would you read me a bedtime story about the great ontology wars?"}

... is really the same as the first example.

So okay, probably everyone can guess what Note means, but what about sensitive? What the heck is that? It doesn't appear in the ActivityStreams vocabulary; it kind of implies something along the lines of content-warning type behavior, like "this content may be considered sensitive" by some users, but how would you guess that just by the term? This is an extension, and it lives at

So maybe if we were going to use it (and if we inline our context) it might look like:

  {"@context": {"as": "",
                "toot": "",
                "Note": "as:Note",
                "content": "as:content",
                "sensitive": "toot:sensitive"},
   "@type": "Note",
   "content": "Would you read me a bedtime story about the great ontology wars?",
   "sensitive": true}

(I mean, the Great Ontology Wars are a sensitive topic for some.)

The choice of JSON-LD in ActivityPub is controversial for various reasons. But it turns out what isn't really controversial anymore is whether we need some way of being more exact about the way we speak about terms... those who used to complain about that mostly now agree (disagreements then surround what tooling need to be used to do so (not in scope of this post), and namespace governance (in scope of this post)).

Maybe you feel like, having heard what sensitive and Note mean, these are the obvious definitions. But consider that Note itself could have meant something very different. Are we talking about a short mostly-textual post (probably on a microblog), as ActivityStreams does? Are we talking about a musical note? Are we instructing someone to take note of something, as an action (or yes, activity)?

So terms really are ambiguous, and in a decentralized but extensible system with open world assumptions, we are eventually going to result in conflicts. The choice to map our vocabulary to URIs is actually a very reasonable way to reduce ambiguity. Unfortunately, the choice to map them to namespaces and to live URIs (a-la http(s): URIs), is a mistake that will eventually bite us (and doubly so for JSON-LD contexts).

Problems appear

The first problem with choosing to put our terminology URIs at HTTP(S) URIs is that it assumes that those vocabularies will remain alive. Perhaps popular ones shall, but really the modern web rots all the time. Soon enough, many ontologies will eventually be replaced by Viagra ads.

The problem is dramatically worse for json-ld contexts (and similar documents such as XML DTDs): these are the very documents by which we map terms to their fully defined meanings. Servers get hammered by people looking up contextual mappings. This is no good already. It gets even worse when such documents add (or otherwise amend) their terminology mappings; old documents may suddenly mean different things!

(I'd be remiss to not note here that vocabulary namespaces and json-ld contexts are frequently the same URIs and yet frequently not the same thing. Still, they share a lot of the same problems and solutions in terms of liveness.)

Furthermore, both the choice to put terms in namespaces and the choice to have common contextual URIs that can change creates governance problems.

I know this from personal experience (and by that I mean many painful hours of my life wasted that I can never get back). Consider sensitive above. The Mastodon folks created their own namespace, as previously mentioned, but they didn't really want to. The good news was that the Social Web Community Group was given permission to both extend the ActivityStreams vocabulary and the official ActivityStreams context.

Despite the entire group agreeing that it made sense to make sensitive official in some way (which does not mean everyone agreed that it was a good term, just that it was in enough usage that we should make it more easily widely available), the SocialCG got tied up for months and months in meetings being unable to make progress about how to do so:

  • Should we add sensitive to the ActivityStreams namespace, or leave it in the old namespace but "officially sanction" it?
  • What is the migration path for software using the previous term URI?
  • How often should we do this? What is the governance process for incubating a new term? Should it happen in a separate namespace first and then get "pulled in" later?
  • What would happen if we didn't for terms like these, and the sites went down?
  • If we also update the json-ld context, what happens for documents that already had sensitive in them meaning either the old URI or a new one? This can have significant impact on normalization for signature verification.

The group met for months about all the topics above and came to no conclusions. Eventually we decided that no consensus could be reached, so instead no action was taken at all. What a disappointment.

In general, this seems to be common. Ironically, it leads to otherwise nice decentralized designs for vocabularies eventually ending up centralized in something like anyway.

Content addressed vocabularies (and contexts) are the answer

My friend Sandro Hawke offered a solution, which I initially rejected as terrible, decided upon further consideration was brilliant, and fully embraced. Then Sandro explained to me that I had totally misunderstood him, and that he meant something different. It turns out that I actually think my initial misunderstanding was the right answer.

Here's what I understood Sandro to say:

The name we choose for a term doesn't matter that much. What really matters is the paragraph or so of specification language that describes the term. If two implementations refer to the same specification text, they mean the same thing. So just use that as the description.

Once I (incorrectly) came to realize that this could mean naming via content addressing, I latched onto the idea. Of course! We had merely selected the wrong edge of Zooko's triangle. But we know how to fix that sort of thing.

Here's how it works. Let's remember the specification text for Note above: Represents a short written work typically less than a single paragraph in length. Let's hash that (along with a "recommendation" prefix that a user might choose to bind this to the term Note, though this is just a recommendation):

$ echo "Note: Represents a short written work typically less than a single paragraph in length." | sha256sum

So if we were defining Note via content-addressing, we instead would have defined it as urn:sha256:3e1de3b56d2dc1bee7313963462691f9a8f46b068557b75e0e0d14c0994eddc6. This is unambiguous enough to avoid collisions with other uses of the word "Note". But note that it doesn't require any servers staying up. It also doesn't have any namespace governance quagmire, because there is no namespace. Updates can be handled the usual way, via errata (translations can be handled similarly), and standards organizations can still publish such things... but it is important that the original term remain content-addressed and immutable. (Hash migration is left as an exercise for the user, with a hint that the solution is similar to that with errata.)

Anyway, our post might end up looking in the end like this instead:

  {"@context": {"Note": "urn:sha256:3e1de3b56d2dc1bee7313963462691f9a8f46b068557b75e0e0d14c0994eddc6",
                "content": "urn:sha256:57dc44a1cdcbb7aa976a65a858b4d349ad6110d58d9d546650ce2b0e2b1048e4",
                "sensitive": "urn:sha256:81d98cf83fcf733400ad5d2a25495feeea47f287193a53a9722f4cb025da88f1"},
   "@type": "Note",
   "content": "Would you read me a bedtime story about the great ontology wars?",
   "sensitive": true}

I'll note very briefly that content-addressing is also the answer for JSON-LD contexts. If something like Datashards or IPFS were used to host json-ld contexts, each post could link to the exact immutable content-addressed context it was intended to be used with. Servers that use such contexts can "pin" them to keep them available, avoiding a single point of failure (or bandwidth bottleneck).

  {"@context": "idsc:p0.JLnUcJN4R1KNvSXm9Ut3Tmg7WfXAKEOx47p01Pk_Htw.2_rCdtnEha1RpD_qyzxhFIjUvLj7crIbzpmzWei5xRk",
   "@type": "Note",
   "content": "Would you read me a bedtime story about the great ontology wars?",
   "sensitive": true}

As one other side-note, I'll also observe that even though the fully expanded version of the above message is:

  {"@type": "urn:sha256:3e1de3b56d2dc1bee7313963462691f9a8f46b068557b75e0e0d14c0994eddc6",
   "urn:sha256:57dc44a1cdcbb7aa976a65a858b4d349ad6110d58d9d546650ce2b0e2b1048e4": "Would you read me a bedtime story about the great ontology wars?",
   "urn:sha256:81d98cf83fcf733400ad5d2a25495feeea47f287193a53a9722f4cb025da88f1": true}

... we never needed to look at it that way because json-ld contexts (and systems like them) are actually petname systems.

Conclusions (and non-conclusions)

Let me clarify a claim I'm not making: we don't need to throw away the old terms for systems like ActivityStreams that are already well understood. However, going forward I do think that using content-addressing of new terms is a good idea. And in the long run, I think content-addressing of json-ld contexts and any documents like them is an absolute must (when they aren't inlined, anyway... but inlining is expensive).

If we adopted Content Addressed Vocabularies, working on vocabulary extensions to ActivityPub could be a different story. Imagine a git repository that communities can fork to work on new terms. We could have a drafts directory where people hammer out common extension terms, and when they're ready, we simply move them to the extensions directory. Since the names are merely hashes of the contents of that directory, statically generating a webpage that lists all current known and recommended extensions would be trivial. Everything could be handled in issues and PRs, and even if terms aren't merged into the main repo, that's merely a matter of lower term discoverability rather than a hinderance of application itself.

If we moved to content addressed vocabulary, we'd be more free from the perils of downtime and general web bitrot, freer from gatekeeping and governance challenges, but just as free (I'd argue even freer) to collaborate. Moving forward, I intend to ake content addressed approaches to terms I define in my systems, and I encourage you to do the same.

On standards divisions and collaboration (or: Why can't the decentralized social web people just get along?)

By Chris Lemmer-Webber on Thu 25 January 2018

A couple of days ago I wrote about ActivityPub becoming a W3C Recommendation. This was one output of the Social Working Group, and the blogpost was about my experiences, and most of my experiences were on my direct work on ActivityPub. But the Social Working Group did more than ActivityPub; it also on the same day published WebSub, a useful piece of technology in its own right which amongst other things also plays a significant historical role in what is even ActivityPub's history (but is not used by ActivityPub itself), and it has also published several documents which are not compatible with ActivityPub at all, and appear to play the same role. This, to outsiders, may appear confusing, but there are reasons which I will go into in this post.

On that note, friend and Social Working Group co-participant Amy Guy just wrote a reasonably and (to my own feelings) highly empathizable frustrated blogpost (go ahead and read it before you finish this blogpost) about the kinds of comments you see with different members of different decentralized social web communities sniping at each other. Yes, reading the comments is always a precarious idea, particularly on tech news sites. But what's especially frustrating is seeing comments that we either:

These comments seem to be being made by people who were not part of the standards process, so as someone who spent three years of their life on it, let me give the perspective of someone who was actually there.

So yes, first of all, it's true that in the end we pushed out two "stacks" that were mostly incompatible. These would more or less be the "restful + linked data" stack, which is ActivityPub and Linked Data Notifications using ActivityStreams as its core (but extensible) vocabulary (which are directly interoperable, and use the same "inbox" property for delivery), and the "Indieweb stack", which is Micropub and Webmention. (And there's also WebSub, which is not really either specifically part of one or the other of those "stacks" but which can be used with either, and is of such historical significance to federation that we wanted it to be standardized.) Amy Guy did a good job of mapping the landscape in her Social Web Protocols document.

Gosh, two stacks! It does kind of look confusing, if you weren't in the group, to see how this could have happened. Going through meeting logs is boring (though the meeting logs are up there if you feel like it) so here's what happened, as I remember it.

First of all, we didn't just start out with two stacks, we started out with three. At the beginning we had the linked data folks, the RESTful "just speak plain JSON" development type folks, and the Indieweb folks. Nobody really saw eye to eye at first, but eventually we managed to reach some convergence (though not as much as I would have liked). In fact we managed to merge two approaches entirely: ActivityPub is a RESTful API that can be read and interpreted as just JSON, but thanks to JSON-LD you have the power of linked data for extensions or maybe because you really like doing fancy RDF the-web-is-a-graph things. And ActivityPub uses the very same inbox of Linked Data Notifications, and is directly interoperable. Things did not start out as directly interoperable, but Sarven Capadisli and Amy Guy (who was not yet a co-author of ActivityPub) were willing to sit down and discuss and work out the details, and eventually we got there.

Merging the RESTful + Linked Data stuff with the Indieweb stuff was a bit more of a challenge, but for a while it looked like even that might completely happen. For those that don't know, Linked Data type people and Indieweb type people have, for whatever reason, historically been at each others' throats despite (or perhaps because of) the enormous similarity between the kind of work that they're doing (the main disagreements being "should we treat everything like a graph" and "are namespaces a good idea" and also, let's be honest, just historical grudges). But Amy Guy long made the case in the group that actually the divisions between the groups were very shallow and that with just a few tweaks we could actually bridge the gap (this was the real origin of the Social Web Protocols document, which though it eventually became a document of the different things we produced, was originally an analysis of how they weren't so different at all). At the face to face summit in Paris (which I did not attend, but ActivityPub co-editor Jessica Tallon did) there was apparently an energetic meeting over a meal where I'm told that Jessica Tallon and Aaron Parecki (editor of Micropub and Webmention) hit some kind of epiphany and realized yes, by god, we can actually merge these approaches together. Attending remotely, I wasn't there for the meal, but when everyone returned it was apparent that something had changed: the conversation had shifted towards reconciling differences. Between the Paris face to face meeting and the next one, energy was high and discussions active on how to bring things together. Aaron even began to consider that maybe Micropub (and/or? I forget if it was just one) Webmention could support ActivityStreams, since ActivityStreams already had an extension mechanism worked out. At the next face to face meeting, things started out optimistic as well... and then suddenly, within the span of minutes, the whole idea of merging the specs fell apart. In fact it happened so quickly that I'm not even entirely sure what did it, but I think it was over two things: one, Micropub handled an update of fields where you could add or remove a specific element from a list (without giving the entire changed list as a replacement value) and it wasn't obvious how it could be done with ActivityPub, and two, something like "well we already have a whole vocabulary in Microformats anyway, we might as well stick with it." (I could have the details wrong here a bit... again, it happened very fast, and I remember in the next break trying to figure out whether or not things did just fall apart or not.)

With the the dream of Linked Data and Indieweb stuff being reconciled given up on, we decided that at least we could move forward in parallel without clobbering, and in fact while actively supporting, each other. I think, at this point, this was actually the best decision possible, and in a sense it was even very fruitful. At this point, not trying to reconcile and compromise on a single spec, the authors and editors of the differing specifications still spent much time collaborating as the specifications moved forward. Aaron and other Indieweb folks provided plenty of useful feedback for ActivityPub and the ActivityPub folks provided plenty of useful feedback for the Indieweb folks, and I'd say all our specifications were improved greatly by this "friendly treaty" of sorts. If we could not unify, we could at least cooperate, and we did.

I'd even say that we came to a good amount of mutual understanding and respect between these groups within the Social Web Working Group. People approached these decentralization challenges with different building blocks, assumptions, principles, and goals... hence at some point they've encountered approaches that didn't quite jive with their "world view" on how to do it right (TM). And that's okay! Even there, we have plenty of space for cooperation and can learn from each other.

This is also true with the continuation of the Social Web Working Group, which is the SocialCG, where the two co-chairs are myself and Aaron Parecki, who are both editors of specifications of the conflicting "stacks". Within the Social Web Community Group we have a philosophy that our scope is to work on collaboration on social web protocols. If you use a different protocol than another person, you probably can still collaborate a lot, because there's a lot of overlap between the problem domains between social web protocols. Outside the SocialWG and SocialCG it still seems to be a different story, and sadly linked data people and Indieweb people seem to still show up on each others' threads to go after each other. I consider that a disappointment... I wish the external world would reflect the kind of sense of mutual understanding we got in the SocialWG and SocialCG.

Speaking of best attempts at bringing unity, my main goal at participating in the SocialWG, and my entire purpose of showing up in the first place, was always to bring unity. The first task I performed over the course of the first few months at the Social Working Group was to try to bring all of the existing distributed social networks to participate in the SocialWG calls. Even at that time, I was worried about the situation with a "fractured federation"... MediaGoblin was about to implement its own federation code, and I was unhappy that we had a bunch of libre distributed social network projects but none of them could talk to each other, and no matter what we chose we would just end up contributing to the problem. I was called out as naive (which I suppose, in retrospect, was accurate) for a belief that if we could just get everyone around the table we could reconcile our differences, agree on a standard that everyone could share in, and maybe we'd start singing Kumbaya or something. And yes, I was naive, but I did reach out to everyone I could think of (if I missed you somehow, I'm sorry): Diaspora, GNU Social, (well, they were already there), Hubzilla, Friendica, Owncloud (later Nextcloud)... etc etc (Mastodon and some others didn't even exist at this point, though we would connect later)... I figured this was our one chance to finally get everyone on board and collaborate. We did have Diaspora and Owncloud participants for a time (and Nextcloud even has begun implementing ActivityPub), and plenty of groups said they'd like to participate, but the main barrier was that the standards process took a lot of time (true story), which not everyone was able to allocate. But we did our best to incorporate and respond to feedback whever we got it. We did detailed analysis on what the major social networks were providing and what we needed to cover as a result. What I'm trying to say is: ActivityPub was my best attempt to bring unity to this space. It grew out of direct experiences from developing previous standards between OStatus, the Pump API, and over a decade of developing social network protocols and software, including by people who pioneered much of the work in that territory. We tried through long and open comment periods to reconcile the needs of various groups and potential users. Maybe we didn't always succeed... but we did try, and always gave it our best. Maybe ActivityPub will succeed in that role or maybe it won't... I'm hopeful, but time is the true test.

Speaking of attempting to bring unity to the different decentralized social network projects, probably the main thing that disappoints me is the amount of strife we have between these different projects. For example, there are various threads pitting Mastodon vs GNU Social. In fact, Mastodon's lead developer and GNU Social's lead developer get along just fine... it's various members of the communities of each that tend to (sounds familiar?) be hostile.

Here's something interesting: decentralized social web initiatives haven't yet faced an all-out attack from what would be presumably be their natural enemies in the centralized social web: Facebook, Twitter, et all. I mean, there have been some aggressions, in the senses that bridging projects that let users mirror their timelines get shut down as terms of service violations and some comparatively minor things, but I don't know of (as of yet) an outright attack. But maybe they don't have to: participants in the decentralized social web is so good at fighting each other that apparently we do that work for them.

But it doesn't have to be that way. You might be able to come to consensus on a good way forward. And if you can't come to consensus, you can at least have friendly and cooperative communication.

And if somehow, you can't do any of that, you just not openly attack each other. We've got enough hard work to fight to make the federated social web work without fighting ourselves. Thanks.

Update: A previous version of this article said "I even saw someone tried to write a federation history and characterize it as war", but it's been pointed out that I'm being unfair here, since the very article I'm pointing to itself refutes the idea of this being war. Fair point, and I've removed that bit.

ActivityPub is a W3C Recommendation

By Chris Lemmer-Webber on Tue 23 January 2018

Having spent the majority of the last three years of my life on it, I'm happy to announce that ActivityPub is now a W3C Recommendation. Whew! At last! Horray! Finally! I've written some more words on this over on the FSF's blog so maybe read that.

As for things I didn't put there, that fit more on a personal blog? I guess that's where I speak about my personal life experience and feelings about it and I would say they're a mix of elation (for making it), relief (also for making it, because it wasn't always clear that we would), and burnout (I had no idea this process was going to suck up so much of my life).

I didn't expect this to take over my life so thoroughly. I did say this bit on the FSF blogpost but when Jessica Tallon and I got involved in the Social Working Group we figured we were just showing up for an hour a week to make sure things were on track. I did think the goal of the Social Working Group was the right one: we had a lot of libre social networks but they were largely fractured and failed at interoperability... surely we could do better if we got everyone in a room together! (Getting everyone in the room wasn't easy and didn't always happen, though I sure as heck tried, particularly early on.) But I figured the other people in the room would be the experts, the responsible ones, and we'd just be tagging along to make sure our needs were met. Well, the next thing you know we're co-editors of ActivityPub, and that time grew from an hour a week to filling most of my week to sometimes urgent, grueling deadlines (granted, I made most of them a lot more complicated than I needed to be by doing example implementations in obscure languages, etc etc).

I'm feeling great about things now, but that wasn't always the case through this. I've come to learn how hard standards work is, and I've been doing other specification work recently too (more on that in a coming blogpost), but I'll say that for whatever reason (and I can think of quite a few, but it's not worth going into here), ActivityPub has been far harder than anything else I've worked on in the standards space. (Maybe that's just because it's the first standard I've gotten to completion though.)

In fact, in early-to-middle 2017 I was in quite a bit of despair, because it seemed clear that ActivityPub was going to not make it in time as an official recommended standard. The Social Working Group's charter was going to run out at mid-2017, and it had already been extended once... apparently getting a second extension was nearly unheard of. I resigned myself to the idea that ActivityPub would be published as a note, but that there was no way that we would be able to make it to getting the shiny foil stamp of being an actual recommended standard. Instead, I shifted my effort to making sure that my ActivityPub implementation work would support enough of ActivityStreams (which is what ActivityPub uses as its vocabulary) to make sure that at least that would make it as a standard with all the components we required, since we at least needed to be able to refer to that vocabulary.

But Mastodon saved ActivityPub. I'll admit that at first I was skeptical about all the hype I was hearing about Mastodon... but Amy Guy (co-author of ActivityPub, and whose PHD thesis, "Presentation of Self on a Decentralised Web", is worth a read at the memorable domain of convinced me that I really ought to check out what was going on in Mastodon land. And I found I really did like what was happening there... and connected to a community that felt like what I had missed from the heyday of StatusNet/, while having a bit of its own flavor of culture, one that I really felt at home in. It turned out this was good timing... Mastodon was having trouble expanding the privacy needs of its users on OStatus, and it turns out private addressing was exactly one of the reasons that ActivityPub was developed. (I'm not claiming credit for this, I'm just talking from my perspective... the Mastodon ActivityPub implementation issue can give you a better sense of where credit is due, and here I didn't really do much.) This interest came right at the right time... it began to also drum up interest from many other participants too... and it pretty much directly lead to another extension to the Social Working Group, giving us until the end of 2017 to wrap up the work on standardizing ActivityPub. Whew!

But Mastodon is not alone. Today there are a growing number of implementers of ActivityPub. I'd encourage you, if you haven't, to watch this video of PeerTube and Mastodon federating over ActivityPub. Pretty cool stuff! ActivityPub has been a massive group effort, and I'm relieved to see that all that hard work has paid off, for all of us.

Meanwhile, there's a lot to do still ahead. MediaGoblin, ironically, has fallen behind on its own federation support in the interest of advancing federation standards (we have some federation code, but it's for the old pre-ActivityPub Pump API, and it's bitrotted quite a bit) and I need to figure out what the next steps are and discuss with the community (expect more on that in the next few months, and sure to be discussed at my talk at Libreplanet 2018). And ActivityPub may be "done" in the sense that "it made it through the standards process", but some of the most interesting work is still ahead. The Social Web Community Group, of which I am co-chair, meets bi-weekly to talk and collaborate on the interesting problems that implementers of libre networks are encountering. (It's open to everyone, maybe you should join?)

On that note, in a recent Social Web Community Group meeting, Evan Prodromou was showing off some of his latest ActivityPub projects ( and I'm paraphrasing here, but he said something interesting, which has stuck with me: "We did all that standardizing work, and that's great, but now we get to the fun part... now we get to build things."

I agree. I look forward to what the next few years of fun ActivityPub development bring. Onwards!

DRM will unravel the Web

By Chris Lemmer-Webber on Mon 18 September 2017

I'm a web standards author and I participate in the W3C. I am co-editor of the ActivityPub protocol, participate in a few other community groups and working groups, and I consider it an honor to have been able to participate in the W3C process. What I am going to write here though represents me and my feelings alone. In a sense though, that makes this even more painful. This is a blogpost I don't have time to write, but here I am writing it; I am emotionally forced to push forward on this topic. The W3C has allowed DRM to move forward on the web through the EME specification (which is, to paraphrase Danny O'Brien from the EFF, a "DRM shaped hole where nothing else but DRM fits"). This threatens to unravel the web as we know it. How could this happen? How did we get here?

Like many of my generation, I grew up on the web, both as a citizen of this world and as a developer. "Web development", in one way or another, has principally been my work for my adult life, and how I have learned to be a programmer. The web is an enormous, astounding effort of many, many participants. Of course, Tim Berners-Lee is credited for much of it, and deserves much of this credit. I've had the pleasure of meeting Tim on a couple of occasions; when you meet Tim it's clear how deeply he cares about the web. Tim speaks quickly, as though he can't wait to get out the ideas that are so important to him, to try to help you understand how wonderful and exciting this system it is that we can build together. Then, as soon as he's done talking, he returns to his computer and gets to hacking on whatever software he's building to advance the web. You don't see this dedication to "keep your hands dirty" in the gears of the system very often, and it's a trait I admire. So it's very hard to reconcile that vision of Tim with someone who would intentionally unravel their own work... yet by allowing the W3C to approve DRM/EME, I believe that's what has happened.

I had an opportunity to tell Tim what I think about DRM and EME on the web, and unfortunately I blew it. At TPAC (W3C's big conference/gathering of the standards minds) last year, there was a protest against DRM outside. I was too busy to take part, but I did talk to a friend who is close to Tim and was frustrated about the protests happening outside. After I expressed that I sympathized with the protestors (and that I had even indeed protested myself in Boston), I explained my position to my friend. Apparently I was convincing enough where they encouraged me to talk to Tim and offer my perspective; they offered to flag them down for a chat. In fact Tim and I did speak over lunch, but -- although we had met in person before -- it was my first time talking to Tim one-on-one, and I was embarassed for that first interaction would me to be talking about DRM and what I was afraid was a sore subject for him. Instead we had a very pleasant conversation about the work I was doing on ActivityPub and some related friends' work on other standards (such as Linked Data Notifications, etc). It was a good conversation, but when it was over I had an enormous feeling of regret that has been on the back of my mind since.

Here then, is what I wish I had said.

Tim, I have read your article on why the W3C is supporting EME, and that I know you have thought about it a great deal. I think you believe what you are doing what is right for the web, but I believe you are making an enormous miscalculation. You have fought long and hard to build the web into the system it is... unfortunately, I think DRM threatens to undo all that work so thoroughly that allowing the W3C to effectively green-light DRM for the web will be, looking back on your life, your greatest regret.

You and I both know the dangers of DRM: it creates content that is illegal to operate on using any of the tooling you or I will ever be able to write. The power of DRM is not in its technology but in the surrounding laws; in the United States through the DMCA it is a criminal offense to inspect how DRM systems work or to talk about these vulnerabilities. DRM is also something that clearly cannot itself be implemented as a standard; it relies on proprietary secrecy in order to be able to function. Instead, EME defines a DRM-shaped hole, but we all know what goes into that hole... unfortunately, there's no way for you or I to build an open and interoperable system that can fit in that EME hole, because DRM is antithetical to an interoperable, open web.

I think, from reading your article, that you believe that DRM will be safely contained to just "premium movies", and so on. Perhaps if this were true, DRM would still be serious but not as enormous of a threat as I believe it is. In fact, we already know that DRM is being used by companies like John Deere to say that you don't even own your own tractor, car, etc. If DRM can apply to tractors, surely it will apply to more than just movies.

Indeed, there's good reason to believe that some companies will want to apply DRM to every layer of the web. Since the web has become a full-on "application delivery system", of course the same companies that apply DRM to software will want to apply DRM to their web software. The web has traditionally been a book which encourages being opened; I learned much of how to program on the web through that venerable "view source" right-click menu item of web browsers. However I fully expect with EME that we will see application authors begin to lock down HTML, CSS, Javascript, and every other bit of their web applications down with DRM. (I suppose in a sense this is already happening with javascript obfuscation and etc, but the web itself was at least a system of open standards where anyone could build an implementation and anyone could copy around files... with EME, this is no longer the case.) Look at the prevelance of DRM in proprietary applications elsewhere... once the option of a W3C-endorsed DRM-route exists, do you think these same application developers will not reach for it? But I think if you develop the web with the vision of it being humanity's greatest and most empowering knowledge system, you must be against this, because if enough of the web moves over to this model the assumptions and properties of the web as we've known it, as an open graph to free the world, cannot be upheld. I also know the true direction you'd like the web to go, one of linked data systems (of which ActivityPub is somewhat quietly one). Do you think such a world will be possible to build with DRM? I for one do not see how it is possible, but I'm afraid that's the path down which we are headed.

I'm sure you've thought of these things too, so what could be your reason for deciding to go ahead with supporting DRM anyway? My suspicion is it's two things contributing to this:

  1. Fear that the big players will pick up their ball and leave. I suspect there's fear of another WHATWG, that the big players will simply pick up their ball and leave.
  2. Most especially, and related to the above, I suspect the funding and membership structure of the W3C is having a large impact on this. Funding structures tend to have a large impact on decision making, as a kind of Conway's Law effect. W3C is reliant on its "thin gruel" of funding from member organizations (which means that large players tend to have a larger say in how the web is built today).

I suspect this is most of all what's driving the support for DRM within the W3C. However, I know a few W3C staff members who are clearly not excited about DRM, and two who have quit the organization over it, so it's not that EME is internally a technology that brings excitement to the organziation.

I suppose at this point, this is where I diverge with the things I could have said in the past and did not say as an appeal to not allow the W3C to endorse EME. Unfortunately, today EME made it to Recommendation. At the very least, I think the W3C could have gone forward with the Contributor Covenant proposed by the EFF, but did not. This is an enormous disappointment.

What do we do now? I think the best we can do at this point, as individual developers and users, is speak out against DRM and refuse to participate in it.

And Tim, if you're listening, perhaps there's no chance now to stop EME from becoming a Recommendation. But your voice can still carry weight. I encourage you to join in speaking out against the threat DRM brings to unravel the web.

Perhaps if we speak loud enough, and push hard enough, we can still save the web we love. But today is a sad say, and from here I'm afraid it is going to be an uphill battle.

EDIT: If you haven't yet read Cory Doctorow / the EFF's open letter to the W3C, you should.