A metaphor and a an addition related to my earlier wonderings about Mastodon and upload filtering:

It’s as if because of a law requiring hammers to be registered, you’re wondering if you’re going to register your screwdriver. Just because some people use the handle of their screwdriver to hit a nail occasionally, and ignore its primary functionality.

Yes there are very large Mastodon instances, the top 3 hold over 50% of all users. These instances might well fall within scope of the EU Copyright Directive. But ‘fixing’ the underlying ActivityPub protocol or federation isn’t the issue here. Fixing big instances is. In fact most Mastodon users, as they are on the biggest instances, don’t use federation at all because most of their interaction is within the same instance. Mastodon.social, pawoo.net and mstdn.jp, the 3 biggest instances, I’d argue are hardly part of the fediverse, despite e.g. mastodon.social being its poster child and point of entry for most.

Don’t make someone’s bloated instance’s issue to be a huge issue for the fediverse as a whole

Jerome Velociter has an interesting riff on how Diaspora, Mastodon and similar decentralised and federated tools are failing their true potential (ht Frank Meeuwsen).

He says that these decentralised federated applications are trying to mimic the existing platforms too much.

They are attempts at rebuilding decentralized Facebook and Twitter

This tendency has multiple faces
I very much recognise this tendency, for this specific example, as well as in general for digital disruption / transformation.

It is recognisable in discussions around ‘fake news’ and media literacy where the underlying assumption often is to build your own ‘perfect’ news or media platform for real this time.

It is visible within Mastodon in the missing long tail, and the persisting dominance of a few large instances. The absence of a long tail means Mastodon isn’t very decentralised, let alone distributed. In short, most Mastodon users are as much in silos as they were on Facebook or Twitter, just with a less generic group of people around them. It’s just that these new silos aren’t run by corporations, but by some individual. Which is actually worse from a responsibility and liability view point.

It is also visible in how there’s a discussion in the Mastodon community on whether the EU Copyright Directive means there’s a need for upload filters for Mastodon. This worry really only makes sense if you think of Mastodon as similar to Facebook or Twitter. But in terms of full distribution and federation, it makes no sense at all, and I feel Mastodon’s lay-out tricks people into thinking it is a platform.

This type of effect I recognise from other types of technology as well. E.g. what regularly happens in local exchange trading systems (LETS), i.e. alternative currency schemes. There too I’ve witnessed them faltering because the users kept making their alternative currency the same as national fiat currencies. Precisely the thing they said they were trying to get away from, but ending up throwing away all the different possibilities of agency and control they had for the taking.

Dump mimicry as design pattern
So I fully agree with Jerome when he says distributed and federated apps will need to come into their own by using other design patterns. Not by using the design patterns of current big platforms (who will all go the way of ecademy, orkut, ryze, jaiku, myspace, hyves and a plethora of other YASNs. If you don’t know what those were: that’s precisely the point).

In the case of Mastodon one such copied design pattern that can be done away with is the public facing pages and timelines. There are other patterns that can be used for discoverability for instance. Another likely pattern to throw out is the Tweetdeck style interface itself. Both will serve to make it look less like a platform and more like conversations.

Tools need to provide agency and reach
Tools are tools because they provide agency, they let us do things that would otherwise be harder or impossible. Tools are tools because they provide reach, as extensions of our physical presence, not just across space but also across time. For a very long time I have been convinced that tools need to be smaller than us, otherwise they’re not tools of real value. Smaller (see item 7 in my agency manifesto) than us means that the tool is under the full control of the group of users using it. In that sense e.g. Facebook groups are failed tools, because someone outside those groups controls the off-switch. The original promise of social software, when they were mostly blogs and wiki’s, and before they morphed into social media, was that it made publishing, interaction between writers and readers, and iterating on each other’s work ‘smaller’ than writers. Distributed conversations as well as emergent networks and communities were the empowering result of that novel agency.

Jerome also points to something else I think is important

In my opinion the first step is to build products that have value for the individual, and let the social aspects, the network effects, sublime this value. Value at the individual level can be many things. Let me organise my thoughts, let me curate “my” web, etc.

