Replied to Gab and the decentralized web by Ben WerdmüllerBen Werdmüller
On one side, by creating a robust decentralized web, we could create a way for extremist movements to thrive. On another, by restricting hate speech, we could create overarching censorship that genuinely guts freedom of speech protections

I think this is a false dilemma, Bernd.

I’d say that it would be great if those extremists would see using a distributed tool like Mastodon as the only remaining viable platform for them. It would not suppress their speech. But it woud deny them any amplification, which they now enjoy by being very visible on mainstream platforms, giving them the illusion they are indeed mainstream. It will be much easier to convince, if at all needed, instance moderators to not federate with instances of those guys, reducing them ever more to their own bubble. They can spew hate amongst themselves for eternity, but without amplification it won’t thrive. Jotted down some thoughts on this earlier in “What does Gab’s demise mean for federation?

Who of you would want to try out Mastodon as an alternative to Twitter or Facebook? Would it help if I offer you a place to try it out? On my own instance, or rather a small group instance? Would you want to find a small group instance near you / around an interest you have? Do you have questions I can help with? See Sandro Hawke’s suggestion to do a once a month push for why I am asking, and this blogpost for why I think driving adoption from the edge matters.

From the recent posting on Mastodon and it currently lacking a long tail, I want to highlight a specific notion, and that’s why I am posting it here separately. This is the notion that tool usage having a long tail is a measure of distribution, and as such a proxy for networked agency. [A long tail is defined as the bottom 80% of certain things making up over 50% of a ‘market’. The 80% least sold books in the world make up more than 50% of total book sales. The 80% smallest Mastodon instances on the other hand account for less than 15% of all Mastodon users, so it’s not a long tail].

To me being able to deploy and control your own tools (both technology and methods), as a small group of connected individuals, is a source of agency, of empowerment. I call this Networked Agency, as opposed to individual agency. Networked also means that running your own tool is useful in itself, and even more useful when connected to other instances of the same tool. It is useful for me to have this blog even if I am its only reader, but my blog is even more useful to me because it creates conversations with other bloggers, it creates relationships. That ‘more useful when connected’ is why distributed technology is important. It allows you to do your own thing while being connected to the wider world, but you’re not dependent on that wider world to be able to do your own thing.

Whether a technology or method supports a distributed mode, in other words is an important feature to look for when deciding to use it or not. Another aspect is the threshold to adoption of such a tool. If it is too high, it is unlikely that people will use it, and the actual distribution will be very low, even if in theory the tools support it. Looking at the distribution of usage of a tool is then a good measure of success of a tool. Are more people using it individually or in small groups, or are more people using it in a centralised way? That is what a long tail describes: at least 50% of usage takes place in the 80% of smallest occurrences.

In June I spoke at State of the Net in Trieste, where I talked about Networked Agency. One of the issues raised there in response was about scale, as in “what you propose will never scale”. I interpreted that as a ‘centralist’ remark, and not a ‘distributed’ view, as it implied somebody specific would do the scaling. In response I wrote about the ‘invisible hand of networks‘:

“Every node in a network is a scaler, by doing something because it is of value to themselves in the moment, changes them, and by extension adding themselves to the growing number of nodes doing it. Some nodes may take a stronger interest in spreading something, convincing others to adopt something, but that’s about it. You might say the source of scaling is the invisible hand of networks.”

In part it is a pun on the ‘invisible hand of markets’, but it is also a bit of hand waving, as I don’t actually had precise notions of how that would need to work at the time of writing. Thinking about the long tail that is missing in Mastodon, and thus Mastodon not yet building the distributed social networking experience that Mastodon is intended for, allows me to make the ‘invisible hand of networks’ a bit more visible I think.

If we want to see distributed tools get more traction, that really should not come from a central entity doing the scaling. It will create counter-productive effects. Most of the Mastodon promotion comes from the first few moderators that as a consequence now run large de-facto centralised services, where 77% of all participants are housed on 0,7% (25 of over 3400) of servers. In networks smartness needs to be at the edges goes the adagium, and that means that promoting adoption needs to come from those edges, not the core, to extend the edges, to expand the frontier. In the case of Mastodon that means the outreach needs to come from the smallest instances towards their immediate environment.

