thesis/chapter4.html at gh-pages · rhiaro/thesis

History

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

<!DOCTYPE html>

<head>

<title>Decentralising the Social Web</title>

<style>

h1:before {

content:"Chapter 4\A" !important;

white-space:pre;

font-size:0.75em;

}

</style>

</head>

<main>

<h1 property="schema:name">Decentralising the Social Web <br/>(and other stories)</h1>

<p>Given the large influx of new users into the fediverse, you may be unaware of the tradition that we all vehemently hate each other and refuse to work with each other because the other guy is a twat.</p>

<p>If you use Hubzilla, you hate Diaspora, Ostatus, and RedMatrix.</p>

<p>If you use RedMatrix, you hate Hubzilla.</p>

<p>If you use Diaspora, you hate Friendica, Hubzilla, and RedMatrix.</p>

<p>If you use Friendica, you hate Diaspora.</p>

<p>If you use ostatus, you hate everyone else who uses ostatus.</p>

<p>This is the law of the fediverse, please bear this in mind. When picking fights with random strangers, make sure it's always based on nothing other than their software choices.</p>

<p>This has been a public service announcement on behalf of the fediverse. Thank you, and good day. </p>

<p> - Thomas Willingham, decentralised Social Web developer. <a href="https://soc.beardyunixer.com/display/0c5b5b901858fce51629a5e267815437">Posted on Friendica, seen through Mastodon</a></p>

</blockquote>

<h2>Introduction</h2>

<div>

<p>The previous two chapters had social-science leanings, in both the literature surveyed and the studies carried out. This chapter marks the beginning of the more technology-focused half of the thesis. It is necessary to define jargon, discuss software specifications, and talk about the details of specific technologies used in particular systems. This is where I try to align my theoretical findings with outcomes that are practical and meaningful for software architects and developers.</p>

<p>First of all, this chapter presents a survey of decentralised social systems: systems which store data about a person, their attributes and activities, and encourage sharing of this data and interactions with others in the network. These systems are analysed along various axes to determine their intended function, fitness for purpose and how they are or were ultimately used and to what extent. The core focus is on treatment of individuals as users of or participants in a system, and I classify systems according to their approach to handling user identities and profile data. I derive modules of decentralised social systems and the contexts in which they are likely to work well and benefit users; I also attempt to identify gaps and common pitfalls in existing theoretical and practical work.</p>

<p>I finish by describing the most recent work (still ongoing at the time of writing) of the W3C Social Web Working Group, which is producing standards for decentralised social interactions on the Web.</p>

<h3>Scope</h3>

<div>

<p>I would love for this chapter to be a complete history of decentralised social networks, but that would take many years to research and write. There exist many partial histories, glimpses into the past through the lens of some masters thesis or an ancient blog post found through archive.org by someone who was There At The Time. These people are even around today, and could be interviewed, if one was so inclined. Efforts towards decentralising social networks have been going on for as long as there have been social networks, and making use of a wide variety of different technologies, such as SMTP, XMPP, peer-to-peer architectures and the Blockchain. Many efforts in academic, commercial or FOSS environments are driven by producing secure private systems (ie. keeping messages transmitted over the network hidden from all but the sender and recipient), or by producing optimised, fast, highly scalable architectures.</p>

<p>Given the topic of this thesis, I constrain the contents of this chapter in two ways:</p>

<ul>

<li>to systems on the Social <em>Web</em>; that is, which operate over HTTP, and</li>

<li>to reports which center the 'user' as a human being, rather than a node; that is I will not cover projects which focus on a purely network architecture perspective.</li>

</ul>

<p>For broader or differently-scoped surveys of the decentralised social networking space, as well as the motivations for pursuing this work and advantages and drawbacks of various approaches, see [<a href="appendices#ref-Datta2010DecentralizedOS">Datta2010DecentralizedOS</a>, <a href="appendices#ref-dcent">dcent</a>, <a href="appendices#ref-halpin16">halpin16</a>, <a href="appendices#ref-incubator">incubator</a>, <a href="appendices#ref-88-projects">88projects</a>, <a href="appendices#ref-survey14">survey14</a>, <a href="appendices#ref-crit12">crit12</a>, <a href="appendices#ref-taxonomy15">taxonomy15</a>].</p>