Although I don’t fully agree with the individual versus the network distinction. To me instead of just the individual you can put small coherent groups within a single context as well: the unit of agency in networked agency. So I’d rather talk about tools that are useful as a single instance (regardless of who is using it), and even more useful across instances.

Like blogs mentioned above and mentioned by Jerome too. This blog has value for me on its own, without any readers but me. It becomes more valuable as others react, but even more so when others write in their own space as response and distributed conversations emerge, with technology making it discoverable when others write about something posted here. Like the thermometer in my garden that tells me the temperature, but has additional value in a network of thermometers mapping my city’s microclimates. Or like 3D printers which can be put to use on their own, but can be used even better when designs are shared among printer owners, and used even better when multiple printer owners work together to create more complex artefacts (such as the network of people that print bespoke hand prostheses).

It is indeed needed to spend more energy designing tools that really take distribution and federation as a starting point. That are ‘smaller’ than us, so that user groups control their own tools and have freedom to tinker. This applies to not just online social tools, but to any software tool, and to connected products and the entire maker scene just as much.

The Mastodon community worries about whether the new EU copyright directive (which won’t enter into force for 2 years) will mean upload filters being necessary for the use of the ActivityPub protocol.

I can’t logically see why that would be, but only because I don’t compare Mastodon to e.g. Twitter or Facebook. Yet if you do then the worry is logical I suspect.

Mastodon is a server and a client for the ActivityPub protocol. In a fully distributed instance of Mastodon you would have only a small group of users, or just one. This is the case in my Mastodon instance, which only I use. (As yet the Mastodon universe isn’t very distributed or decentralised at all, there’s no long tail.)

The ActivityPub protocol basically provides an outbox and inbox for messages. In your outbox others can come get messages you make available to them and your server can put messages in your outbox into someone else’s inbox itself.

The Mastodon server can make what you put into your outbox publicly available to all that way. Others can put messages for you in your inbox and the Mastodon client can show publicly what you receive in your inbox.

But making anything public isn’t necessary at all. In fact I don’t need my public facing profile and message timeline on my Mastodon instance at all. They are non-essential. Without such pages there’s no way to argue that the messages I receive in my inbox are uploaded by others to a platform, and falling within scope of a potential need for an upload filter.

My Mastodon instance isn’t a platform, and the messages others send to it aren’t uploads. The existence and form of other ActivityPub clients and servers demonstrates that neatly. I currently send ActivityPub messages from my weblog as well, without them being visible on my blog, and I can receive them in my Mastodon, or any other AP client without them being visible for others, just as I can read any answers to that message on the back-end of my blog without it being visible to anyone but me and the sender(s). Essentially AP is more like one-to-one messaging with the ability to do one-to-many and many-to-many as well.

The logical end game of decentralisation is full distribution into instances with only individuals or tight knit groups. Federated where useful. The way the Mastodon client is laid out (sort of like Tweetdeck) suggests we’re dealing with a platform-like thing, but that’s all it is: just lay-out. I could give my e-mail client a similar lay-out (one column with mail threads from my most contacted peers, one with mails just to me, one with all mails sent through the same mail server, one with all mails received from other mail servers by this one.) That would however not turn my mail server plus client into a platform. It would still be e-mail.

Mastodon’s lay-out is confusing matters by trying to be like Twitter and Tweetdeck instead of being its own thing, and I posit all ‘upload filter’ worries stem from this confusion.

Da’s wel een understatement ja, “de interface niet heel fijn in het gebruik”. Die interface is nog ronduit slecht. Zelf Aperture draaien lukt me nog niet, pogingen om het op mijn laptop als localhost te doen gingen mis. Dat zou ik nog prettiger vinden eigenlijk, op localhost, dan in mijn WP database al is dat al beter dan op de server van een ander. Om die reden speel ik ook nog met TinyTinyRSS, die is goed zelf te draaien (straightforward PHP and MySql), en je kunt makkelijk zelf in de code wat klooien. Ik zoek natuurlijk uiteindelijk het schaap met 5 of zelfs meer poten.

Replied to De indieweb leesmap mogelijkheden komen steeds dichterbij by Frank Meeuwsen

…nu blijkt er ook Yarns te zijn, een WordPress plugin te zijn die deze server integreert in je WordPress omgeving. Het is allemaal in beta en de interface vind ik niet heel fijn in gebruik…