Long tail forming as an adoption pattern is a good way then to see if broad distribution is being achieved.
Likely elements in promoting from the edge, that form the ‘invisible hand of networks’ doing the scaling are I suspect:

  • Show and tell, how one instance of tool has value to you, how connected instances have more value
  • Being able to explain core concepts (distribution, federation, agency) in contextually meaningful ways
  • Being able to explain how you can discover others using the same tool, that you might want to connect to
  • Lower thresholds of adoption (technically, financially, socially, intellectually)
  • Reach out to groups and people close to you (geographically, socially, intellectually), that you think would derive value from adoption. Your contextual knowledge is key to adoption.
  • Help those you reach out to set up their own tools, or if that is still too hard, ‘take them in’ and allow them the use of your own tools (so they at least can experience if it has value to them, building motivation to do it themselves)
  • Document and share all you do. In Bruce Sterling’s words: it’s not experimenting if you’re not publishing about it.

stm18
An adoption-inducing setting: Frank Meeuwsen explaining his steps in leaving online silos like Facebook, Twitter, and doing more on the open web. In our living room, during my wife’s birthday party.

Discovery in networks is always a bit difficult. You can for instance traverse the follower list of the followers of your followers (ad infinitum), which I often do, or you make voluntary lists like webrings, or blogrolls (my blogroll is in the right side bar). Trunk has some interesting thematic lists with (real 😉 )people’s activity pub and Mastodon accounts on them for a wide variety of topics. From retro-gaming to sustainability, from cyberpunk to fountain pens, and from witchcraft to gardening.

Today the 2.6 version of Mastodon has been released. It now has built-in support for “rel=me”, which allows verification. Meaning that I can show on my Mastodon profile a link to my site and can proof that both are under my control.

Rel=me is something you add to a link on your own site, to indicate that the page or site you link to also belongs to you. The page you link to needs to link back to your site and make it reciprocal. This is machine readable, and allows others to establish that different pages are under control of the same person or entity.

On my own site I use ‘rel=me’ in the about section in the right hand column. First, if you check the html source of my page, you’ll see that I say that this site (zylstra.org/blog) is my primary site, by making it the only link that has a ‘u-uid’ class (uid is unique id). It also has rel=”me”, meaning the relationship I have with the linked site, is that it is me: 

class="u-url url u-uid uid" rel="me" href='https://www.zylstra.org/blog'

Further down in that About segment you find other links, to my Mastodon and Twitter profiles. If you look at those links you will see it says:

rel=”me” href=’https://m.tzyl.nl/@ton'

saying my Mastodon profile is also me, and similarly to say that a specific Twitter profile is also me (I maintain other Twitter profiles as well but they’re not me, but my company etc.):

rel=”me” href=’https://twitter.com/ton_zylstra'

To close the loop that allows verification that that is true, both my Mastodon profile and my Twitter profile need to link back to my site in a way that machines can check. For Twitter that is easiest: it has a specific place in a user profile for a website address. Like in the image below.

In Mastodon I can add multiple URLs to my profile but there was no way for me to explicitly say in my Mastodon profile that a specific link is the one that represents my online identity. But now I can add a rel=me link in my Mastodon profile, so that both my website and my Mastodon profile link to each other in a verifiable way, proving both are under my control. As you can see in the image below it was available on a single instance already for testing purposes (the green mark signifies verification with the linked site), and now with today’s release it is available to all Mastodon instances.

So how is verification of control over different pages by the same person useful? It may be useful to show that another Twitter profile with my name is not me, because there’s no two-way link between that profile and my site. If you have multiple rel=me references it becomes harder for others to fake specific parts of your online identity. Further, it allows additional functionality like logging in on a different site using credentials from another site you control. It also makes it possible to map networks, and discovery. Site X links to profile X with rel=me on Twitter. There X follows Y, and Y’s profile says, site Y is under her control. Now I know that Site X and Site Y’s authors are somehow connected. If I’m following site X, I may find it interesting to also regularly read site Y.

As soon as my Mastodon instance has been updated to the latest version, which will likely be sometime today, I will add the rel=me in my Mastodon profile, making the link between this site and that profile verifiable.

[UPDATE] It now works on my Mastodon instance:

[TL;DR: A long tail is needed for distributed technology to be sustainable I think, otherwise it’s just centralisation and single points of failure in a different form. A long tail means the bottom 80% take over 50% of a market, and the top 20% under 50%. Mastodon currently has over 85% of its participants in the top 20% of instances, and it’s worse than that as 77% of participants are in 0,7% of instances. Just 15% are in the bottom 80% of instances. There’s a power law distribution, but it’s not a long tail. What can Mastodon do to get there and to sustainability?]

On 6 October 2016 Mastodon was launched, and its originator Eugen Rochko looks back in a blogpost on the journey of the past two years.

I joined on 7 April 2017, 6 months after its launch, at the Mastodon.cloud instance. I posted some messages for a month, then fell quiet for half a year. A few messages last March, and then I started using it more frequently last month, in the run-up to figuring out how to run Mastodon for myself (which for now means a hosted solution, but still aiming for running it from the home router). It’s now part of my daily information diet, but no guarantee yet it will last, although being certain I have ‘my half’ of the conversation on a domain I own helps a lot towards maintaining worthwhile exchanges.

Eugen’s blogpost is rightfully proud of what has been accomplished. It’s not yet proof of the sustainability of federated solutions though as he suggests.

He shares a few interesting numbers about the usage of Mastodon. The median of the 3460 known instances is 8 users. In total there are 1.627.557 registered accounts. The largest instance has 415.941 members, while the top 3 together have 52% of users, meaning the number 2 and 3 average 215.194 accounts. The top 25 largest instances have 77% or 1.253.219 members, meaning that the numbers 4-25 average 18.495 users. As the median is 8 it means the smallest 1730 instances have at most 8*1730 = 13.840 users. It also means that the number 26 to number 1730 instances have at least 360.498 members, or an average of 211. This tells us there’s a Pareto power law distribution: the top 20% of instances hold at least 85% of users at the moment. That also means there is no long tail, just a stub that holds at most 15% of Mastodon users only. For a long tail to exist, the smallest 80% of instances should account for over 50% of users, or over three times more than the current number.

As the purpose of Mastodon is distribution, where federation allows everyone to connect regardless of their instances (sort of like e-mail), I think Mastodon can only be deemed sustainable if there is a true long tail. Meaning, that while the number of users goes up, the number of instances should go up at a faster rate. So that over 50% of all Mastodon users will be on the 80% smallest or even individual instances. In the current numbers we should be most interested in the 50% of instances that now have 8 or less users, and find out what drives those instances, so we may have many many more of them. We should also think about what a bigger-to-smaller-instances funnel for members can look like, not just leave it to chance. I think that the top 25 Mastodon instances, which is just 0.7% of the total, currently having 77% of all users is very problematic from a sustainability perspective. Because that level of concentration is completely at odds with the stated purpose of Mastodon: distribution.

Eugen Rochko in his anniversary posting points at a critical article from April 2017 in Mashable, implying that criticaster has been been proven wrong definitively. I disagree. While much of the ‘predictions’ in that article are indeed silly, it also contains a few hints as to where sustainability may be found. The criticaster doesn’t get federation (yet likely uses mail everyday), and complains about discovery (yet likely is relieved not all his personal e-mail addresses are to be found in Google). Yet if we can’t explain distribution and federation, and can’t or don’t communicatie how discovery works in such a setting then we won’t be able to make a long tail grow. For more people to adopt small or individual instance we need to bring the threshold for running your own instance way down, and then way down again. To the level of at most one click installing a script on any regular hosting service, and creating a first account.

Using open protocols, like ActivityPub which Mastodon supports, is key in getting more people out of walled gardens and silos, and on the open web. Tracking its adoption is a useful measure of success, but 2 years of existence is not a sign of sustainability at all. What Eugen Rochko has kicked off with Mastodon is valuable and very laudable, but we have barely started getting to where we need to be for it to stick.

We’re in a time where whatever is presented to us as discourse on Facebook, Twitter or any of the other platforms out there, may or may not come from humans, bots, or someone/a group with a specific agenda irrespective of what you say or respond. We’ve seen it at the political level, with outside influences on elections, we see it in things like gamer gate, and in critiques of the last Star Wars movie. It creates damage on a societal level, and it damages people individually. To quote Angela Watercutter, the author of the mentioned Star Wars article,