</div>

</section>

<h3>Decentralisation</h3>

<div>

<p>Decentralisation is a fairly contentious term with different definitions or understandings depending on the background of the person talking about it. In this thesis, I use the definition from [<a href="appendices#ref-halpin16">halpin16</a>]:</p>

<blockquote><p>A system in which multiple authorities control different components and no single authority is fully trusted by all others. Decentralized systems are a subset of distributed systems.</p></blockquote>

<p>This differentiates decentralised systems from <em>distributed</em> systems, which are not necessarily decentralised, in that the latter "may be managed by a single root of trust or authority."</p>

</div>

</section>

<h3>Social systems</h3>

<div>

<p>I defined the type of social system I am interested in in Chapter 3, and repeat it here for convenience:</p>

<p>Social systems: Web-based networked publics which offer individuals consistent and reusable access to an account which they can customise and use to interact in some form with others in the system.</p>

</blockquote>

<p>Other concepts which will be useful throughout this chapter are:</p>

<dl>

<dt><p><strong>Protocol</strong></p></dt>

<dd><p>A set of possible communication actions between computer systems.</p></dd>

<dt><p><strong>Implementation</strong></p></dt>

<dd><p>A piece of software, possibly designed according to a protocol.</p></dd>

</dl>

<dt><p><strong>Instance</strong></p></dt>

<dd><p>An implementation which has been installed and is running somewhere, probably a server. One implementation can have many instances.</p></dd>

<dt><p><strong>Federation</strong></p></dt>

<dd><p>The joining together of software instances such that activities on one are seen on another (usually by means of a protocol).</p></dd>

</dl>

</div>

</section>

<h3>Selection method</h3>

<div>

<p>There are numerous wiki pages and blog posts which list decentralised social systems<sup><a href="#fn-lists">lists</a></sup>, and academic literature reviews, and project reports which reference related work. I followed links to all projects listed (performing additional Web searches for information if necessary) and performed an exhaustive search on the literature through reading reference lists until I was no longer seeing new citations on the relevant topics. I excluded projects which are out of <a href="#scope">scope</a>; which are clearly abandoned (or have an unknown status) with no public information or documentation; which claim a desire to federate in the future but haven't actually achieved it; and projects which have pivoted in a different direction.</p>

<p>There are a great deal of abandoned projects in this space, spanning more than a decade. It is my hope that one day I or someone else manages to locate their founders and conduct a more thorough post-mortem.</p>

<p>I have, however, included projects which have wound down or are no longer actively maintained if they still provide documentation or blog posts about the work, and ideally running instances are still available, as these are still worthwhile to learn from. As a result, there may be some bias towards abandoned academic projects, since these are fairly well documented in peer-reviewed literature.</p>

<p id="fn-lists"><sup>lists</sup>

<a href="http://benwerd.com/2010/06/04/building-a-distributed-social-network-youre-doing-it-wrong/">A Distributed Social Network: You're Doing It Wrong (benwerd.com)</a>,

<a href="https://en.wikipedia.org/wiki/Comparison_of_microblogging_services">Comparison of microblogging services (wikipedia)</a>,

<a href="https://en.wikipedia.org/wiki/Comparison_of_Internet_forum_software">Comparison of Internet forum software (wikipedia)</a>,

<a href="https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients">Comparison of instant messaging clients (wikipedia)</a>,

<a href="https://en.wikipedia.org/wiki/Comparison_of_software_and_protocols_for_distributed_social_networking">Comparison of software and protocols for distributed social networking (wikipedia)</a>,

<a href="https://en.wikipedia.org/wiki/Social_networking_service">Social networking service (wikipedia)</a>,