Bryan Alexander writes a thoughtful post about media literacy, specifically in the US context, and in relation to the role of education, in response to an ongoing conversation on it:

How should we best teach digital and media literacy?  How can such teaching respond to today’s politically and technologically polarized milieu? Last week a discussion brewed across Twitter…

Towards the end of his critical discussion he makes

One more point: I’m a bit surprised to not see more calls for the open web in this conversation. If we want to get away from platforms we see as multiply dangerous (Facebook in particular, it seems), then we could posit some better sites. I’m for RSS and the blogosphere. Others may plump for Mastodon.

I think this an important aspect. To me the open web is about agency, the power to do something, to act. In this case to critically engage with information flows and contributing your own perspectives on your own website.

Every centralised platform or web silo you use means an implicit vulnerability to being kicked off by the company behind it for arbitrary and not just valid reasons. Even when using it, it means hard borders are drawn about the way you can share, interact or connect to others, to protect the business behind it. Facebook forces you to share links outside your commentary, and doesn’t allow inline hyperlinking as is actually the web’s standard. Your Facebook account can’t directly interact with my Twitter account, not because of technological limitations but because of both their wishes to be silos monopolising your online conversations.

On the open web you acknowledge the existence of various platforms, silos and whatnot, but the interaction circles around your own online space. Your own platform-of-1 that monopolises your own interaction but puts that monopoly in your own hands and that makes no assumption whatsoever about what others do, other than expecting others to use core internet standards and protocols. Your platform-of-1, is your online presence, like this website, from which you alone determine what you share, post, link-to, in what way it is presented, and who can see what.

This includes pushing things into silos. For instance I post to Twitter, and respond to others on Twitter from my own website, and reactions on Twitter come back to me on my website. (Not Facebook, you’re no longer allowed to post / peek over their fence).

This is a source of agency. For me as an individual, as much as for a group. There’s a marked difference between a protest group coordinating themselves on a Facebook group, and e.g. Edgeryders, a network of changemakers building sustainable projects for the common good, which runs their own group platform to interact using Discourse. A direct difference in agency to be able to shape the way you interact versus having to follow predefined common denominator functionality, and an indirect difference in resilience against push-back from others (does someone else control your off-switch?).

In media literacy, as much as in other, complexity-induced, aspects of our connected lives, agency of both you and yours, a networked agency is a key ingredient. Not to build your own competing platforms or media outlets to the existing ones, a common misconceived and unvoiced underlying assumption I feel (“we’ll build the perfect news platform ourselves!”), but to be in control yourself of what comes at you and what flows out from you. You still very well may end up in a bubble of uncritical bias, yet it will be one of your own making, not the making of whichever company happens to run the most popular platform du jour. The open web is your toolkit in gaining and maintaining this agency.

Replied to The powers of digital literacies: responding to danah boyd and all (Bryan Alexander)

Well, yes, some of that social ‘cost of leaving’ plays a role. Yet:

It’s part of my company’s journey to better information security and data protection. Leaving silo’s, and Slack is just as much one as is Facebook, although with a different business model, is part of that. Similarly we’re starting to use our own cloud, in order to not use Google docs, Onedrive and the like. Our clients have different (and contradictory) rules against some of those silos, and we want to offer our own environment in which we can collaborate with clients as well. So our cloud and our Slack replacement run on our own server in a Dutch data center. This makes it easier to show GDPR compliance as well.

Within the company I’m the only heavy Slack user, taking part in about half a dozen Slack spaces. Still 90% of my Slack interaction is within my company.

Importing our Slack history into Rocket.chat, as well as that the URL of our Rocket.chat space is called Slack, help make a soft landing. Similarly Rocket.chat’s interface is similar to Slack’s.

Our cloud integrates well with Rocket, better than with Slack.

For mobile having another app on it is hardly an issue, given we all have half a dozen chat apps on it already.
For desktop it will be less automatic to make the switch, but adding Rocketchat to the dock will help.

So, there will be an adaption cost, but I’m optimistic it will be low, given our starting point. Over time I’ll reflect on how it went.


Screenshot of Rocketchat with previous Slack historty loaded

Replied to a post by Frank Meeuwsen

