blog

Disabling Disqus comments on my blog

| categories: disqus, comments

I've decided to disable Disqus comments on this website. I was quite shocked recently when I saw tacky ads displayed in my blog. I've been using and ad blocker for so long that I never saw them, and only when I loaded my site in a new browser were the ads visible.

Advertising has its time and place. Being informed of a useful product or service can be valuable.

Like so many things in modern day society, the reality is far, far removed from the ideal. Much of modern day advertising is manipulation, trying to make you feel inadequate and lacking, so that you'll be more susceptible and willing to consume a new product.

Adam Curtis' documentary "Century of the Self" brilliantly lays out the development of marketing as a tool of mass manipulation.

The dominant form of advertising on the web, so-called Adtech, is outright fraudulent and user-hostile. Megabytes of JavaScript are included in webpages with the sole purpose of tracking you as you visit various websites so that they can build a more complete psychological profile of you.

In theory such a profile can help to inform you of products and services more akin to your needs and taste. In practice, it gets used to manipulate you and to reinforce your filter bubble.

I knew that Disqus is in this game as well, and should have acted sooner. I enabled Disqus comments probably about 5 or 6 years ago, when I was less concerned or aware of the problems of privacy and manipulation.

As always with information silos, the comments that were made on this website are now all locked away and lost to readers. Perhaps with the GDPR I can ask for them to be downloaded and then I can create a static representation of older comments.

Eventually I'd like to create a comments plugin with Converse.js and based on XMPP and use that on this site.


2018 Gulaschprogrammiernacht and organizing sprints for XMPP

| categories: xmpp, foss, omemo, converse.js, plone

Recently I attended the Gulaschprogrammiernacht for the first time.

It's a hacker/maker event in the Zentrum für Kunst und Medien (Centre for Arts and Media) in Karlsruhe, Germany.

AFAIK it's organized by the local chapter of the infamous Chaos Computer Club.

I heard about it from Daniel Gultsch on Twitter. It sounded like fun, so I decided to attend and spend the time adding OMEMO support to Converse.

Guus der Kinderen and I intended to organize an XMPP sprint for that weekend in Düsseldorf, but we were cutting it a bit fine with the organization, so I hoped that we could just shift the whole sprint to GPN.

Unfortunately Guus couldn't attend, but Daniel and Maxime Buquet (pep) did and I spent most of the event hanging out with them and working on XMPP-related stuff. The developers behind the Dino XMPP client also attended and hung out with us for a while and there was someone working on writing an XMPP connector for Empathy in C++.

XMPP hackers at Gulaschprogrammiernacht

Maxime worked on adding OMEMO support, to Poezio, and Daniel provided us with know-how and moral support. Daniel worked mainly on the Conversations Push Proxy.

We had some discussions around the value of holding regular sprints and I told them about my experience with sprints in the Plone community.

The Plone community regulary organizes sprints and they've been invaluable in getting difficult work done that no single company could or would sponsor internally. To me it's a beautiful example of what's been termed Commons-based peer production.

The non-profit Plone foundation provides funding and an official seal of approval to these sprints, and usually a sprint has a particular focus (such as adding Python3 support). Sprints can range from 3 people to 30 or more.

One difference between the Plone and XMPP communities, is that Plone is a single open source product on which multiple companies and developers build their businesses, whereas XMPP is a standardized protocol upon which multiple companies and developers create multiple products, some open source and some closed source.

In both cases however there is a single commons which community members have an incentive to maintain and improve as they build their businesses around it.

Another difference is between the Plone Foundation and the XMPP Standards Foundation. The XSF, for better or worse, interprets its role and function fairly strictly as being a standards organisation primarily focused on standardising extensions to XMPP, and less on community building or supporting software development.

Despite these differences, I still consider sprints a great way to foster community and to improve the extent and quality of XMPP-related software and documentation.

There is an interesting dynamic between cooperation and competition in both the Plone and XMPP communities. Participants compete with one another but they also have the shared goal of maintaining and growing a healthy software ecosystem.

Maxime was particularly excited by our discussion and very quickly put word into action by planning and announcing an XMPP sprint in Cambridge, UK in August.

There's still time to vote on the date of the sprint and to suggest topics.

Hopefully this will be first of many more sprints and communit events.

Unmanned laptops at the Gulaschprogrammiernacht

Slack's bait and switch

| categories: xmpp, foss, slack, converse.js

Slack has finally decided to close down their IRC and XMPP gateways.

True to form, you can only read their announcement if you already have a Slack account and are logged in to a workspace.

Here's the gist of their announcement:

As Slack has evolved over the years, we've built features and capabilities —
like Shared Channels, Threads, and emoji reactions (to name a few) — that the
IRC and XMPP gateways aren't able to handle. Our priority is to provide a
secure and high-quality experience across all platforms, and so the time has
come to close the gateways.