…it gets harder and harder to have an honest discussion […] when some of the speakers are just there to throw kerosene on a flame war. And when that happens, when it’s impossible to know which sentiments are real and what motivates the people sharing them, discourse crumbles. Every discussion […] could turn into a […] fight — if we let it.

Discourse disintegrates I think specifically when there’s no meaningful social context in which it takes place, nor social connections between speakers in that discourse. The effect not just stems from that you can’t/don’t really know who you’re conversing with, but I think more importantly from anyone on a general platform being able to bring themselves into the conversation, worse even force themselves into the conversation. Which is why you never should wade into newspaper comments, even though we all read them at times because watching discourse crumbling from the sidelines has a certain addictive quality. That this can happen is because participants themselves don’t control the setting of any conversation they are part of, and none of those conversations are limited to a specific (social) context.

Unlike in your living room, over drinks in a pub, or at a party with friends of friends of friends. There you know someone. Or if you don’t, you know them in that setting, you know their behaviour at that event thus far. All have skin in the game as well misbehaviour has immediate social consequences. Social connectedness is a necessary context for discourse, either stemming from personal connections, or from the setting of the place/event it takes place in. Online discourse often lacks both, discourse crumbles, entropy ensues. Without consequence for those causing the crumbling. Which makes it fascinating when missing social context is retroactively restored, outing the misbehaving parties, such as the book I once bought by Tinkebell where she matches death threats she received against the sender’s very normal Facebook profiles.