Wat me bij deze diensten toch erg interesseert is de kosten van overstap voor de overige gebruikers. Met name de mentale overstap. Ik kan me voorstellen dat je huidige conversatiepartners in Slack zelf ook meer Slack-koppelingen hebben. Dan is het handig om alles bij elkaar in één Slack app te hebben. Rocketchat voelt dan als “weer een extra app” wat transitie en acceptatie lastiger kan maken. Ik ben benieuwd hoe je daar mee om gaat!

Rocketchat looks rather good as a Slack replacement! Open source, data on our own server. It has an import function for Slack exports so now that we have set up our own rocket chat server (named slack to make the switch easy on the mind), I’m importing all our Slack content over. Much better than staying with Slack which at our current usage level runs at about 75 Euro / month, whereas our managed hosting solution is 12 Euro / month including a 1 hr SLA response time. It integrates with our cloud, allowing direct drag and drop of any files.

Creating a #NextCloud cloud storage, archive and collaborative space for my company now that we have more employees. Sharing files between colleagues has become more important. Also we want to start providing access to files and sharing of files with clients through our own cloud, not through email or one of the cloud silos by Google, Microsoft or Dropbox. We also aim to replace Slack with e.g. Rocket chat.

With the CPH Techfestival announced I just booked my early bird ticket for this year’s event in early September.
Having signed the Copenhagen Letter in 2017, and having had to miss participating in the Copenhagen 150 to draft the Copenhagen Catalogue last year, I will attend this year.

Subscribe to humans is this year’s tagline. In my information strategies and rss-reading tactics, I always have done just that: subscribe to people, not sources or blogs. I aim to contribute my networked agency work to the mix in September.

As of today it is final: the new EU copyright directive has been adopted (ht Julia Reda). I am pleased to see my government voted against, as it has in earlier stages, and as my MEPs did. Sadly it hasn’t been enough to cut Article 11 and 13, despite the mountain of evidence and protests against both articles. It is interesting and odd to see both Spain and Germany vote in favour, given the failure of their respective laws on which Article 11 is based, and the German government coalition parties stated position of being against content filters (i.e. Article 13).

Over the next two years it is important to track the legislative efforts in Member States implementing this Directive. Countries that voted against or abstained will try to find the most meaningless implementation of both Articles 11 and 13, and will be emphasising the useful bits in other parts of the Directive I suspect, while subjected to intense lobbying efforts both for and against. The resulting differences in interpretation across MS will be of interest. Also looking forward to following the court challenges that will undoubtedly result.

In the mean time, you as an internet-citizen have two more years to build and extend your path away from the silos where Article 11 and 13 will be an obstacle to you. Run your own stuff, decentralise and federate. Walkaway from the big platforms. But most of all, interact with creators and makers directly. Both when it comes to re-using or building on their creations, as when it comes to supporting them. Article 11 and 13 will not bring any creator any new revenue, dominant entertainment industry mediators are the ones set to profit from rent seeking. Vote with your feet and wallet.

The Mozilla foundation has launched a new service that looks promising, which is why I am bookmarking it here. Firefox Send allows you to send up to 1GB (or 2.5GB if logged in) files to someone else. This is the same as services like Dutch WeTransfer does, except it does so with end-to-end encryption.

Files are encrypted in your browser, before being send to Mozilla’s server until downloaded. The decryption key is contained in the download URL. That download URL is not send to the receiver by Mozilla, but you do that yourself. Files can be locked with an additional password that needs to be conveyed to the receiver by the sender through other means as well. Files are kept 5 minutes, 1 or 24 hours, or 7 days, depending on your choice, and for 1 or up to 100 downloads. This makes it suitable for quick shares during conference calls for instance. Apart from the encrypted file, Mozilla only knows the IP address of the uploader and the downloader(s). Unlike services like WeTransfer where the service also has e-mail addresses for both uploader and intended downloader, and you are dependent on them sending the receivers a confirmation with the download link first.


Firefox Send doesn’t send the download link to the recipient, you do

This is an improvement in terms of data protection, even if not fully water tight (nothing ever really is, especially not if you are a singled out target by a state actor). It does satisfy the need of some of my government clients who are not allowed to use services like WeTransfer currently.