-
Notifications
You must be signed in to change notification settings - Fork 6
/
chapter6.html
218 lines (165 loc) · 44.8 KB
/
chapter6.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
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
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="utf-8" />
<title>Conclusions</title>
<meta content="width=device-width, initial-scale=1" name="viewport" />
<link href="thesis.css" media="all" rel="stylesheet" title="Thesis do" />
<link href="https://dokie.li/media/css/basic.css" media="all" rel="stylesheet alternate" title="Basic" />
<link href="https://dokie.li/media/css/dokieli.css" media="all" rel="stylesheet" />
<script src="https://dokie.li/scripts/dokieli.js"></script>
<script src="thesis.js"></script>
<link href="https://rhiaro.co.uk/incoming/" rel="http://www.w3.org/ns/ldp#inbox" />
<link href="https://linkedresearch.org/annotation/rhiaro/thesis/" rel="http://www.w3.org/ns/oa#annotationService" />
<style>
h1:before {
content:"Chapter 6\A" !important;
white-space:pre;
font-size:0.75em;
}
</style>
</head>
<body about="" prefix="rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema# owl: http://www.w3.org/2002/07/owl# xsd: http://www.w3.org/2001/XMLSchema# dcterms: http://purl.org/dc/terms/ dctypes: http://purl.org/dc/dcmitype/ foaf: http://xmlns.com/foaf/0.1/ pimspace: http://www.w3.org/ns/pim/space# cc: https://creativecommons.org/ns# skos: http://www.w3.org/2004/02/skos/core# prov: http://www.w3.org/ns/prov# mem: http://mementoweb.org/ns# qb: http://purl.org/linked-data/cube# schema: http://schema.org/ void: http://rdfs.org/ns/void# rsa: http://www.w3.org/ns/auth/rsa# cert: http://www.w3.org/ns/auth/cert# wgs: http://www.w3.org/2003/01/geo/wgs84_pos# bibo: http://purl.org/ontology/bibo/ sioc: http://rdfs.org/sioc/ns# doap: http://usefulinc.com/ns/doap# dbr: http://dbpedia.org/resource/ dbp: http://dbpedia.org/property/ sio: http://semanticscience.org/resource/ opmw: http://www.opmw.org/ontology/ deo: http://purl.org/spar/deo/ doco: http://purl.org/spar/doco/ cito: http://purl.org/spar/cito/ fabio: http://purl.org/spar/fabio/ oa: http://www.w3.org/ns/oa# as: https://www.w3.org/ns/activitystreams# ldp: http://www.w3.org/ns/ldp# solid: http://www.w3.org/ns/solid/terms# acl: http://www.w3.org/ns/auth/acl# dio: https://w3id.org/dio# rel: https://www.w3.org/ns/iana/link-relations/relation#" typeof="schema:CreativeWork sioc:Post prov:Entity">
<main>
<article about="" typeof="schema:Article">
<h1 property="schema:name">Conclusions</h1>
<div id="content">
<section id="summary" rel="schema:hasPart">
<h2>Summary</h2>
<div>
<p>The goal of this thesis was to reach an improved understanding of how people present themselves online, and how this may evolve in the future. I carried out five empirical studies which bring to light diverse identity behaviours in different types of social system. Against my results and a backdrop of existing social science studies, I developed the 5 Cs conceptual framework which can be used to organise ideas when studying representations of individuals in networked publics. I also produced the Social Web Protocols, a primer for the cutting edge formal standards work for the Social Web which is taking place at the W3C, demonstrated prototype implementations of systems which use these standards, and discuss how systems like this affect self-presentation behaviours.</p>
<p>In this chapter I review the research questions which I set out in <a href="chapter1">chapter 1</a>, and summarise my contributions to the field. I wrap up with some still unanswered questions, and new questions which have arisen through my work, as well as some suggestions for directions to take with future research in this area.</p>
</div>
</section>
<section id="review-rqs" rel="schema:hasPart">
<h2>Review of research questions</h2>
<div>
<p><strong>How can we access the bigger picture when it comes to understanding the impact of networked publics on presentation of self?</strong></p>
<p>I provide a conceptual framework, the <a href="chapter3#ccccc">5 Cs</a>, which includes high level interconnected concepts which are critical to any studies of online self-presentation: <strong>control</strong>, <strong>customisability</strong>, <strong>connectivity</strong>, <strong>cascade</strong>, and <strong>context</strong>. Whilst it is difficult for studies to take into account the huge number of factors which influence presentation of self, we have seen that most don't even acknowledge the bigger picture, tending to focus on technical affordances or particular actions or feelings of people. We must acknowledge that people and technology affect each other in a continuous cycle, and are both similarly affected by - and affect in turn - external factors, social, political, and economic. <a href="#c2studies">Table 16</a> shows the studies reviewed in <a href="chapter2">chapter 2</a> about <a href="chapter2#sns">Social Network Sites</a>, <a href="chapter2#bloggers">blogging</a> and <a href="chapter2#everybody-knows-im-a-dog">privacy</a> grouped according to which of the 5Cs are acknowledged in their background, results or analysis. None of them examine <em>all</em> of the 5Cs.</p>
<table id="c2studies">
<caption>Table 16. A set of studies reviewed in chapter 2, grouped by which of the 5 Cs they discuss.</caption>
<thead>
<tr>
<th>Concept</th>
<th>SNS studies</th>
<th>Blogging studies</th>
<th>Privacy studies</th>
</thead>
<tbody>
<tr>
<td>Context</td>
<td>[<a href="appendices#ref-borndigi">borndigi</a>] [<a href="appendices#ref-boyd2014s">boyd2014s</a>] [<a href="appendices#ref-appgen">appgen</a>] [<a href="appendices#ref-boyd-sns07">boyd-sns07</a>] [<a href="appendices#ref-boydnp10">boydnp10</a>] [<a href="appendices#ref-marwickdrama14">marwickdrama14</a>] [<a href="appendices#ref-boydfacid">boydfacid</a>] [<a href="appendices#ref-bunnies17">bunnies17</a>] [<a href="appendices#ref-papatwit12">papatwit12</a>] [<a href="appendices#ref-food15">food15</a>] [<a href="appendices#ref-DiMicco07">DiMicco07</a>] [<a href="appendices#ref-boyd15">boyd15</a>] [<a href="appendices#ref-Zhao16">Zhao16</a>] [<a href="appendices#ref-Farnham11">Farnham11</a>] [<a href="appendices#ref-Vitak14">Vitak14</a>] [<a href="appendices#ref-ellison11fb">ellison11fb</a>] [<a href="appendices#ref-litt12">litt12</a>] [<a href="appendices#ref-Smart2014">Smart2014</a>] [<a href="appendices#ref-Dalton2013">Dalton2013</a>]</td>
<td>[<a href="appendices#ref-dennen09">dennen09</a>] [<a href="appendices#ref-boyd-sns07">boyd-sns07</a>]</td>
<td>[<a href="appendices#ref-albrechtslund2008Participatory">albrechtslund2008Participatory</a>] [<a href="appendices#ref-fife2012privacy">fife2012privacy</a>] [<a href="appendices#ref-metzger2004privacy">metzger2004privacy</a>] [<a href="appendices#ref-featherman2010reducing">featherman2010reducing</a>] [<a href="appendices#ref-dcent">dcent</a>] [<a href="appendices#ref-crit12">crit12</a>] [<a href="appendices#ref-nissenbaum2004privacy">nissenbaum2004privacy</a>] [<a href="appendices#ref-nissenbaum2009privacy">nissenbaum2009privacy</a>]</td>
</tr>
<tr>
<td>Control</td>
<td>[<a href="appendices#ref-appgen">appgen</a>] [<a href="appendices#ref-boydnp10">boydnp10</a>] [<a href="appendices#ref-boydsns07">boydsns07</a>] [<a href="appendices#ref-ellison13">ellison13</a>] [<a href="appendices#ref-boyd-sns07">boyd-sns07</a>] [<a href="appendices#ref-stendal12">stendal12</a>] [<a href="appendices#ref-DiMicco07">DiMicco07</a>] [<a href="appendices#ref-Farnham11">Farnham11</a>]</td>
<td>[<a href="appendices#ref-dennen09">dennen09</a>]</td>
<td>[<a href="appendices#ref-decew1997pursuit">decew1997pursuit</a>] [<a href="appendices#ref-tyler2003can">tyler2003can</a>] [<a href="appendices#ref-nissenbaum2004privacy">nissenbaum2004privacy</a>] [<a href="appendices#ref-nissenbaum2009privacy">nissenbaum2009privacy</a>]</td>
</tr>
<tr>
<td>Customisability</td>
<td>[<a href="appendices#ref-appgen">appgen</a>] [<a href="appendices#ref-baker09">baker09</a>] [<a href="appendices#ref-boydfacid">boydfacid</a>] [<a href="appendices#ref-youth">youth</a>] [<a href="appendices#ref-counts09">counts09</a>] [<a href="appendices#ref-vanhouse11">vanhouse11</a>] [<a href="appendices#ref-lasen15">lasen15</a>] [<a href="appendices#ref-senft15">senft15</a>] [<a href="appendices#ref-frosch15">frosch15</a>] [<a href="appendices#ref-bunnies17">bunnies17</a>] [<a href="appendices#ref-papatwit12">papatwit12</a>] [<a href="appendices#ref-food15">food15</a>] [<a href="appendices#ref-stendal12">stendal12</a>] [<a href="appendices#ref-boydsns07">boydsns07</a>]</td>
<td>[<a href="appendices#ref-Rousseau17">Rousseau17</a>] [<a href="appendices#ref-markus06">markus06</a>] [<a href="appendices#ref-dennen09">dennen09</a>] [<a href="appendices#ref-alist05">alist05</a>] [<a href="appendices#ref-gosling08">gosling08</a>] [<a href="appendices#ref-vazire04">vazire04</a>] [<a href="appendices#ref-papacharissi02">papacharissi02</a>] [<a href="appendices#ref-blogdesign">blogdesign</a>]</td>
<td>n/a</td>
</tr>
<tr>
<td>Connectivity</td>
<td>[<a href="appendices#ref-boydsns07">boydsns07</a>] [<a href="appendices#ref-ellison13">ellison13</a>] [<a href="appendices#ref-boyd2014s">boyd2014s</a>] [<a href="appendices#ref-marwickdrama14">marwickdrama14</a>] [<a href="appendices#ref-DiMicco07">DiMicco07</a>] [<a href="appendices#ref-Zhao16">Zhao16</a>] [<a href="appendices#ref-Farnham11">Farnham11</a>] [<a href="appendices#ref-Vitak14">Vitak14</a>] [<a href="appendices#ref-ellison11fb">ellison11fb</a>] [<a href="appendices#ref-boydnp10">boydnp10</a>] [<a href="appendices#ref-Marwick2010">Marwick2010</a>] [<a href="appendices#ref-litt12">litt12</a>] [<a href="appendices#ref-Dalton2013">Dalton2013</a>]</td>
<td>[<a href="appendices#ref-dennen09">dennen09</a>]</td>
<td>[<a href="appendices#ref-decew1997pursuit">decew1997pursuit</a>] [<a href="appendices#ref-tyler2003can">tyler2003can</a>] [<a href="appendices#ref-nissenbaum2004privacy">nissenbaum2004privacy</a>] [<a href="appendices#ref-nissenbaum2009privacy">nissenbaum2009privacy</a>]</td>
</tr>
<tr>
<td>Cascade</td>
<td>[<a href="appendices#ref-ellison13">ellison13</a>] [<a href="appendices#ref-boyd-sns07">boyd-sns07</a>] [<a href="appendices#ref-boydnp10">boydnp10</a>] [<a href="appendices#ref-boyd2014s">boyd2014s</a>] [<a href="appendices#ref-singh15">singh15</a>] [<a href="appendices#ref-duguay13">duguay13</a>] [<a href="appendices#ref-papatwit12">papatwit12</a>] [<a href="appendices#ref-DiMicco07">DiMicco07</a>] [<a href="appendices#ref-Zhao16">Zhao16</a>] [<a href="appendices#ref-Marwick2010">Marwick2010</a>] [<a href="appendices#ref-litt12">litt12</a>] [<a href="appendices#ref-contextwesch">contextwesch</a>] [<a href="appendices#ref-daviscontext">daviscontext</a>] [<a href="appendices#ref-duguay14">duguay14</a>]</td>
<td>n/a</td>
<td>[<a href="appendices#ref-albrechtslund2008Participatory">albrechtslund2008Participatory</a>] [<a href="appendices#ref-fife2012privacy">fife2012privacy</a>] [<a href="appendices#ref-metzger2004privacy">metzger2004privacy</a>] [<a href="appendices#ref-featherman2010reducing">featherman2010reducing</a>] [<a href="appendices#ref-dcent">dcent</a>] [<a href="appendices#ref-crit12">crit12</a>] [<a href="appendices#ref-boydpriv12">boydpriv12</a>]</td>
</tr>
</tbody>
</table>
<p><strong>Control</strong> and <strong>customisability</strong> for the most part relate to what technical systems enable people to do or prevent them from doing. <strong>Control</strong> additionally calls out the multi-faceted nature of identity, so we are forced to consider the relationships between people's different and potentially disconnected verisons of themselves. <strong>Connectivity</strong> and <strong>cascade</strong> emphasise that self-presentation is not a solo activity. We are influenced by audiences, real, imaginary, seen and unseen. The <strong>cascade</strong> requires us to acknowledge some of the important differences between offline publics and networked publics, including how our personal data is collected, stored, and used by unknown third parties, and how it may persist for long periods of time, and possibly be accessed in vastly different ways than we imagined when we created it. Finally, <strong>context</strong> captures the overall backdrop against which our online identity performances take place. It is imperative to consider, or at least document, the cultural, political, and economic surroundings of individuals; a lack of geographical bounds for online activities does not make these disappear. By no means least, personal feelings, motivations, desires, aspirations and troubles, as well as access to particular technologies and attitudes toward them, make up the immediate <strong>context</strong> of every single person. It may be impossible to know these details, yet these details may be at the core of explaining particular online behaviours, and it is easy to lose sight of this when analysing data about collectives.</p>
<p>Deeper work on <strong>control</strong>, <strong>customisability</strong> and <strong>connectivity</strong> stems from <a href="chapter3#what-is-a-profile">What is a profile?</a>, whence I conclude that what constitutes a profile is context-dependent and varies with individual and community needs. This study focuses on technical platforms, but accommodates the perspectives on the platforms of users, developers, and the broader social landscape. Social Network Sites provide varying facilities to build profiles, from asking for explicit input from the profile owner, to a feed of owner- and other-generated content, to automated output from the system itself. Systems may be judged along dimensions of: flexibility; access control; portability; representation; and prominence. The combination of features can determine how much authority, in terms of <strong>control</strong> and <strong>customisability</strong>, a profile owner has over their online self-presentation in that particular system. This study provides a framework for describing technical systems as a backdrop for studies which focus primarily on the people using the systems.</p>
<p>A detailed description of the process of standards-making for the Social Web in <a href="chapter5#socialwg-thesis">Standards and self-presentation</a> also provides <strong>context</strong>ual backdrop for any future work which studies systems which are built on top of the protocols produced by the W3C Social Web Working Group.</p>
<p><strong>How does self-presentation change depending on the power dynamics of the Social Web services they use?</strong></p>
<p>When software systems do not do what people need, and there are few realistic alternatives, people innovate. They find new ways to work around the constraints they face. Much mainstream Social Web software today is designed around representing and connecting 'real people', but without taking into account the nuances of what a real person actually is. In <a href="chapter3#constructing-online-identity">Constructing Online Identity</a> and <a href="chapter3#the-many-dimensions-of-lying-online">The Many Dimensions of Lying Online</a>, we can see a wide variety of motivations for bending the truth on the Social Web, most of which are not malicious or even truly dishonest. We see people adapting to their audiences, and selectively disclosing parts of their identity in order to protect their own wellbeing. This is all part of how people <strong>control</strong> their self-presentation(s) online. In Turkle's early (mid-1990s) research into identity in digital spaces, she optimistically proclaimed these new media to be fora for creative expression, where people can safely explore to find their true selves. Turkle's view on technology may have soured since then, but we are still seeing playful, artistic, and empathic behaviours on the Social Web, much of which tends to take place outside of the rules and regulations of the underlying systems (which themselves provide important <strong>context</strong> against which to understand uses of the systems). This is a key insight that informs our understanding of what it is to be a social entity within rigid technological limitations, and something to bear in mind before we make assumptions about what people use a system for purely on the basis of the system's affordances or what it claims to be for.</p>
<p>An important takeaway from <a href="chapter3#computationally-mediated-pro-social-deception">Computationally Mediated Pro-Social Deception</a> is that if Social Network Sites demanded <em>less</em> of their users, people would be inclined to entrust them with <em>more</em>. People's perceptions of the <strong>cascade</strong> vary; in many cases either they know enough about it to not want to share, or they know they don't understand it, and are too suspicious to share. A second is that a world which is at all times revealing and accurate is not necessarily a social or humane world. This seems obvious from a social perspective, but we see Social Network Sites are still baking in expectations of their users based on a flawed understanding of integrity or authenticity which does not leave people space to maintain their relationships (and sanity) through the different levels of mild deception which are second nature in offline interactions.</p>
<p>My study of <a href="chapter3#social-media-makers">Social Media Makers</a> is the first of its kind; I engaged with indivdiduals who are building and using decentralised Social Web systems as alternatives and augmentations to mainstream centralised systems. These individuals, mostly starting from scratch, have completely changed the power dynamic by taking ownership of their personal data, moulding it to their needs, and selectively sharing this across different networked publics. Their responses demonstrate the importance of flexible functionality for self-expression - <strong>customisability</strong> - as well as a desire to break away from the cultural norms which have arisen around centralised Social Network Sites. Nonetheless, they are still affected by outside systems thanks to their desire for <strong>connectivity</strong> to existing networks, and the <strong>cascade</strong> which results from this. There is a sense that once diverisity in online self-presentation is the norm, people will be more able to be themselves on the Social Web.</p>
<p><strong>What can developers do to adapt to or accommodate self-presentation needs of individuals?</strong></p>
<p>By following Web standards when designing new social systems (specifically the W3C Social Web Working Group ones in this case), developers can accommodate people who want to move between or spread themselves across different systems, without creating the burden of lock-in that we see with proprietary systems today. This opens the door to extensibility and more specialised social systems which can rise to the challenge of accommodating increasingly niche communities and individual quirks. I provide some examples of where to start with this in <a href="chapter5#social-web-protocols">Social Web Protocols</a>.</p>
<p>In direct application of Goffman's dramaturgical theories, I argue that it is important to find new ways of helping people to engage with their audience, across space and time. <em><a href="chapter5#audience-and-self-presentation">face</a></em> is one possible approach, which does not address privacy or information access concerns, but relies on the idea that an audience member is willing to play their part in the performance, is somewhat aware from their own experiences of the complexities of online self-presentation, and will participate in helping their expectations to be met. Just as we politely pretend not to see someone stumble as they enter the room, or accept without question the actions of characters in a play on stage.</p>
<section id="contributions" rel="schema:hasPart">
<h3>Methodological Recommendations</h3>
<div>
<blockquote><p>Web Science must coordinate engineering with a social agenda, policy with technical constraints and possibilities, analysis with synthesis - it is inherently interdisciplinary. - [<a href="appendices#ref-websci">websci</a>]</p></blockquote>
<p>A further outcome of my work has been to find ways to link research and methods from social science and computer science fields in a way which benefits both, and serves to further our understanding of socio-technical systems in general. I have leaned on Goffman's dramaturgy throughout, and highlighted ways in which theories about face-to-face interactions can be applied to the Social Web, as well as places where these theories need to be extended or amended for digital spaces.</p>
<p>I also advocate exploring more auto-ethnographic style approaches to system design and development. Researchers can immerse themselves in the systems they are studying, and gain greater insight into the motivations and activities of other participants. At the very least, this should enable a more comprehensive description and review of technical features than an outside overview could provide, which in itself is vaulable for situating any particular study.</p>
<p>In software engineering, using yourself the software you produce is often known as "dogfooding" or "eating one's own dogfood." This comes with the ethic that one shouldn't build systems for other people which aren't useful to you. More extreme advocates argue that if you <em>rely</em> on the software you are building you're also much more likely to resolve problems, and see gaps for missing features. Many large software development companies already employ this policy [<a href="appendices#ref-dogfood">dogfood</a>], and for one-person or small teams developing experimental platforms to explore new ideas I think academics would do well to adopt this approach as well. It has the potential to reduce speculative features and cement a greater level of commitment to a project. I demonstrated this with <em>sloph</em>, the personal social datastore I built and described in <a href="chapter5#personal-web-observatory">Personal data and self-presentation</a>. In terms of the highly personal Social Web systems I expect us to be moving towards as this field progresses, I think it is particularly presumptuous for us to theorise around systems which we aren't willing to engage with directly ourselves.</p>
<p>In conclusion, I have advanced the field of Web Science through bridging interdisciplinary approaches, and propose a new mode of research approach when it comes to experimental software systems of a personal or social nature.</p>
</div>
</section>
</div>
</section>
<section id="future" rel="schema:hasPart">
<h2>Things to come</h2>
<div>
<p>This thesis covers a mere snapshot of a point in time, in the history of the Web and online social interactions. By the time you read this, anything labeled 'current' or 'modern' will probably be obsolete. Even in the last month of writing up, <em>Mastodon</em> gained sudden popularity, and continues to grow (in terms of new instances and total user accounts) at an exponential rate. Mastodon is an implementation of OStatus and alternative to GNU Social, decentralised microblogging platform designed to compete with the monolithic Twitter. If you were paying attention in Chapter 4, you know that GNU Social is the community takeover of StatusNet. The founder of StatusNet and the primary driver of the OStatus architecture, Evan Prodromou, is a chair of the Social Web Working Group. Following StatusNet, Evan worked to simplify OStatus with Pump.io [<a href="appendices#ref-dcent">dcent</a>], a popular instance of which includes <em>identica</em>. A modest community of developers maintain the primary Pump.io codebase and keep federated instances running. The Social Web Working Group's ActivityPub used to be called Activity<em>Pump</em>, and is an evolution of the Pump.io specification, with Evan's oversight. As such, the suddenly popular Mastodon codebase is not one but two generations of protocol behind, if we assume Evan (and Social Web Working Group co-conspirators) know what they're talking about.</p>
<blockquote><p>
"I'm happy for Mastodon's success but disappointed they didn't use the modern protocol ActivityPub we developed at W3C. All I have to say." - Evan Prodromou, on various social platforms [<a href="https://mobile.twitter.com/evanpro/status/851155551325229058">Twitter</a>].
</p></blockquote>
<p>What followed were murmured complaints about the OStatus dependence on the <em>ancient</em> XML (developers these days supposedly prefer JSON). Some of us in the Working Group wondered where this will go next. Does its sudden popularity (at a scale not previously enjoyed by decentralised social efforts) mean that after all, the Social Web Working Group's efforts were for naught; OStatus was sufficient all along, it just needed the timing of the current political environment perhaps combined with the (comparatively) beautiful user interface that Mastodon provides? Or does it mean that thanks to its popularity, a flurry of open source developers will update the codebase to be compatible with ActivityPub, and the Working Group's work will see widespread success off the back of Mastodon after all? </p>
<p>Subsequently core Mastodon developers joined the Social Web Community Group (a less formal follow-on from a Working Group) and began raising issues and engaging in discussions with the ActivityPub specification authors and implementors. ActivityPub made small changes to the specification in response, and in September 2017, Mastodon <a href="https://hackernoon.com/mastodon-and-the-w3c-f75f376f422">announced</a> a release which uses ActivityPub mechanisms for key features, as well as an intention to deprecate OStatus in future versions.</p>
<p>Does this mean that other OStatus-based systems (such as <a href="https://www.postactiv.com/">PostActiv</a> and <a href="https://gnu.io/social/">GNU Social</a>) will follow Mastodon's example? Early to say, but at a minimum I hope for some level of bridging between the different protocols. After all, even if one particular combination of protocols is widely used there will always be use cases it doesn't quite meet, or developers who just don't really like the look of it. I think that an important indicator for the long-term potential of OStatus based systems will be whether we soon see implementations which do things <em>other</em> than Twitter-style microblogging. OStatus was designed with microblogging as its core use case in mind, but (as we have seen) there is a whole host of social software out there, from health tracking to service exchange. The extensibility-by-design of ActivityStreams 2.0 may be what gives ActivityPub an edge in terms of diversifying the possibilities of decentralised social systems. This diversity, as I have hinted at previously, brings a host new challenges of course. </p>
<section id="considered-harmful" rel="schema:hasPart">
<h3>Decentralisation considered harmful</h3>
<div>
<p>Throughout this thesis I have assumed that decentralisation is a positive route forward for empowering individuals through Web technologies. I have done little to reflect on the new problems that arise with this kind of architecture. Here I outline a few areas where decentralisation might cause <em>new</em> issues or make things worse. I am barely scratching the surface here, and finding and solving the social problems associated with decentralised Social Web technologies is an important direction for future research.</p>
<!-- <p class="todo">professionalise https://rhiaro.co.uk/2016/11/decentralisation-considered-harmful</p> -->
<p><strong>Smaller attack surfaces:</strong> Large centralised systems have robust network architectures, and plenty of resources to keep things running under duress, or to recover from attacks. Many decentralised architectures imagine smaller 'pods', independent servers which federate. It's possible many of these servers will be run by volunteers, hobbyists, or small organisations, and could be easily taken down and kept down by malicious actors.</p>
<p><strong>Quieter takedowns:</strong> 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.</p>
<p><strong>Illusion of control 1:</strong> We promote decentralisation as a way to <strong>customise</strong> who has access to your personal or 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. We already see that people have difficulty managing their Facebook privacy settings, and these are for a single unified system. On top of that, not only must you trust the server where you host your data to correctly enforce access controls, depending on the architecture, there can be serious <strong>connectivity</strong> implications; you may need to trust your friends' servers, and their friends' too, as blobs of your information are passed through the network. Just because you <em>could</em> move your data to a different service, doesn't mean it's safe where it is.</p>
<p><strong>Illusion of control 2:</strong> When I log and publish data about myself with my homemade personal datastore (described in <a href="chapter5#personal-web-observatory">chapter 5</a>), I feel like I have more control over my expression given off. I provide data on my own terms, and I know that <em>my</em> software is not drawing inferences or aggregating my data with others in order to learn more about me than I'm sharing explicitly. However, related to the previous point, my data is all public and machine readable, using open standards; there's nothing to stop Facebook from connecting the dots and consuming this data about me as well, so the <strong>cascade</strong> is still present. If social media has normalised dangerous oversharing, and the general populace is starting to realise how their data is being used and carrying out countermeasures, then decentralised social media runs the risk of convincing people their oversharing is 'safe' again, setting us back a decade.</p>
<p><strong>The filter bubble:</strong> The easier we make it for people to avoid abuse online (not that decentralised systems have necessarily solved this yet), the easier we make it for people to filter out diverse points of view. Last year, Twitter introduced the ability to filter out certain phrases from one's timeline. An immediate reaction from privileged Twitter users (people who have never been flooded by abusive posts) was to decry the new filter bubble this could create. If filtering abuse is directly at odds with exposing people to different worldviews we might suppressing one of the core potentials of the Web. At the very least, people need to be able to choose how selective to be with what they consume, whilst being made aware of the potential consequences.</p>
<p><strong>Lost in translation:</strong> We have to assume that protocols used in decentralised social systems will at some point not meet all of the needs of system designers and users, and will need to be extended. Indeed, ActivityPub and other Social Web Working Group specifications are designed with extensibility in mind. As different implementations extend the core protocols in different ways, whilst continuing to federate with each other, mismatches will start to occur. One example is Mastodon's <em>content warning</em> feature, which allows people to hide the majority of a post behind a small label (from NSWF to politics to TV spoilers), so that receivers can opt into reading the content, or skim past if they'd rather not. Friendica <a href="https://github.com/friendica/friendica/issues/3285">rushed to implement this</a> so that their users wouldn't be negatively affected by inappropriate posts from Mastodon instances which the creators thought would be tactfully hidden, and there was also <a href="https://mastodon.social/users/Gargron/updates/3244985">concern about how this would play with ActivityPub integration</a> (a <a href="https://github.com/w3c/activitypub/issues/231">future extension</a> to ActivityPub was eventually agreed). As implementations and extensions diversify, we run the risk of content being miscommunicated between systems as well as conflicts about how particular features are expected to behave.</p>
</div>
</section>
<section id="long-live-decentralisation" rel="schema:hasPart">
<h3>Long live decentralisation</h3>
<div id="praviti-pitu-od-govana">
<!-- #70 Based on the students investigations in this thesis suggest future scenarios for the decentralised web for digital presentation of self. -->
<p>None of the problems in the previous section are things that will foil mass adoption of decentralised social Web technologies. They're just things that may make this type of technology more harmful by not being resolved if there <em>is</em> adoption. So what will happen next?</p>
<p>I cannot herald a golden age, a revolution in human expressiveness. I unexcitedly predict gradual changes, in fits and starts, with intermittent controversy, but little fanfare. Even as social media becomes central to Western everyday lives, we are simultaneously turning away from it. In truth, far more people do not use the social layer of the Web than those who do, globally. </p>
<p>Over the next few years, distaste for social media will peak. Those with the resources to do so will pay for less obnoxious experiences. Those fortunate enough to not live in isolation or want for community support, will disconnect. The Web will drift into the background of their lives; something to check in an emergency, or on a special occasion. Their identities will recentre in their physicality and moments will pass unrecorded. They will nonetheless be accommodated in society, because they are already a privileged group.</p>
<p>For all of the people for whom social media was a detriment, there are perhaps a great many more whose lives have been vastly (or even slightly) improved. People who can't or won't disconnect even if they want to. Service providers will eventually realise that Stockholm Syndrome is not the most effective way of retaining users, and will become gentler and more outwardly respectful than they are now. Today people switch contexts by switching applications; over the next few years, service providers will stop fighting this, and work to make it more seamless. In understanding that we live life in different modes, interface for particular tasks will become more specialised and more personalised, and for someone to put on the right face at the right time will become second nature digitally, as it is in-person.</p>
<p>To enable this, service providers will share data under the hood. No longer competing to be the sole proprietor of an individuals' network and personhood (they never were, after all) systems will instead trade between each other, provide service integrations, and use this more complete contextual information to compete on utility and usability.</p>
<p>With each enormous data leak or trust-breaching design decision, a flurry of smaller more respectful services will emerge and gain adoption. More specialised applications will be more pluggable; their users benefit when they cooperate. As services share data under the hood, context switching becomes easier and smoother. </p>
<p>Data sharing deals will be exclusive, between the most popular and most successful platforms to begin with, but as people get more discerning, and as they get used to a landscape of better performing specialised applications with variety to choose from, the market will broaden. APIs for data exchange will stabilise and generalise. Maybe some of the standards of this decade will be picked up and adapted. Personal data consolidators will step in to broker between applications. Not as end-user products, but as services for service providers themselves. Everyone will have a context-aware personal data store without knowing it. Personal data legislation in some parts of the world will make sure people <em>do</em> know it though. A side effect of service interoperability will be data portability. A small portion of people will take ownership of their accumulated online presence, but most won't.</p>
<p>As human beings, we will remain diverse. Acknowledging this diversity spawns <em>more</em> options for applications and services. But just like hundreds of brands in a grocery store which are all owned by two or three conglomerates lends an illusion of choice, the number of <em>providers</em> behind the options may not actually increase, just their offerings. But we will perfect our digital daily routine, tweak it so it suits our tastes, and it needn't look the same as that of anyone else in the world.</p>
<p>As ever, some people will register and check up on every step taken, every character typed. Some will knowingly or unknowingly log this data and pay it no mind. Every microsecond will be captured and some will be replayed, some will be lost forever on a harddrive. Portraits of your personas will be scary, accurate, and very convenient. They'll still get things wrong, and there will be things you just don't do over the network. It'll be harder and harder to get a device or use an application that doesn't already know some part of who you are - whether your personal data is in your own hands or in someone else's black box.</p>
<p>As much as I'd love to believe the data ownership revolution will be driven by those steadfastly building decentralised tooling right now, I think the history of fragmentation and infighting will have repercussions for years to come. Systems which only interoperate with other versions of themselves will have no place in a future of diverse tailored digital experiences, and neither will stand-alone systems which individuals have to set up and maintain all by themselves. Change will be driven by the big players, who must eventually realise that putting all of their users into matching boxes isn't actually in anyone's interests. Personalised, more diverse social applications which support context-switching may create a backdoor of data access through which those who care enough can claw back some ownership, but ultimately our online presence will still be largely out of our hands. What matters though, for most people, is the interface for expressing ourselves through our data; ownership alone is not empowering.</p>
<p><em>(Alternatively, corporations and government will merge, personal data will be gathered and unified, and opting out will be at the cost of healthcare, jobs, and being recognised as human by passing self-driving cars).</em></p>
</div>
</section>
<section id="next" rel="schema:hasPart">
<h3>Future work</h3>
<div>
<p>As is declared at the end of all theses but the most confident or self-important ones, there remains much to be done. I have demonstrated in the preceding chapters that there is a complex interplay between the personal, the social and the technical in considering the dynamics of the Social Web, and in engineering its future. I hope that one overarching impact of my work will be to help set a research agenda for better understanding the place of social media within the context of Web Science. The following list, albeit incomplete, highlights four key areas where I both recommend and expect to see future research.</p>
<p><strong>Cogs in the machine:</strong> Social machines are to date largely studied in collective terms. It is important to acknowledge that this is one zoom level, which is a valid perspective, but I'd like to see comparisons between results of studies of the impression of a social machine as whole, with studies of individual participants. There is scope for work in differentiating identity performance as part of a crowd or collective with shared purpose, with how individuals in that crowd perform their identity on their own terms. When are these at odds and when are they complementary? How do reputation systems play into this? What affects the ability for applications to simultaneously be tools for individuals and tools for social coordination?</p>
<p><strong>Decentralisation and communities:</strong> This thesis examined possible effects of decentralisation of the Social Web on individuals, but I have not looked at how this type of architecture will affect communities. I anticipate that distinct sub-communities will become more obvious in an instance-based architecture (that is, servers will host a particular community, which can nonetheless interact through federation protocols with other communities on other instances). One question to ask is how individuals will manage their participation in multiple communities in this case? Linkability of different identities may need to be carefully managed by individuals, and it is worth investigating possible user interfaces to help with this, to maximise convenience for individuals whilst minimising the effects of information leakage. In addition, interoperable protocols mean that people using diverse software implementations can interact. Certain things may need to be translated between systems, eg.: terminology; user interface design; cultures, norms and quirks; and features above and beyond what is specified in the official protocols. Right now, most Facebook users who see someone post a 'retweet' as a status update understand that this has likely been cross-posted automatically from Twitter, even if they are not Twitter users themselves. Decentralisation will enable an explosion of different ideas around how to describe social interactions, and it will be impossible for an individual in one system to be aware of all of the others. One term may even be used in different ways by different communities. Just last week I called out to the ether from Mastodon to ask what the difference between a "bap" and a "boost" is. It turns out that they're the same thing, but the administrators of my chosen Mastodon instance, which is loosely cat-themed, has tweaked the UI so that "replies", "favorites" and "boosts" (like Twitter's retweets) are labelled "meows", "boops" and "baps". Anyone who saw my post from a different instance, unaware of the existence of "baps" likely had no idea what I was talking about; somebody replied to point out that "bap" is what the Scottish call bread rolls.</p>
<p><strong>Semantics of identity:</strong> I am hesitant to suggest that it's feasible to model identity behaviours in terms of the formal semantics desired by Semantic Web advocates. However, a longitudinal study into emerging community descriptions, or folksonomies, of how people present themselves or how their different identities interact or intersect would be a useful step in terms of both better understanding presentation of self online on a theoretical level, as well as how we can engineer interfaces for decentralised systems which help rather than hinder individuals on the Social Web.</p>
<p><strong>The Web for the vulnerable:</strong> It is important that we better understand the impact of decentralised social systems on minority communities and vulnerable people. Many safeguards developed as add-ons to centralised systems (such as shared or automated block lists) are themselves developed by the very people who need them the most. It is imperative that we (as scholars and developers) seek out diverse voices, listen to their needs and support their efforts without questioning their experiences, <em>and</em> that we put both research and development (funding, opportunities) into the hands of the people who are affected the most.</p>
<p>As for my personal continuation of this work: now I am addicted to life-logging with my personal data store, I expect that I will develop it further, and in particular improve the more social features, as well as experimenting with <em>face</em> for communicating with my audiences. </p><p>Stay tuned: I am <a href="https://rhiaro.co.uk">rhiaro.co.uk</a>.</p>
<!-- <ul>
<li>An agenda for Social Web Science research. Being able to ask the right questsions is really important. Move the starting point forward because of this work.</li>
</ul> -->
</div>
</section>
</div>
</section>
</div>
</article>
</main><script>
get_refs();
</script>
</body>
</html>