They're of course being economical with the truth here.

Perhaps their XMPP gateway can't handle "Shared Channels" and "Threads", but that's because they purposefully stopped working on it.

A "Shared Channel" simply means a chatroom which people from outside your workspace can participate in. If a workspace is mapped to a members-only chatroom, then making something a shared channel simply means updating the members list or making the chatroom open (so anybody can join it).

Threads can be implemented by adding a <thread> element in the message stanza, as documented in XEP-201.

And emoji... there's nothing in XMPP that prevents people from sending emoji.

Note

UPDATE: Several readers have pointed out that "emoji reactions" and emoji are different things. Emoji reactions can be tacked to a particular message.

Still, there's nothing fundamental about XMPP that prevents emoji reactions, and work is currently underway to add support for them.

The protocol is designed to be eXtensible (hence the X in XMPP) and new features are continuously being added.

Classic bait and switch

We all know the real reason Slack has closed off their gateways. Their business model dictates that they should.

Slack's business model is to record everything said in a workspace and then to sell you access to their record of your conversations.

They're a typical walled garden, information silo or Siren Server

So they have to close everything off, to make sure that people can't extract their conversations out of the silo.

We saw it with Google, who built Gtalk on XMPP and even federated with other XMPP servers, only to later stop federation and XMPP support in favour of trying to herd the digital cattle into the Google+ enclosure.

Facebook, who also built their chat app on XMPP at first allowed 3rd party XMPP clients to connect and then later dropped interoperability.

Twitter, although not using or supporting XMPP, had a vibrant 3rd party client ecosystem which they killed off once they felt big enough.

Slack, like so many others before them, pretend to care about interoperability, opening up just so slightly, so that they can lure in people with the promise of "openness", before eventually closing the gate once they've achieved sufficient size and lock-in.

On Federation

When we talk about "federation" in networks, we mean the ability to communicate between different service providers.

For example, email is federated. You can set up your own email server, and then send emails to people with their own email servers, or to people with Gmail or Yahoo! accounts.

You can email any other email address in the world, regardless of where that email address is hosted.

If email never existed, and a company like Slack today would come out with this brand new concept of "Electronic Mail", let's call it digimail, do you think they would standardise the digimail protocol and allow you to send messages to other digimail purveyors?

We all know the answer to that. They won't, and neither would Google, Microsoft or Facebook.

Heck, Facebook is actively trying to replace email since years.

The reason email is federated, is because it was developed before surveillance capitalism was a thing and because it was established and entrenched long before these companies came around.

There's a reason why your email address is still the de facto way to sign up for any service on the web (sometimes with one or two degrees of separation), and it's because of federation.

XMPP is designed to allow federation. Think about that. Instead of having to sign up to various different chat providers, all which try to lock you in and monetize your conversations, you could instead have one chat account, and use that to chat with anybody else, regardless of which chat provider they are using.

Alas, that's the dream, but because XMPP came much later to the scene, it didn't develop the critical mass as email has, and here we are. With dozens of chat apps, all non-interoperable and closed off.

What would it take for XMPP to take off?

One of the sad things that has come out of Slack's meteoric rise to success, has been how many free and open source projects have jumped over to using it (after previously using IRC or XMPP).

In so doing, they have closed off their discussions from search engines and they prevent people from accessing their past archives.

Slack has many cool features, and they work very well, I'm not going to deny it.

However, the XMPP Software Foundation has done a lot of work in recent years to enable protocol extensions that provide features that people have come to expect from chat applications, for example:

Unfortunately XMPP clients have been lagging far behind in various respects.

One of the main problems is funding. The modern digital economy is largely set up around surveillance capitalism and user lock-in.

So attempts to create software that doesn't follow these precepts, often end up unfunded or underfunded.

However, our "weakness", is also our strength.

XMPP clients, and the XMPP network can provide something that Slack never can. Federation, free and open software, interoperability, extensibility and user choice.

Converse.js

For the last few years I've been working in my spare time on making a JavaScript XMPP chat client, called converse.js.

Originally the idea was to make a Gtalk like chat client that you integrate in your website, and it can still be used like that.

A screenshot of converse.js as overlayed chatboxes

However, in the last year I've updated it further so that it can also be used as a fullscreen application, like Slack is used.

You can try the fullscreen version at https://inverse.chat/

A screenshot of converse.js as a fullscreen application

If you have no-one to chat to, then come join the discuss@conference.conversejs.org chat room.

This link will take you directly there (via inverse.chat): https://inverse.chat/#converse/room?jid=discuss@conference.conversejs.org

Converse.js still lacks lots of features that Slack has, but that's not because XMPP itself can't support those features.