<a href="https://en.wikipedia.org/wiki/Social_software">Social software (wikipedia)</a>,

<a href="https://en.wikipedia.org/wiki/List_of_social_networking_websites">List of social networking websites (wikipedia)</a>,

<a href="https://en.wikipedia.org/wiki/List_of_defunct_social_networking_websites">List of defunct social networking websites (wikipedia)</a>,

<a href="https://en.wikipedia.org/wiki/Comparison_of_social_networking_software">Comparison of social networking software (wikipedia)</a>,

<a href="https://www.w3.org/2005/Incubator/federatedsocialweb/wiki/Platforms">Federated Social Web Platforms (w3.org)</a>,

<a href="http://indieweb.org/project">Projects (indieweb.org)</a>

</p>

</aside>

</div>

</section>

</div>

</section>

<h2>When is a person not a person?</h2>

<div>

<p>Identity and reference are a critical part of broader Web architecture [<a href="appendices#ref-websci">websci</a>, <a href="appendices#ref-halpinthesis">halpinthesis</a>], and in some systems built on top of the Web, this distinction matters. This topic was the subject of the infamous 'httpRange-14' issue debate, a lengthy discussion (over a decade of W3C mailing lists exist) and a supposed resolution about the <em>meaning</em> of an HTTP URI. </p>

<!--Contextualise this better, why is it relevant?

When there's a difference between if people are people or profiles and systems disagree, this is problematic for interop.

Signpost as background for technical stuff.

Background for technical development context.-->

<p>Q: When is a person not a person?</p>

<p>A: When they're a document. </p>