Two elements therefore are needed I find, one in terms of determining who can be part of which discourse, and two in terms of control over the context of that discourse. They are point 2 and point 6 in my manifesto on networked agency.

  • Our platforms need to mimick human networks much more closely : our networks are never ‘all in one mix’ but a tapestry of overlapping and distinct groups and contexts. Yet centralised platforms put us all in the same space.
  • Our platforms also need to be ‘smaller’ than the group using it, meaning a group can deploy, alter, maintain, administrate a platform for their specific context. Of course you can still be a troll in such a setting, but you can no longer be one without a cost, as your peers can all act themselves and collectively.
  • This is unlike on e.g. FB where the cost of defending against trollish behaviour by design takes more effort than being a troll, and never carries a cost for the troll. There must, in short, be a finite social distance between speakers for discourse to be possible. Platforms that dilute that, or allow for infinite social distance, is where discourse can crumble.

    This points to federation (a platform within control of a specific group, interconnected with other groups doing the same), and decentralisation (individuals running a platform for one, and interconnecting them). Doug Belshaw recently wrote in a post titled ‘Time to ignore and withdraw?‘ about how he first saw individuals running their own Mastodon instance as quirky and weird. Until he read a blogpost of Laura Kalbag where she writes about why you should run Mastodon yourself if possible:

    Everything I post is under my control on my server. I can guarantee that my Mastodon instance won’t start profiling me, or posting ads, or inviting Nazis to tea, because I am the boss of my instance. I have access to all my content for all time, and only my web host or Internet Service Provider can block my access (as with any self-hosted site.) And all blocking and filtering rules are under my control—you can block and filter what you want as an individual on another person’s instance, but you have no say in who/what they block and filter for the whole instance.

    Similarly I recently wrote,

    The logical end point of the distributed web and federated services is running your own individual instance. Much as in the way I run my own blog, I want my own Mastodon instance.

    I also do see a place for federation, where a group of people from a single context run an instance of a platform. A group of neighbours, a sports team, a project team, some other association, but always settings where damaging behaviour carries a cost because social distance is finite and context defined, even if temporary or emergent.

    Previously I had tried to get GNU Social running on my own hosted domain as a way to interact with Mastodon. I did not get it to work, for reasons unclear to me, I could follow people on Mastodon but would not receive messages, nor would they see mine.

    This morning I saw the message below in my Mastodon timeline.

    It originates from Peter Rukavina’s own GNU Social install. So at least he got the ‘sending mentions’ part working. He is also able to receive my replies, as my responses show up underneath his original message. Including ones I limited the visibility of it seems.

    Now I am curious to compare notes. Which version of GNU Social? Any tweaks? Does Peter receive my timeline? How do permissions propagate (I only let people follow me after I approve them)? And more. I notice that his URL structures are different from those in my GNU Social install for instance.

    After I moved my Mastodon accounts from a general server to a self-run instance last week, I was curious to see how many of the followers I had on the old account would make the move to my current Mastodon account. After all the ‘cost of leaving’ is always a consideration when changing course in social media usage, in this case specifically the portability of your existing network. Last week I had 43 followers on the old account, and I now have 11 on my new account, so that is about 25%. Let’s see if it grows in the coming days. Likely some of the followers I had no longer use Mastodon. So another question is when I reach the same number of followers by engaging in new conversations.

    As I didn’t succeed yet in getting Mastodon to run on a Raspberry Pi, nor in running a Gnu Social instance that actually federates on my hosting package, I’ve opted for an intermediate solution to running my own Mastodon instance.

    Key in all this is satisfying three dimensions: control, flexibility and ease of use. My earlier attempts satisfy the control and flexibility dimensions, but as I have a hard time getting them to work, do not satisfy the ease of use dimension yet.

    At the same time I did not want to keep using Mastodon on a generic server much longer, as it builds up a history there which with every conversation ups the cost of leaving.

    The logical end point of the distributed web and federated services is running your own individual instance. Much as in the way I run my own blog, I want my own Mastodon instance.

    Such an individual instance needs to be within my own scope of control. This means having it at a domain I own. and being able to move everything to a different server at will.

    There is a hoster, Masto.host run by Hugo Gameiro, who provides Mastodon hosting as a monthly subscription. As it allows me to use my own domain name, and provides me with admin privileges of the mastodon instance, this is a workable solution. When I succeed in getting my own instance of Mastodon running on the Rapsberry Pi, I can simply move the entire instance at Masto.host to it.

    Working with Hugo at Masto.host was straightforward. After registering for the service, Hugo got in touch with me to ensure the DNS settings on my own domain were correct, and briefly afterwards everything was up and running.
    Frank Meeuwsen, who started using Masto.host last month, kindly wrote up a ‘moving your mastodon account’ guide in his blog (in Dutch). I followed (most) of that, to ensure a smooth transition.

    Using Mastodon? Do follow me at https://m.tzyl.nl/@ton.

    Screenshots of my old Mastodon.cloud account, and my new one on my own domain. And the goodbye and hello world messages from both.

    Today I had a bit of time to try running Mastodon on Raspberry Pi again. Last week I got stuck as some of the mentioned dependencies in the Mastodon installation guide could not be installed. As the step where I got stuck deals with a different Linux version, I tried simply skipping to the next step.

    From the linked guide the steps ubuntu dependencies, node.js repository, yarn repository did not work.
    The step after that, for various other dependencies, works again (which includes yarn actually).
    Then a few steps follow that need to be executed as the specific user for mastodon. Installing ruby and node.js works fine, and almost all steps to install ruby and node.js dependencies. The final 2 steps of the dependencies throw errors (bundle install and yarn install). As at least some parts of the bundle install command do get executed, but not all. These are the last two steps before actually getting into configuring the installation, so it feels like being nearly there.

    I’d have to dive deeply into the logfiles to see what wasn’t installed and what is missing. Not sure if I will easily find time to do so, and if I would actually understand what the log files tell me. It is also unclear if there is a relationship with the three steps I have skipped earlier in the process as they didn’t work.

    In the past few days I tried a second experiment to run my own Mastodon instance. Both to actually get a result, but also to learn how easy or hard it is to do. The first round I tried running something on a hosted domain. This second round I tried to get something running on a Raspberry Pi.

    The Rapsberry Pi is a 35 Euro computer, making it very useful for stand-alone solutions or as a cheap hardware environment to learn things like programming.

    20180923_144442Installing Debian Linux on the Rapsberry Pi

    I found this guide by Wim Vanderbauwhede, which describes installing both Mastodon and Pleroma on a Raspberry Pi 3. I ordered a Raspberry Pi 3 and received it earlier this week. Wim’s guide points to another guide by on how to install Ruby on Rails and PostgresSQL on a Rapsberry Pi. The link however was dead, and that website offline. However archive.org had stored several snapshots, which I save to Evernote.

    Installing Ruby on Rails went fine using the guide, as did installing PostgresSQL. Then I returned to Wim’s guide, now pointing to the Mastodon installation guide. This is where the process currently fails for me: I can’t extend the Ubuntu repositories mentioned, nor node.js.

    So for now I’m stalled. I’ll try to get back to it later next week.

    My first steps experimenting with a self-run Mastodon instance were a bit disappointing. However I came across this guide by Wim Vanderbauwhede to run a Mastodon or Pleroma instance on a Raspberry Pi 3b. I’m definitely going to try this. A Raspberry Pi will be delivered after the weekend. In parallel I will try and update my GnuSocial instance I installed earlier to see if it improves functionality.

    At our birthday unconference STM18 last week, Frank gave a presentation (PDF) on running your own website and social media tools separate from the commercial silos like Facebook, Twitter etc. Collected under the name IndieWeb (i.e. the independent web), this is basically what used to be the default before we welcomed the tech companies’ silos into town. The IndieWeb never went away of course, I’ve been blogging in this exact same space for 16 years now, and ran a personal website for just under a decade before that. For broader groups to take their data and their lives out of silos it requires however easy options out, and low-threshold replacement tools.

    One of the silos to replace is Twitter. There are various other tools around, like Mastodon. What they have in common is that it’s not run by a single company, but anyone can run a server, and then they federate, i.e. all work together. So that if I am on server 128, and you are on server 512 our messages still arrive in the right spot.

    I’ve been looking at running a Mastodon instance, or similar, myself for a while. Because yes, there are more Mastodon servers (I have accounts on mastodon.cloud and on mastodon.nl), but I know even less about who runs them and their tech skills, attitudes or values than I know about Twitter. I’ve just exchanged a big silo for a smaller one. The obvious logical endpoint of thinking about multiple instances or servers, is that instances should be individual, or based on existing groups that have some cohesion. More or less like e-mail, which also is a good analogy to think of when trying to understand Mastodon account names.

    Ideally, running a Mastodon instance would be something you do yourself, and which at most has your household members in it. Or maybe you run one for a specific social context. So how easy is it, to run Mastodon myself.

    Not easy.

    I could deploy it on my own VPS. But maintaining a VPS is rather a lot of work. And I would need to find out if I run the right type of operating system and other packages to be able to do it. Not something for everyone, nor for me without setting aside some proper time.

    Or I could spin up a Mastodon instance at Amazon’s server parks. That seems relatively easy to do, requiring a manageable list of mouse clicks. It doesn’t really fit my criteria though, even if it looks like a relatively quick way to at least have my own instance running. It would take me out of Twitter’s software silo, but not out of Amazon’s hardware silo. Everything would still be centralised on a US server, likely right next to the ones Twitter is using. Meaning I’d have more control over my own data, but not be bringing my stuff ‘home’.

    Better already is something like Masto.host, run by a volunteer named Hugo Gameiro who’s based in Portugal. It provides ease of use in terms of running your own instance, which is good, but leaves open issues of control and flexibility.

    So I’d like a solution that either can run on a package with my local hosting provider or figure out how to run it on cheap hardware like Raspberry Pi which can be connected to my home router. The latter one I’d prefer, but for now I am looking to learn how easy it is to do the former.

    Mastodon and other similar tools like Pleroma require various system components my hosting provider isn’t providing, nor likely to be willing to provide. Like many other hosters they do have library of scripts you can automatically install with all the right dependencies and settings. In the section ‘social media’ it doesn’t mention Mastodon or any other ‘modern’ varity, but they do list GnuSocial and its predecessor StatusNet. GnuSocial is a script that uses the same protocols like Mastodon, OStatus and ActivityPub. So it should be able to communicate with Mastodon.

    I installed it and created an account for myself (and myself as administrator). Then I tried to find ways to federate with Mastodon instances. The interface is rather dreadful, and none of the admin settings seemed to hint at anything that lies beyond the GnuSocial instance itself, no mention of anything like federation.

    The interface of GnuSocial

    However in my profile a button labelled “+remote” popped up. And through that I can connect to other people on other instances. Such as the people I am connected to on Mastodon already. I did that, and it nicely links to their profiles. But none of their messages show up in my stream. Even if it looks I can send messages to them from my GnuSocial instance as I can do things like @someotheruser, they don’t seem to arrive. So if I am indeed sending something, there’s no-one listening at the other end.

    I did connect to others externally

    And I can send messages to them, although they do not seem to arrive

    So that leaves a number of things for next steps to explore. Also on Mastodon in conversation with Maarten I noticed that I need to express better what I’m after. Something for another posting. To be continued.