What converse.js however does have, is that it's free and open source software, based on a standard protocol and it can be extended, updated and improved upon, by anyone.

We're actively working on adding new features and more and more people are joining in.

Moreover, anybody can host it and you can integrate it into any website.

Ultimately, I believe in the power and utility of interoperability and software freedom, even though the current trend is to close off and lock down.

These information silos are as powerful as we make them. If enough projects choose standardised protocols and FOSS software, we will be able to create viable alternatives that foster freedom instead of lock-in.

Note

Hacker News discussion

This blog post triggered a lively discussion on Hacker news, you can read that here: https://news.ycombinator.com/item?id=16567009


A badge for linking to your XMPP chat

| categories: xmpp, converse.js

You've probably noticed the coloured badges at the top of project READMEs on Github and Gitlab.

These badges indicate various metrics about the project's current state and its supporting infrastructure.

For example, the README page for converse.js contains the following badge:

Bountysource bounties

It indicates how many open bounties there are for converse.js on Bountysource.

There are dozens such badges available nowadays, just take a look at shields.io.

Some projects have badges that link to a chatroom, hosted by Gitter, Slack etc.

Converse.js, being an XMPP-based project, has its own XMPP chatroom at discuss@conference.conversejs.org.

So I created a badge for its README, which points to that chatroom and also indicates how many users are currently in it.

It looks like this:

Link to the Converse.js chatroom on inverse.chat

The Markdown syntax for showing the badge looks like this:

[![Link to XMPP chat](https://inverse.chat/badge.svg?room=discuss@conference.conversejs.org)](https://inverse.chat/#converse/room?jid=discuss@conference.conversejs.org)

The target URL for this badge is https://inverse.chat/#converse/room?jid=discuss@conference.conversejs.org, which means that it takes the user to https://inverse.chat and then once the user has logged in, the room discuss@conference.conversejs.org will be opened.

To go to a different room, just specify a different JID (Jabber ID) in the URL parameters.

The image URL is https://inverse.chat/badge.svg?room=discuss@conference.conversejs.org

Here you specify the room JID with the room URL parameter.

The image is an SVG which is generated by a tiny Flask app, which includes a chatbot written with SleekXMPP that checks how many users are in a particular chatroom.

The code is open source, and hosted on Github at jcbrand/xmpp-chat-badge.

If you're using this badge for your project, I'd be happy to hear about it.

You can let me know in the converse.js XMPP chatroom at discuss@conference.conversejs.org (or through the web with inverse.chat) or by using this website's contact form.


The 2018 XSF Summit

| categories: xmpp

This year I again attended the XMPP Software Foundation's summit in Brussels. The summit spans two days and is held at Cisco's offices.

It's a rare opportunity to get community members together to discuss and make decisions around protocol extensions (the so-called XEPs). On the second day interesting discussions were had regarding the state of XMPP today, for example how and by whom its used, how to foster and support client development and the merits of federation (i.e. communication between different messaging providers).

We heard that XMPP is heavily used and respected within the Telecoms industry, and that there's a lot of "hidden" use of XMPP that even most of the Summit participants were unaware of.

The distinction was made between XMPP, which represents the protocol, and Jabber®, which represents the ideal of federated instant messaging as used by end users.

Besides what some people may think, XMPP is alive and well, and used extensively in many applications and in various sectors.

Jabber®, on the other hand, not so much. Mindshare has moved largely to siloed (i.e. non-federated and non-standardized) messaging apps like Slack et al.

The Tigase guys Andrzej Wójcik and Daniel Wisnewski gave a demo of the new Internet-of-things module of the Tigase XMPP server which also drew attention at the realtime communications stand at FOSDEM.

Minutes for the XSF Summit

I volunteered to be the minute taker this year, for which I used my favorite notes-taking app: Vimwiki.

With Vimwiki you can generate HTML from your wiki files, so I was able to make the notes available online roughly as I was typing them. which I did by pushing the generated HTML to a git repo and then pulling again via cron on a server and serving with Nginx.

Me writing the notes at the summit.

I N C E P T I O N (an original piece by Guus der Kinderen)

I also wanted to make the minutes available on the XMPP wiki, but Vimwiki's syntax is a little bit different than the Mediawiki syntax.

Pandoc came to the rescue, and with a one-liner I could generate Mediawiki files from all my notes.

So here are the 2018 XSF Summit minutes on the XMPP wiki:

https://wiki.xmpp.org/web/Summit_22#Minutes

Final thoughts

It was fun to meet up again with kindred spirits and to see some familiar and friendly faces from the XMPP world.

This year was also the first time I attended the fancy XSF dinner. I had the sea bass with endive and beurre blanc.

See you folks next year and thanks for all the fish!

The XSF summit dinner.

Next Page »