I’ve been gradually getting involved in Sandstorm lately. I’m working on an app to idle in IRC for me, and in support of that I’ve been working on Go wrappers for the sandstorm Cap’n Proto APIs, and contributing a few things to the Go Cap’n Proto libraries/compiler plugin. There are some folks interested in running federated social networking apps (e.g. pump.io or GNU Social) on Sandstorm, and I agreed to write up a few notes about the challenges in getting those applications to run on Sandstorm, so that’s what this post is about. A lot of this is just questions; I haven’t had a chance to dig into things the way I’d like.

Background

First, a list of relevant bits of software, standards and protocols that I’m aware of. This is probably incomplete.

Software:

• GNU Social, which used to be called Status.net. It’s basically a twitter clone, and used to power identi.ca. Some folks on the mailing list seem to be interested in this. I’m somewhat less than excited about it myself, but the reasons for that are a rabbit hole that deserve their own post, if I’m to write about them.
• Pump.io, which is basically a message bus for ActivityStreams. identi.ca seems to be an instance of this now, which isn’t surprising since they’re both Evan Prodromou’s babies, and my impression is he’s mostly moved on from Status.net/GNU Social.
• GNU Mediagoblin. There’s already a sandstorm port for this, which I haven’t looked at in detail, but when I spoke with Christine Lemmer Webber at Libreplanet this past March, Federation was still “We’re working on it,” so my suspicion is that the Sandstorm package at present won’t provide a heck of a lot of insight on this matter (yet). I could be wrong.

Standards/Protocols:

• The W3C’s Social Web Working Group is working on a handful of protocol standards. From what I can tell everything is still in draft mode. The full list is on that page; here I’ll only discuss the bits I’ve poked at and had time to consider:
  • ActivityPub is an iteration on the protocol used by pump.io, with some lessons learned.
  • Webmention is a fairly simple protocol meant to fill the same niche as Pingback, but without the XML-RPC (thank god). It lets compliant websites find out when other sites are linking to them. I’ve got some ideas on using this as part of a federated bug tracker to do cross-referencing of issues, but that’s it’s own post.
• Way back in the day there was a protocol called OStatus, which Status.net/GNU Social was using. I know GNU Social still supports it. What I don’t know is whether GNU Social supports anything else. My memory is that it isn’t fundamentally different in its design from ActivityPub, though the details differ, and ActivityPub seems simpler. OStatus was cobbled together from a handful of existing protocols (PubSub, salmon, and a few others), and when I first dug into the specs I remember feeling like there was an awful lot of reading to do to understand where everything was.
• Webfinger is (roughly) a protocol for looking up social networking details of a user by something that looks like an email address. It’s used by ActivityPub (and the current pump.io protocol). It’s also an optional part of OpenID connect. While the protocol is nice and simple, there’s what I consider a pretty glaring (though not fatal) design flaw that makes things awkward for sandstorm, and has slowed adoption a bit (more on that later). Webfist is intended to make adoption a bit easier.

Implications for Sandstorm

First, some very concrete challenges:

• Social web protocols generally require some discoverability for resources. Webfinger is likely enough to bootstrap this in many cases, but right now a user wishing to use this as a solution would have to host Webfinger somewhere other than their sandstorm instance. Sandstorm doesn’t have a great way of giving things memorable URLs in general. It provides static publishing, but this doesn’t work for Webfinger, since it requires the use of a resource query parameter. This is the design flaw I mentioned earlier; the inability to implement it using only static pages makes it harder for users to set it up themselves.
• The Webmention spec expects implementations to check that pages claiming to link to them actually do. The approach to this is to simply grab the page and search it for links. My suspicion is that Sandstorm’s UI will cause problems for this; most applications supporting Webmention will choke on the iframe/JavaScript page, and probably reject the (apparently absent) link. At present, Apps using Webmention would have to use static publishing or otherwise route around the sandstorm UI to make this work.

I’m sure there are more.

There’s also a big conflict in approach that I expect to cause a lot of friction: Sandstorm takes a hard line on the principle of least priviledge. In contrast, what I’ve read of the federated social networking protocols doesn’t demonstrate much sophistication when it comes to security. Indeed, when I spoke to a handful of the W3C working group members at Libreplanet, I asked them about what their thoughts were on how to deal with some authorization use cases that I’d been puzzling over, and basically got “authorization is still something we’re thinking about.” There’s some basic sanity checks in the ActivityPub spec, but the last time I looked at it (a few weeks ago) it didn’t really provide much guidance on security issues. Security isn’t something that’s easy to bolt on to existing protocols, so this has me worried.

When I get the chance I’d like to dig into things a bit more and write a better-researched post, but these are my initial impressions.