<p>HTTP URIs can be used to represent both Web-based documents (information resources, IRs) - which can be transported over HTTP - and everything else (non-information resources, NIRs, like people and places) [<a href="appendices#ref-http14">http14</a>]. The latter, needless to say, cannot be transported over HTTP (yet). In this case, some systems separate <em>people</em> from the <em>documents about</em> them by using fragment URIs (fragments aren't passed to servers, so the server can only return the resource represented by the URI up to and not including the fragment) or 303 redirects (the server says "sorry this URI identifies a NIR which I can't return, so I have to send you to an IR about it instead").</p>

<p>Not all systems make this distinction however. For some, conflating metadata about a webpage and metadata about a person is simply not a problem, or not one worth solving. However, when we are thinking about federated systems, architectural differences in data models like this may cause interoperability problems. The <a href="chapter3#profiles-taxonomy">representation feature</a> of profile-hosting systems which was elicited in the first study of the previous chapter demonstrates some variations in how people and profiles are modeled in various contemporary social systems.</p>

<p>Other ways systems vary their data models are by using different vocabularies and syntaxes. In many cases, open data models for representing people and their activities within social networks have been created over the years independently of software implementations that use them, and are sometimes picked up by separate projects. Common vocabularies, or mappings between them, significantly <em>improves</em> interoperability options. The following are well known, and may be referred to as in-use by other protocols or implementations throughout the remainder of this chapter:</p>

<ul>

<li>FOAF: An RDF vocabulary with various properties for representing attributes of people, as well as the links between them using the <code>knows</code> predicate. A cornerstone of any Semantic Web based social projects [<a href="appendices#ref-foaf14">foaf14</a>].</li>

<li>Relationships: An extension to FOAF to provide more granular relationships than <code>knows</code> [<a href="appendices#ref-foafship">foafship</a>].</li>

<li>SIOC: An RDF vocabulary for representing online discussions, such as blogs, forums and mailing lists. Complements FOAF [<a href="appendices#ref-Passant2010">Passant2010</a>].</li>

<li>vCard:A standard for representing attributes of a person that might be found on a business card. A common export format from email clients and mobile address books, and the core of many 'contacts' type applications [<a href="appendices#ref-vcard">vcard</a>].</li>

<li>Atom: An XML based standard for representing streams of content from blogs [<a href="appendices#ref-atom">atom</a>].</li>

<li>ActivityStreams 1.0: An XML or JSON syntax for representing social interactions as activities, which consist of <code>actor</code>, <code>verb</code>, <code>object</code>, and <code>target</code>, as well as other more domain-specific properties; widely deployed, in particular as part of the OStatus stack. Predecessor to ActivityStreams 2.0 [<a href="appendices#ref-as1">as1</a>].</li>

<li>microformats2: A set of classes which can be used with HTML elements to provide semantics about the value of the element. The classes cover types and properties for a core set of social objects (eg. people, organizations, events, locations, blog posts, products, reviews, resumes, recipes) as well as a specification for how to parse them. Built on vCard. [<a href="appendices#ref-mf">mf</a>].</li>

<li>XHTML Friends Network (XFN): A set of values for the HTML4 <code>rel</code> attribute which indicate a relationship between the person who created the link and the person being linked to (eg. "met", "coworker", "parent") [<a href="appendices#ref-xfn">xfn</a>]. Works with microformats2. This one is not bothered by httpRange-14, ie. my homepage can be friends with your homepage.</li>

</ul>

</div>

</section>

<h2>Standards and monocultures</h2>

<div>

<p>Certain more modular (ie. only do one thing) open standards are used by multiple projects. I describe them here for convenience (references are therefore not inline when they are mentioned again):</p>

<ul>

<li>Webfinger: is a discovery mechanism for user profiles using the <code>.well-known</code> URL pattern and <code>user@domain.tld</code> style identifiers [<a href="appendices#ref-webfinger">webfinger</a>].</li>

<li>WebID+TLS: an authentication mechanism that uses FOAF files and browser certificates [<a href="appendices#ref-foaftls">foaftls</a>].</li>

<li>OAuth 2: a commonly used authentication mechanisms which uses bearer tokens [<a href="appendices#ref-oauth2">oauth2</a>].</li>

<li>JSON-LD: a JSON syntax for RDF [<a href="appendices#ref-jsonld">jsonld</a>].</li>

<li>Semantic Pingback: a federation protocol which alerts a resource when it has been linked to on the Web [<a href="appendices#ref-sp">sp</a>].</li>

<li>PubSubHubbub: a federation protocol for subscribing to publishers and delivering content to subscribers [<a href="appendices#ref-push10">push</a>].</li>

<li>Salmon: a federation protocol for passing responses to decentralised threaded conversations 'upstream' so the originator of the conversation is notified [<a href="appendices#ref-salmon">salmon</a>].</li>

</ul>

<p>Some projects publish the specifications of their systems as protocols that anyone can implement. Projects which publish their protocols and state their intent to have interoperability across multiple independent projects, but in practice have few distinct implementations, include Tent [<a href="appendices#ref-tent">tent</a>] and RemoteStorage [<a href="appendices#ref-rs">rs</a>]. The latter bundles Webfinger, OAuth 2.0, JSON-LD and HTTP REST, together with a thin layer of additional requirements, and is published as an IETF draft [<a href="appendices#ref-rsietf">rsietf</a>]. Hubzilla [<a href="appendices#ref-hubz">hubz</a>] (a fork? of Friendica) publish the Zot! protocol [<a href="appendices#ref-zot">zot</a>], but it isn't clear there is uptake outside of Hubzilla implementations.</p>

<p>Implementations may be assembled from an existing set of more modular protocols. SMOB (Semantic Microblog) [<a href="appendices#ref-passant2010rethinking">smob</a>] and DSSN [<a href="appendices#ref-dssn14">dssn</a>] are based on Semantic Web technologies, and use overlapping vocabularies for their data, but different mechanisms for content creation and federation. SMOB uses RDFa in published content, and propagates updates throughout the network with SPARQL/Update and HTTP POST requests. DSSN and OpenLink Open Data Spaces (ODS) [<a href="appendices#ref-ods">ods</a>], both use WebID, FOAF, Semantic Pingback and PubSubHubbub. ODS is additionally LDP [<a href="appendices#ref-ldp">ldp</a>] (for content reading and writing) and LDN [<a href="appendices#ref-ldn">ldn</a>] (for notifications) compatible.</p>

<p>In some cases, existing sets of protocols have been identified and documented as complimentary. One example is OStatus [<a href="appendices#ref-ostatus">ostatus</a>], which combines Atom, ActivityStreams, PubSubHubbub, Salmon and Webfinger. OStatus has several independent implementations listed on its Wikipedia page at the time of writing, including GNU Social (previously StatusNet) and Mastodon, both of which there are hundreds to thousands of instances. Another is Solid [<a href="appendices#ref-solid">solid</a>], which uses LDP, WebID+TLS, FOAF and Web Access Control [<a href="appendices#ref-wac">wac</a>].</p>

<p>Conversely, some projects cultivate monocultures, either by not publishing their protocols at all or by gaining little adoption outside of a single core implementation. In computing, a monoculture is when a group of computers all run the same software. Several FOSS Social Web projects meet this description, with large and active developer communities who all contribute to the same codebase (Pump.io [<a href="appendices#ref-pump">pump</a>], NextCloud [<a href="appendices#ref-nextc">nextc</a>], Friendica [<a href="appendices#ref-friendica">friendica</a>], Hubzilla). One particular piece of software is expected to be downloaded and installed on multiple different servers, and different instances can interoperate with each other so it runs in a decentralised manner. This has the advantage that, assuming a straightforward setup process, new instances can be set up quickly and easily, aiding adoption. However, a security vulnerability in the core code base would be present across all instances; there is overhead for developers working on the project to agree its direction and realisation; and focusing on this type of architecture can mean that optimisations for same-software interoperability come at the expense of potentially more open protocols, as is the case with diaspora* [<a href="appendices#ref-dcent">dcent</a>]. Monocultures can emerge when one implementation of an open protocol is particularly successful; an example is Known [<a href="appendices#ref-known">known</a>], which implements the open standards Micropub [<a href="appendices#ref-mp">mp</a>] and Webmention [<a href="appendices#ref-wm">wm</a>] but also has an easy setup process, good community support, and a for-profit company behind it which has driven wide adoption through managed and white-labelled instances for educational institutions, massively increasing the dependence upon a single codebase.</p>

<p>Friendica is based on DFRN [<a href="appendices#ref-zot">zot</a>], but has code which bridges to a wide variety of decentralised protocols, including OStatus and diaspora*, as well as the APIs of centralised services. Systems like diaspora* and GNU Social are moving in this direction too, desiring to federate with instances of software implementing totally different (or, sometimes overlapping) protocols.</p>

</div>

</section>

<h2>Social (and) personal datastores</h2>

<div>

<p>Research into Personal Data Stores (PDS) spans back a long way in the Personal Information Management Systems (PIMS) field. Once a PDS can communicate with another PDS, grant access to a third-party, or PDS owners are able to spread their data around across multiple separate systems or instances, we find many parallels with decentralised social networking [<a href="appendices#ref-crit12">crit12</a>]. MyDex [<a href="appendices#ref-mydex">mydex</a>] is a commercial offering which provides software to organisations who wish to securely hold data on behalf of their customers. With an emphasis on consent-based data sharing through their proprietary API, datastore owners can authorise trusted third-parties to access their data in exchange for a useful service. indx (previously known as WebBox) [<a href="appendices#ref-vkpds">vkpds</a>, <a href="appendices#ref-vkpds14">vkpds14</a>, <a href="appendices#ref-indx">indx</a>] is similar, but based on Web standards rather than proprietary technology; it is expected that individual users will host their own instances rather than relying on a provider (and an academic rather than commercial project). PrPl [<a href="appendices#ref-prpl10">prpl</a>] on the other hand indexes personal data aggregated from other services, and provides a 'Personal Cloud Butler' to negotiate data sharing with other parties who may be able to provide something in return. Data is indexed with RDF, but they created a new query language (SociaLite) for federating and searching across instances. The team behind PrPl outline a deployment plan which uses devices already existing in people's homes such as media centers to allow self-hosting with low setup cost.</p>

<p>NextCloud (the actively maintained fork of ownCloud) is a free and open source PDS which lets users manage files and media as well as data such as calendars and contacts. Social features such as file sharing, tagging, and commenting are possible across separate instances of NextCloud through the OCS (<a href="http://open-collaboration-services.org/ocs/">Open Collaboration Services</a>) federation API. NextCloud provides hosted services, as well support for self-hosted instances. OpenLink Open Data Spaces (ODS) is similarly hosted and for similar purposes; it is developed by a commercial organisation, and instances federate using existing open standards.</p>

<p>The RemoteStorage protocol provides users with the opportunity to trust their data to a third-party provider, or to set up an instance of the software on their own server. It is a grassroots rather than commercial effort, and intended as a generic personal data store. Solid is an open source project with its roots in academia; multiple server implementations exist, and are known as PODS (Personal Online Data Stores). The data stores are generic, with little logic built into the servers, and use a combination of existing open standards with small specialisations to communicate with other instances by means of smart client applications and access control rules.</p>

<p>The data stored in a PDS may be distinctly personal, shared with third-parties only in specific contexts for a particular purpose (eg. sharing medical data with a doctor's office); or it may be inherently social, expected to be broadcast on creation to at least one other person and possibly subject to further reshaping, sharing, and propagation throughout a network of people. Many datastores are optimised for one or the other of these scenarios and may place constraints on their users accordingly. Others, in particular RemoteStorage and Solid, attempt to meet requirements for both types of use and encounter different implementation and usability challenges as a result.</p>

</div>

</section>

<h2>From status updates to microblogging, and beyond</h2>

<div>

<p>Many systems are designed with the emphasis on social networking over personal data storage. Even systems which emphasis privacy or access control are still inherently about sharing content through a network. Several of these attempt to replicate the functionality of centralised SNS, and a common focus was around the 'status update' feature of the likes of Facebook. Twitter, with its continuous feeds of short posts, changed the discourse somewhat to 'microblogging'. SMOB augments ordinary text publishing with machine-readable metadata, tags as links to other concepts on the Web, and data portability through RDF. [<a href="appendices#ref-passant2010rethinking">smob</a>] describes microblogging as a "hybrid of blogging, instant messaging, and status notifications."</p>

<p>The original 'Twitter clone' was StatusNet, an implementation of the OStatus protocol which is now known as GNU Social. Mastodon is another OStatus implementation, and pump.io has the same origins. Friendica, Hubzilla, diaspora* [<a href="appendices#ref-diaspora">diaspora</a>] and Known provide similar user interfaces for posting to and reading from a timeline of notes, articles and messages from the profiles you friend or follow, but each use different (combinations of) protocols to pass content between instances. The architecture of Tent is also based on passing around 'posts' (pieces of text with various metadata).</p>

<p>Now, many centralised services offer different types of updates, like check-ins, or multimedia sharing experiences, and decentralised social networks are somewhat lagging behind on that front. The most advanced in terms of media is <a href="http://mediagoblin.org/">MediaGoblin</a>, an implementation of pump.io specifically oriented around sharing images and video. Known also provides different 'post types' such as audio and location. DSSN is similar to SMOB in that it is based on Semantic Web technologies, however the reference implementation is integrated into Semantic Media Wiki, so users see changes to wiki pages federated between instances, rather than status updates.</p>

<p>The types of content which social networks enable users to create is pertinent to understanding the self-presentation possibilities of profiles within certain systems. Decentralised systems which cannot accommodate a wide variety of types of content or interaction may in the end not meet users' needs for expressiveness. Leaning on extensible technologies and protocols could be one way to ease customisation of basic systems by communities with particular needs.</p>

</div>

</section>

<div>

<p>A common focus of decentralised Social Web projects is decoupling application logic from data storage. Whilst most of the protocols have client-to-server APIs which would technically allow this architecture (like Pump.io), they don't necessarily focus on it as a strength; others however are designed specifically around this model.</p>

<p>RemoteStorage servers are developed by the same community behind Unhosted web apps [<a href="appendices#ref-unhosted">unhosted</a>], at the core of which is the idea that applications should run entirely in the browser so that the entire source code of the application is made available to the user; they can download it and run it locally if desired, and have no need to depend on a third party to run the service. This alone has limited use as data cannot be persisted, so coupling these kinds of Web apps with RemoteStorage servers allows users to authenticate with their own datastore and have the application operate on their data, without the application developer processing that data at a third-party, potentially untrusted, server. The Unhosted community provide several sample applications and a JavaScript library to help with app development.</p>

<p>Solid works in a similar manner, with the explicit aim to reduce the logic of a server, making them simple storage devices which can write data and serve it up again. Applications are expected to be smart, including managing access control for resources. Data is stored on the servers as RDF, so applications using shared vocabularies can reuse the same data, giving users even more freedom of choice. Again, the core Solid team are developing sample applications and helper libraries to encourage development of applications by others. OpenLink ODS has several protocols in common with Solid, and there is at least one clientside application (<a href="https://dokie.li">dokieli</a>) which works with both Solid PODS and ODS datastores [<a href="appendices#ref-do-ods">do-ods</a>, <a href="appendices#ref-solid">solid</a>]. PrPl is similar, describing the potential of empowering users through choice of applications. </p>

<p>NextCloud encourages community development of applications which operate on user data, but these exist as plugins to the NextCloud architecture so they're a little more tightly coupled. SMOB, indx and Tent also purport to prefer this kind decoupled-application of architecture, however I was unable to find samples or galleries of applications which have been developed to work with the accompanying servers, and these projects are now largely retired.</p>

<p>There is some overlap between the mindset behind the PDS-type systems and the decoupled-application architectures. Where client-to-server APIs exist for systems like Pump.io, diaspora* and GNU Social, these are typically employed to build applications on different platforms (ie. desktop and native mobile clients for different operating systems) rather than with the idea that multiple Web apps should exist to do different things with the same data stored on someone's instance. This is perhaps due to the broader notion of what kinds of data are stored on a server for PDSs compared to more focussed microblogging and social sharing sites.</p>

</div>

</section>

<!-- <section id="the-people-in-the-machines" rel="schema:hasPart">

<h2>The people in the machines</h2>

<div>

<p>Background on how identity fits into these systems and related standards work. Typically for authentication and access control, with representation of user secondary or not covered. What’s missing to do with profiles/people from previous and current identity-related standards work? What problems has this caused? (Critique also based on findings in chs 2 & 3.)</p>

<p>diaspora* aspects. Friendica whatjamacallits. Everything else zzzz</p>

</div>

</section> -->

<h2>The Social Web Working Group</h2>

<div>

<p>[<a href="appendices#ref-crit12">crit12</a>] advocates for open standards, not as the solution to decentralisation problems, but as a prerequisite for interoperability success. Standards "needs serious developer commitment as well as the involvement of standards bodies with significant authority."</p>

<p>Ultimately, the Social Web Working Group has produced the following recommendations:</p>

<ul>

<li>ActivityStreams 2.0 Core and Vocabulary: A JSON data model and syntax for social content and interactions, with extensibility based on JSON-LD.</li>

<li>ActivityPub: An API for creating content, delivering notifications, and managing common side-effects of interactions within social networks, based on ActivityStreams 2.0.</li>

<li>Linked Data Notifications: An API for delivering and reusing generic notifications, based on JSON-LD.</li>

<li>Micropub: An API for creating content, based on microformats2.</li>

<li>Webmention: An API for delivering notifications when a resource on the Web refers to the URL of another.</li>

<li>WebSub: An API for managing and fulfilling subscription requests to Web content (formally known as PubSubHubbub).</li>

</ul>

<p>And the following Working Group notes:</p>

<ul>

<li>JF2: An alternative JSON syntax and vocabulary for representing social objects, based on microformats2.</li>

<li>Post-type Discovery: An algorithm for converting between implicitly typed social objects (like JF2) to explicitly typed ones (like ActivityStreams 2.0).</li>

<li>Social Web Protocols: A guide to the specifications produced by the group, including how they overlap or complement each other.</li>

</ul>

<h3>Implementations</h3>

<div>

<p>Each of the recommendations has received a number of implementations during the Working Group's lifetime. Some were formally submitted to the Working Group as implementation reports whilst the specifications were undergoing review. This section briefly describes the implementations to date, and notes relationships to work previously described in this chapter where applicable.</p>

<p>ActivityStreams 2.0 has a number of publishing and consuming implementations by members of the Social Web Working Group and the Web Annotations Working Group (who rely on one portion of the AS2 model for their Annotations Vocabulary). There is ongoing work in upgrading ActivityStreams 1.0 implementations to AS2.</p>

<p>Webmention and Micropub have a number of implementations from the IndieWeb (https://indieweb.org) community, which is were these specifications were incubated prior to being standardised by the Working Group. The implementations span a variety of different programming languages; many are part of people's personal websites, but there are also implementations in the form of helper libraries and plugins for popular blogging or content management systems (like Wordpress).</p>

<p>ActivityPub has been implemented to some degree by several members of the Working Group, and integration into pump.io and various OStatus based systems are in progress.</p>

<p>Linked Data Notifications has also been integrated into personal software projects of Working Group members, as well as a number of academic projects or commercial to do with dataset and resource management. Applications and helper libraries have also been created as part of the Solid project. Existing Linked Data Platform servers can by default serve as one part of the LDN protocol.</p>

<p>WebSub has received implementations from the IndieWeb community, and has semi-compatible historical implementations from when it was PubSubHubbub.</p>

</div>

</section>

</div>

</section>

<h2>Discussion</h2>

<div>

<p>Here we uncover common modules of decentralised social systems from previous discussion, and look at where there are overlaps and things that stand out.</p>

<p><strong>Identifiers:</strong> Most of the systems mentioned use URIs to identify and locate individual resources (like blog posts). Users of the systems, or their accounts, are identified by a combination of Webfinger URIs and HTTP URLs. A useful point of alignment between different systems might be a standard for mapping between Webfinger URIs and HTTP URLs for user profiles.</p>

<p><strong>Data storage:</strong> Users of decentralised systems must be acutely more aware of the location(s) of their data. When faced with choices between multiple possible third-party providers (datastore providers or particular hosted software instances), or self-hosting (either on one's own local hardware, or a rented webhosting service), ones personal data gains a sense of concreteness, somewhat divorced from activities which might create the data, of interacting and socialising online.</p>

<p><strong>Trust:</strong> In most cases, instances federate by passing data from one server or PDS to another. Unless the data is end-to-end encrypted and able to be interpreted by authorised <em>clients</em> only, users ultimately need to trust the servers of their entire social network in the cases where their posts are broadcast to all of their followers, and their followers responses are broadcast to all of <em>their</em> followers. This creeps into the territory of imagined vs. actual audience, which individuals might not be fully aware of.</p>

<p><strong>Content:</strong> Content and activities being passed around between different instances and implementations of protocols means that it is likely to be seen in different user interfaces, and as part of different streams of other data, and even perhaps with additional affordances or missing features. Systems which mix and match functionality of different protocols, and are extended or otherwise customised, will have a significant impact on how people interact with and consume content from others, and in a way that will be fairly unpredictable to the content publisher.</p>

<p>In the <a href="chapter5">next chapter</a> we take a deeper look at the Social Web Protocols and the context in which they were developed.</p>

</div>

</section>

</div>

</article>

</main>

get_refs();

</script>

</body>

</html>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chapter4.html

chapter4.html

Files

chapter4.html

Latest commit

History

chapter4.html

File metadata and controls