9 changed files with 361 additions and 31 deletions
@ -0,0 +1,99 @@ |
|||
Title: Have you considered the alternative? |
|||
Date: 2017-3-9 |
|||
Category: a x-post |
|||
Tags: xmpp, conversations, instant messaging, ecosystem |
|||
Slug: have-you-considered-the-alternative |
|||
Summary: *This article first appeared on <https://homebrewserver.club> on the 9th of March of 2017.* <hr> Signal is often considered an alternative to Whatsapp, but is it really? Why you should gather a group of friends and consider staring into the abyss of self-hosted, federated messaging services. |
|||
|
|||
|
|||
>"Remember, when advertising is involved you the user are the product. [...] |
|||
>When people ask us why we charge for WhatsApp, we say 'Have you considered the alternative?'" |
|||
|
|||
<small>Brian Acton and Jan Koum, June 2012[^1] </small> |
|||
|
|||
>"Facebook today announced that it has reached a definitive agreement to acquire WhatsApp, a rapidly growing cross-platform mobile messaging company, |
|||
>for a total of approximately $16 billion, including $4 billion in cash and approximately $12 billion worth of Facebook shares." |
|||
|
|||
<small> Facebook Newsroom, February 2014[^2]</small> |
|||
|
|||
>"[B]y coordinating more with Facebook, we'll be able to do things like track basic metrics about how often people use our services and better fight spam on WhatsApp. |
|||
>And by connecting your phone number with Facebook's systems, Facebook can offer better friend suggestions and show you more relevant ads if you have an account with them." |
|||
|
|||
<small> Brian Acton and Jan Koum, August 2016[^3]</small> |
|||
|
|||
|
|||
Pattern Recognition |
|||
=== |
|||
|
|||
WhatsApp started out full of dreams: "we want WhatsApp to be the product that keeps you awake...and that you reach for in the morning. No one jumps up from a nap and runs to see an advertisement"[^4]. When they thought of WhatsApp, Brian Acton and Jan Koum were very keen on *not* selling our user data for targeted advertisement purposes. So they charged a nominal rate for the use of their service, rightfully pointing out the hidden cost of using free services. |
|||
|
|||
In the year of 2014 however, WhatsApp was bought by Facebook, thus joining the social network's happy and expanding family of venture capital investments, a family including Instagram, purchased in April 2012, and Oculus VR, purchased the month before. At the time, many, and with good reason, worried about the changes this acquisition could entail for WhatsApp. Eventually, in August 2016, WhatsApp users everywhere learned about what was in fact unavoidable. The company that built its reputation upon an ad-free ethic, would now be sharing private user information with Facebook, its parent company. So we, the users, are the product after all, and as expected, this is presented in the form of an *improvement* of the user experience. Thanks to the tighter coordination between WhatsApp and Facebook, we can now more easily find our friends or see more valuable messages from the companies that truly matter to us. Of course, small footnote, these 'benefits' comes at the price of sharing our phone number and other private data with Facebook—though, trusting their word, not the content of the messages themselves. |
|||
|
|||
Facebook does this for the simple reason that it needs to increase its market share on mobile devices[^5]; the family of Whatsapp, Facebook and Instagram are all *different* channels leading to this same purpose. One of the consequences of this is that while Facebook's chat function can still be used on their mobile website, plans are that we will soon be forced to install Facebook Messenger should we wish to continue using it on our mobile phones[^6]. Once again, in a stroke of pure genius and creativity, this move is being marketed as a way to provide us with the best experience ever. And we can use it with just a phone number, we don't even need a Facebook account. That way, their user base expands along with their profits. |
|||
|
|||
Every time there is a breach of user trust —read: a change in the Terms of Service— or news regarding network surveillance, people are on the lookout for an alternative, and rightfully so. In these moments there are many also willing to promote such *alternatives*, usually in the form of yet another disruptive app. After the purchase of Whatsapp, for example, Telegram was advertised as the alternative. After it became clear that Telegram had dreadful security, people promoted Viber. Then Snapchat, then Threema, then Allo and now Signal. There is a reason why we’re falling into this pattern of needing alternatives to the alternatives. And that is because... |
|||
|
|||
There are no alternatives. |
|||
=== |
|||
|
|||
There's a tendency to oversimplify the issues related to the use of these apps as merely a privacy matter, and not even that is sufficiently addressed. While each of the aforementioned apps are alternative companies and brands, what these alternatives all have in common is that they share the same model. A model that revolves around centralized services, vendor lock-in and marketing related surveillance, and all of that within a neoliberal context of the free market. These alternatives therefore promote themselves as more than just an alternative, but also as competing products, usually highlighting a particular feature lacking in rivals' products. Remember that ill-fated, super cool, nice looking alternative to Facebook, Ello? It gained a lot of traction out of legitimate concerns with Facebook's modus operandi, promoting itself as an alternative for its nice features and its promise not to use advertising. But as Aral Balkan was quick to point out, allowing investments by venture capital firms meant the project was dead before it really began[^7]. Taking these investments, which allowed them to scale as a platform, also meant that they would, at some point, *have* to make a lot of money for their investors. How? By selling ad space or information about their users. The reason the pattern keeps repeating itself is not because the makers of these apps always secretly intended to sell your data while saying they wouldn’t. The reason is that they have no choice within the economic system they choose to operate in. |
|||
|
|||
Cryptography matters, but then it also doesn’t |
|||
=== |
|||
|
|||
The latest competitive feature—one might even say, marketing trick—to make concerned users switch from one alternative to another is cryptography, the act of coding messages during communication. This strategy works well because the vast majority of people are not really informed when it comes down to the technicalities of cryptography, so this discourse mostly serves to throw bedazzling sparkles in our eyes. To be sure, cryptography is fundamental for privacy. However, the main privacy threat in the context of using these apps isn't the potential of a government eavesdropping on our communications. The privacy threat is the wholesale and increasing dependence on centralized services which revolve around the surveillance and monetization of user information. In 2016, both WhatsApp and Facebook Messenger enabled end-to-end encryption[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#e2e) to address increasing privacy concerns. Adding *crypto* to a communication app in this case merely obfuscates a concern about the hegemony of these platforms. In essence, the issue of privacy is much larger than just the lack of cryptography; the conditions that threaten privacy are structural and economic and not resolved by a *patch* or a new feature. |
|||
|
|||
This issue is further stressed when looking at the question of metadata, that is to say, data about data, which in the case of communication applications is everything but the communication data itself. When WhatsApp started sharing, among other things, its users' phone numbers with its parent company, Facebook, it went to great lengths to guarantee us that the content of our messages was still perfectly secure, impossible to be read by both WhatsApp and Facebook. The argument stating that "It's only metadata, don't worry" has been however debunked numerous times. Even though these platforms would love us to believe otherwise, metadata is neither a trivial disposable by-product, nor it is anonymous. And assuming that the crypto is sound and that the app running this crypto is not flawed, cross-referencing several databases containing metadata will always produce an array of very personal information, that in itself is much more valuable than encrypted naked selfies. Thus it should be no surprise that former NSA director Michael Hayden infamously said in 2012 "we kill based on metadata"[^8] and later argued in 2015 that metadata should be the main area of focus of surveillance activities, and not the creation of backdoors within crypto, or the banning of the latter[^9]. |
|||
|
|||
In short, both Whatsapp and FacebookMessenger can afford to deploy end-to-end encryption for your messages because it won’t hurt their bottom line, which is making money based on the surveillance of your behavior and your social graph. Adding crypto thus merely patches your privacy worries, but not the threat to it. |
|||
|
|||
The Wrong Signal[^10] |
|||
=== |
|||
|
|||
The end-to-end encryption enabled in WhatsApp and Facebook Messenger has been developed by Open Whisper Systems, a non-profit run by crypto-celebrity Moxie Marlinspike. OWS also developed the algorithm for their own instant messaging application, Signal, and then open-sourced it. Signal itself is now the latest app being promoted as an alternative to WhatsApp and is hailed as the panacea of both security and usability. It even has the backing of members of the dissident elite such as Edward Snowden. |
|||
|
|||
While OWS provides thorough expertise in the field of cryptography, Marlinspike is currently advocating centralisation as the only answer towards user-friendly, fast and secure messaging apps. Decentralisation, according to him, has no place in the modern world and apparently hampers innovation. However, some of his arguments have not remained unchallenged. In particular, where Marlinspike accuses federation of stalling evolution[^11], Daniel Gultsch[^12] provides a counter argument by using the Web as an example of successfully federated system[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#federated). Furthermore, Gultsch states that the problem is not that federation doesn't adapt, but rather that there are problems with its implementation for a very significant reason: software developers working on federated systems mostly work for free in their spare time or with little means, given the difficulty to monetise a system which design can only succeed if it is open and can be appropriated easily beyond its original scope, and thus making its capitalisation particularly challenging. In that sense, the most interesting aspect of this debate is that while Marlinspike seems to defend his product from a technological perspective, Gultsch's counter argument moves back the discussion to the context of political economy. |
|||
|
|||
Daniel Gultsch is an important counter-voice because he is the main developer behind Conversations[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#conversations). This open-source instant messaging app tries to be both accessible for new users as well as provide enough flexibility for more advanced users. In that regard, Conversations itself does not manage to escape the logic of competition and the discourse around *alternative* superior apps discussed previously. However, its approach is significantly different because unlike any other apps, Conversations is not a complete solution, nor does it present itself as such. It is a client that relies on federation, which means that it allows for people to chat with each other regardless of what provider they are using. In concrete terms, there is no central server directly connected to Conversations, but Conversations can connect to different chat servers. This is possible because Conversations is built upon a long-lived messaging protocol called XMPP[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#xmpp). |
|||
|
|||
XMPP, the federated messaging protocol |
|||
=== |
|||
|
|||
Up to a few years ago XMPP and its implementations were lagging behind in terms of mobile features, usability and interface design[^13]. That was the so-called lack of evolution Moxie pointed out. But recently Gultsch and the other contributors to Conversations have managed to bring XMPP up to speed with the functionality of well known mobile messenger applications. Not only did this demonstrate that bridging the gap could be done technically, but it also had the effect of breathing new life into the XMPP community. An example of this new energy was the initiative to create and implement OMEMO[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#omemo), an XMPP Extension Protocol[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#xep) that provides multi-user end-to-end encryption and which is based on Signal's own encryption algorithm. Ever since a growing number of clients have started implementing OMEMO, including Gajim[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#gajim) for desktops and ChatSecure[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#chatsecure) for iPhones[^14]. |
|||
|
|||
Gultsch succeeded[ref]His XMPP client Conversations has been installed between [10 and 50 thousand times](https://play.google.com/store/apps/details?id=eu.siacs.conversations&hl=en) and he is able to live off and work full-time on the project[/ref] so far precisely because of understanding the technical underpinnings of centralized services[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#centralized) such as WhatsApp or Signal. It is however a bitter-sweet victory, because as Gultsch articulated in his defense of decentralisation, the main difference between centralised and decentralised implementations is not only technical, but also a matter of economic sustainability. In other words, if his ongoing efforts show that it is possible to have a satisfying and safe user experience *while* using federated alternatives, this is only possible because, unlike any other XMPP client developers, he is in the position of working on this project full time. The problem has not been solved but shifted. |
|||
If economically sustainable XMPP federation were to scale to the point of being as successful as the centralised solution offered by Signal, it would have to face the consequences of doing so in the context of a free market driven by competition. In that situation, each XMMP client's economic viability would depend heavily on its capacity to capture enough users that can provide income for their developers. The problem therefore is not so much a problem of the technical or economical sustainability of federation, but more a problem of the economic sustainability of open standards and protocols in a world saturated with solutionist business models. After all, many years ago, Google and Facebook did provide XMPP support in their chat applications before deciding to close its interoperability. |
|||
|
|||
|
|||
Approaches not Apps |
|||
=== |
|||
|
|||
Given the different problems mapped in this text, it becomes difficult to blindly recommend Conversations as the superior alternative, that is to say, a near drop-in replacement to Signal or any other competing secure communication software. |
|||
The reason is not technical but is linked to the fact that, as discussed earlier, Conversations' own success relies on an economic model that is quite fragile, and the success of which—and it's a paradox—could potentially undermine the cultural diversity of the XMPP ecosystem. |
|||
With that said, there are however two essential points that the Conversations case brings up. These points are not always articulated clearly in discussions on federation: scale and trust. |
|||
|
|||
Rather than having to swap one app for the other in an attempt to mitigate a large and confusing privacy problem, the XMPP federation approach allows to collectively tackle the problem based on its various discrete parts. Such an approach, rather than suggesting a singular and proprietary solution, allows for the existence of different free and open source software servers which can be combined with different free and open source software clients. That makes it possible for you and a group of friends to run your own infrastructure, whether on a rented server or on a very small home server. |
|||
The federated nature of the protocol allows you to try, play and experiment with different network infrastructures with different clients. These clients can range from custom XMMP bots to general instant messengers that you would be able recommend your friends and family to replace Whatsapp, without making a fool of yourself. As these open-source technologies continue to evolve you can make incremental changes to your server or switch clients as newer versions arrive. |
|||
Hosting your own infrastructure allows you to scale your communication in a way that is the most meaningful for the group or community you belong to. It is also a way to make sure your system matches your own threat model[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#threat), while simultaneously allowing you to deal with trust that is not mediated by an app. It also allows you to experiment with economic models other than those linked to large-scale infrastructure involving surveillance and capturing of your social graph for financial gain. Maybe you want to share the cost of the server or the responsibilities of administrating it, maybe you want to collectively learn how to run all this stuff, or maybe you want to start meetings to exchange tips, etc. However, this does not mean that you need to cut yourself off from the rest of the world and this form of localism should not be misunderstood for a hipsterist and reactionary form of escapism. Instead, such an approach is quite the opposite as it provides a possibility to actively engage with societal issues. It allows groups to collectively think, in the sense of defining questions and hypotheses themselves, acquire skills and knowledge and respond to issues that are both relevant to their own situation but that can also resonate globally, enabling others to start a similar process. |
|||
|
|||
The goal of this article was to provide some tools and insights which not only allow for contextualisation of the technology we are using and supporting, but also help making sure that the instant-messaging you and your friends use happens in a trusted and secure environment, as much as possible outside the economies of surveillance. For this reason our motivation for writing this article was two-fold. On the one hand we wanted to show that the issue of privacy is more insidious than institutional eavesdropping and not merely solved with the use of end-to-end encryption. On the other hand, and as a consequence, we wanted to suggest not a different app, but a different approach altogether on the basis of XMPP federation and collective action. Therefore we've written two guides. [One on how to configure a server](http://homebrewserver.club/configuring-a-modern-xmpp-server.html) and [one on how to choose and use clients](http://homebrewserver.club/picking-modern-xmpp-clients.html) that can go along with it. These allow you to put a self-hosted approach, an approach that brings aspects of trust, scale and implementation to the forefront and into practice. Once again, such guides should not be perceived as definitive answers but more as tools to keep us, and hopefully you too, busy formulating the right questions and building networks of mutual help. |
|||
So while we are unable to recommend you the next big app that will solve all user surveillance and financialisation once and for all—as we are pretty sure no such app will ever even exist—we hope to at least help shed a light on the confused and confusing discourses that surround crypto-sound alternatives which may obfuscate less obvious problems. |
|||
|
|||
[^1]: <https://blog.whatsapp.com/245/Why-we-dont-sell-ads> |
|||
|
|||
[^2]: <http://newsroom.fb.com/news/2014/02/facebook-to-acquire-whatsapp/> |
|||
|
|||
[^3]: <https://blog.whatsapp.com/10000627/Looking-ahead-for-WhatsApp> |
|||
|
|||
[^4]: <https://blog.whatsapp.com/245/Why-we-dont-sell-ads> |
|||
|
|||
[^5]: <https://www.theguardian.com/technology/2016/aug/25/whatsapp-to-give-users-phone-number-facebook-for-targeted-ads> |
|||
[^6]: <https://www.theguardian.com/technology/2016/jun/06/facebook-forcing-messenger-app-explainer> |
|||
[^7]: <https://ar.al/notes/ello-goodbye/> |
|||
[^8]: <https://www.youtube.com/watch?v=UdQiz0Vavmc> |
|||
[^9]: <https://www.c-span.org/video/?402284-1/discussion-immigration-policy-national-security> |
|||
[^10]: <https://it-kollektiv.com/wrong-signal-das-falsche-signal-engl/> |
|||
[^11]: <https://whispersystems.org/blog/the-ecosystem-is-moving> |
|||
[^12]: <https://gultsch.de/objection.html](https://gultsch.de/objection.html> |
|||
[^13]: <https://op-co.de/blog/posts/mobile_xmpp_in_2014/> |
|||
[^14]: <https://omemo.top/> |
|||
|
After Width: | Height: | Size: 2.0 KiB |
@ -0,0 +1,30 @@ |
|||
Title: Federated Ecosystems |
|||
Category: an introduction |
|||
slug: welcome-to-the-federation |
|||
tags: Wtt�F, software, design |
|||
summary: Welcome to the � Federation explores alternative federated ecosystems for online services such as **social media** and **chat**. It will focus in particular on those software projects whose activities have stimulated new interest for their underlying protocols, such as XMPP or ActivityPub, in part by their focusing on design, language and user experience (UX). The Wtt�F question is to explore how arts and design communities can play a supportive role in these processes by contributing skills, knowledge, time and exposure. |
|||
|
|||
|
|||
Welcome to the � Federation explores alternative federated ecosystems for online services such as **social media** and **chat**. It will focus in particular on those software projects whose activities have stimulated new interest for their underlying protocols, such as XMPP or ActivityPub, in part by their focusing on design, language and user experience (UX). |
|||
|
|||
The Wtt�F question is to explore how arts and design communities can play a supportive role in these processes by contributing skills, knowledge, time and exposure. |
|||
|
|||
## Federation instead of centralized systems |
|||
|
|||
Over the past few years there has been a renewed interest in 'alternative' on-line services such as social media and chat[^1]. These are services that promise to provide different experiences and models to the ones we are used to seemingly for free from corporations like Google, Facebook and Twitter. |
|||
|
|||
Some of these alternatives are that in name only. These alternatives promise to be something else from the start, but often end up being more of the same since they use similar or identical business models as the platform they pretend to be an alternative to. In essence a different brand serving the same product. |
|||
|
|||
Others projects take a different approach. They challenge the current state of affairs by putting effort in building fundamentally different ecosystems based around free software and open protocols. |
|||
|
|||
One of the ways this current state of affairs is challenged is by insisting on **federation**, as opposed to centralized structures. Federation is the idea that various actors decide to cooperate in a collective fashion to make a network. Distributing responsibility and power as they do so. |
|||
|
|||
These software practices can be understood as forms enacted criticism, developing a theoretical critique of systems into concrete and practical responses. |
|||
|
|||
## Wtt�F in 2018 & 2019 |
|||
|
|||
Wtt�F will host a series of gatherings that invite developers of these software projects and people active in arts and design. An evening of **presentation** and discussion is combined with a hands-on **worksession** during the day. |
|||
|
|||
For these worksessions the invited developers will introduce and outline a few issues in the context of language, design and UX that participantes are invited to respond to. Concrete contributions are explored as a way to introduce these critical software practices in a tangible way. |
|||
|
|||
[^1]: Any time there is large scandal relating to privacy or the concentration of power of cloud companies, there are attempts and campaigns to delete social media. This was notable after the Snowden revelations, most recently #deleteFacebook was a popular item. |
|||
@ -1,4 +1,4 @@ |
|||
Title: ii-gallery |
|||
Title: Gallery |
|||
slug: gallery |
|||
|
|||
|
|||
@ -1,26 +0,0 @@ |
|||
Title: i-introduction |
|||
Category: an introduction |
|||
slug: welcome-to-the-federation |
|||
tags: Wtt�F, software, design |
|||
|
|||
Over the past few years there has been a renewed interest in 'alternative' on-line services such as social media and chat[^1]. These are services that promise to provide different experiences and models to the ones we are used to seemingly for free from corporations like Google, Facebook and Apple. |
|||
|
|||
Some of these alternatives are that in name only. These alternatives promise to be something else from the start, but often end up being more of the same since they use similar or identical business models as the platform they pretend to be an alternative to. In essence a different brand serving the same product. |
|||
|
|||
Others projects take a different approach. They challenge the current state of affairs by putting effort in building fundamentally different ecosystems based around free software and open protocols. |
|||
|
|||
One of the ways this current state of affairs is challenged is by insisting amongst on federated, as opposed to centralized structures. Federation is the idea that various actors decide to cooperate in a collective fashion to make a network. Distributing responsibility and power as they do so. |
|||
|
|||
These software practices can be understood as forms enacted criticism, developing a theoretical critique of systems into concrete and practical responses. |
|||
|
|||
The interest of *Welcome to the � Federation* is to consider software projects that are working towards alternative federated ecosystems. In particular those projects whose activities have reinvigorated interest for their underlying protocols, in part by their focusing on design, language and user experience (UX). |
|||
|
|||
The Wtt�F question is to explore how arts and design communities can play a supportive role in these processes by contributing skills, knowledge, time and exposure. |
|||
|
|||
## Wtt�F in 2018 & 2019 |
|||
|
|||
Wtt�F will host a series of two-day gatherings that invite developers of these software projects and people active in arts and design. After an evening of presentation and discussion on the first day, the second day will be dedicated to a hands-on worksession. |
|||
|
|||
For these worksessions the invited developers will introduce and outline a few issues in the context of language, design and ux that participantes are invited to address. Concrete *contributions* are explored as a way to introduce these critical software practices in a tangible way. |
|||
|
|||
[^1]: Any time there is large scandal relating to privacy or the concentration of power of cloud companies, there are attempts and campaigns to delete social media. This was notable after the Snowden revelations, most recently #deleteFacebook was a popular item. |
|||
@ -0,0 +1,29 @@ |
|||
Title: 'The Ecosystem is Moving' a gathering with Daniel Gultsch |
|||
Category: gathering |
|||
Date: 05-01-2018 |
|||
slug: conversations-gultsch |
|||
tags: instant messaging, conversations, xmpp |
|||
featured_image: images/fi_im.jpg |
|||
|
|||
On the 1st and 2nd of June [*varia*](https://varia.zone/en/) will host 'The Ecosystem Is Moving', a presentation by and worksession with Daniel Gultsch about federated instant messaging, open source software and the sustainability of open systems. |
|||
|
|||
* June 1st, 19.00 - 22.00 - **presentation**: introduction to XMPP and lecture by Daniel Gultsch |
|||
* June 2nd, 10.00 - 18.00 - hands on [**worksession**](/conversations-gultsch.html#worksession) on design and federated chat systems. Please register for the worksession via `info * varia.zone` |
|||
|
|||
Daniel Gultsch is the developer behind [Conversations](https://conversations.im), an open source instant messaging application for Android. In 2014, he decided to work full time on Conversations and try to <!-- PELICAN_END_SUMMARY --> make a living from it. Rather than starting from scratch with Conversations, he built it as a client for the existing federated messaging protocol XMPP. |
|||
|
|||
Since an XMPP messenger can, in a way, only be as good as the entire ecosystem, Daniels work on Conversations also meant work on expanding and improving that larger XMPP ecosystem. This work includes helping to draft and implement protocol standards, such as OMEMO, a modern and user-friendly end-to-end encryption based on Signal's protocol. He also contributed code to other XMPP servers and clients in the ecosystem to bring them up to speed with modern uses. Additionally, [through his critical essays](https://gultsch.de/xmpp_2016.html) he is a vocal defender of XMPP and open standards in general. |
|||
|
|||
Conversations is notable because, through its continuous focus on user experience, design and security it has garnered a lot of interest for both itself and the XMPP ecosystem as a whole. This makes it an interesting example to talk about what the design field could potentially contribute to critical software practices. |
|||
|
|||
## <a id="worksession">about the worksession</a> |
|||
|
|||
Depending on the amount of participants during the **worksession** we plan to look at the following concrete tasks: |
|||
|
|||
* Redesigning the group chat details to show contextual information about the specific chat, such as groupchat images and descriptions. |
|||
* Revisit the language (and possibly translations) used in the application to increase usabillity. |
|||
* Improve the documentation on how to install and use Conversations |
|||
|
|||
While Wtt�F encourages people with a background in arts and design to join, the worksessions are welcoming to anyone with an interest in learning more about XMPP and contributing to the ecosystem. Programming skills are not necessary to participate, although an affinity with the usage of computers and smartphones is helpful. The primary language of the worksession will be English. |
|||
|
|||
The worksession takes place from 10:00 to 18:00 in Varia, Gouwstraat 3, Rotterdam. Lunch is provided. Please register in advance by sending a mail to `info[at]varia.zone` |
|||
@ -0,0 +1,168 @@ |
|||
title: The Ecosystem is Moving, a worksession with Daniel Gultsch - documentation |
|||
Category: report |
|||
Date: 06-10-2018 |
|||
author: Cristina Cochior |
|||
slug: conversation-with-daniel-gultsch |
|||
tags: Wtt�F, worksession, documentation |
|||
summary: A detailed report of the day. |
|||
|
|||
|
|||
# Conversations workshop |
|||
|
|||
[https://pad.vvvvvvaria.org/WttF.The-Ecosystem-is-Moving.worksession |
|||
](https://pad.vvvvvvaria.org/WttF.The-Ecosystem-is-Moving.worksession |
|||
) |
|||
|
|||
## Implementing conviviality in multi-user chat environments |
|||
|
|||
On Saturday the 2nd of June, Varia held a work session around the digital interface design of the federated chat client Conversations together with its developer, Daniel Gultsch. |
|||
|
|||
 |
|||
Work session, Saturday 2 June |
|||
|
|||
During this day, we focused on the group chat interface as a key element for sociality afforded by the XMPP protocol. XMPP stands for Extensible Messaging and Presence Protocol and has its roots in the Jabber community. The protocol emerged in 1999 as a decentralised, secure and open alternative to commercially-driven instant messaging services and included specifications for various types of XML data exchanges. Two of them are one-to-one and many-to-many instant messaging, the latter being also called MUCs (multi-user chats). Since then it has undergone several transformations, but the key elements have remained unchanged. |
|||
|
|||
The history of the protocol and commitment of the community behind it have informed the current design of the Conversations client; some of the terminology, for example “roster”, is still being used. |
|||
|
|||
 |
|||
|
|||
We started by listing all of the features of the user interface design: |
|||
|
|||
At the top of the phone screen, the room name that was configured by the room owner is shown. If the group doesn't have a name, it will be assigned a combination of the nicknames of the participants. |
|||
|
|||
Below are the room ID of the group chat that is randomly generated by the Jabber server, thus often difficult to read for users, and information about the user: the avatar, their nickname and their role within the chat. |
|||
|
|||
What follows is the room roster, the client's representation of the list of occupants, described by their names and their nicknames for the particular session. And at the end of the list is a button to invite new members into the room. |
|||
|
|||
MUCs can be of many types: |
|||
|
|||
1. public vs. hidden |
|||
2. persistent vs. temporary |
|||
3. password-protected vs. unsecured |
|||
4. members-only vs. open |
|||
5. moderated vs. unmoderated |
|||
6. non-anonymous vs. semi-anonymous |
|||
|
|||
For example, group chats can be non-anonymous or semi-anonymous, depending on whether the full Jabber IDs (JIDs) of the members are visible or not. Considering that some of the groups have several hundreds of participants, the ability to hide one's full Jabber ID is very handy. Nonetheless, it will still be visible to the group owner and administrators. |
|||
|
|||
Groups can also be split into members-only and open. Based on this setting, the group determines who is allowed to join the chat and how easy it is to find through search. |
|||
|
|||
Most groups on XMPP are: |
|||
* Members-only and non-anonymous |
|||
* Open and semi-anonymous |
|||
|
|||
A MUC user – or what the XMPP protocol calls an “occupant” - can have multiple affiliations: owner, member, administrator, none and outcast. |
|||
|
|||
An owner is in practice only one, the person that created it. |
|||
An administrator has similar rights as those of the owner, but without the possibility to make other occupants adminstrators, to change the group configuration or to destroy the room. |
|||
A participant has the right to participate in the conversation, as opposed to visitors (no affiliation), who can only observe. Lastly, an outcast is a user which has been banned from a group chat. |
|||
|
|||
There are a few design qualities that make Conversations stand out from other commercially-driven alternatives, such as Whatsapp or Telegram. For example, there is no indication as to when a user was last active. Presence is a matter of debate within the XMPP community: while Conversations has chosen not to display the availability of a user in individual chats, the implementation has made its way to the group chat as a result of popular demand. |
|||
|
|||
In order to understand other ways in which it differs from alternatives, we looked at a collection of chat clients to compare their group chat affordances. |
|||
|
|||
## Signal |
|||
|
|||
 |
|||
|
|||
The group chat banner takes up a high percentage of the screen, there is a section for shared media, you can mute group chats, or set the ringtone/vibrations settings for notifications. |
|||
The current members are displayed in a list without avatars: since Signal is based on a person's phone number as an identity, it doesn't need to give a lot of descriptors. |
|||
|
|||
## Telegram |
|||
|
|||
 |
|||
|
|||
You can change the name and the avatar of the group chat. (Currently, the group avatars in Conversations are generated from some of the members' avatars. It isn't possible yet to add one.) The menu includes options such as: edit, find members, remove group, abandon group and add a shortcut. The last function adds a shortcut to the group on the desktop. Below that are settings for the notifications, a shared media section, add member option and at the bottom is the list of current members. In order to indicate who is the owner of the group chat, Telegram adds a star to the person's name. |
|||
|
|||
|
|||
 |
|||
|
|||
<!--  --> |
|||
|
|||
Another important feature are the sticker sets on Telegram. Users have the possibility to upload their own images that are then made available to anyone else using the app. The sticker sets have become one of its most appealing functions, leading to a quite a large variety in subject choice and tone of humour that is all conjured by the users. |
|||
|
|||
|
|||
## Facebook Messenger |
|||
|
|||
 |
|||
|
|||
Facebook Messenger has many options for personalisation: Color, Emoji, Nicknames, Search in conversation. Some of these functions are convivial in nature, for example, the nicknames are not a necessity, but they add a feeling of informality within the group. Although they may seem frivolous, these features contribute to the atmosphere of the chat. In contrast, Conversations is following the tradition of XMPP and IRC chats, which are most often used by developers. As a result, efficiency and privacy are some of the core values of the app. But considering that default settings change depending on whether you are in a public or private group, this can be altered. |
|||
|
|||
Our task for the day became to consider ways in which we can introduce a sense of intimacy into the app's group chat design: how to pay attention to features that are often considered “silly”, but make a space feel more homely; how to implement conviviality. |
|||
|
|||
Facebook Messenger puts a lot of effort into the features that make a group chat more hospitable: being able to give nickna mes to your friends, change the colour of the chat, or select an emoji for the conversation. |
|||
|
|||
Another interesting design choice we observed in Messenger is to have the options categorised and displayed into subscreens, which could be implemented into Conversations as well. The clunkiness and length of the list of options is also the reason why Daniel has not yet implemented Search For Words in the conversation, despite the fact that it wouldn't be a technical issue. |
|||
|
|||
Conversations has been making similar attempts, but in some of the situations it faces technical challenges. For example, it is difficult to choose a banner for the group, because of the technical restriction on the image sizes. Traditionally, each XML packet in XMPP has an upper limit of 10.000 bytes. Despite the fact that many servers have increased this number, one shouldn't assume that all of them have done so. It would be possible to reach an agreement to raise the upper limit, but this is a consensus that must be reached among thousands of servers. Until then, the default size of the image is 196x196 pixels in Conversation (extended from the usual 64x64 pixels), a size that can be read by all XMPP servers with which a user makes contact. |
|||
|
|||
## WeChat |
|||
|
|||
 |
|||
|
|||
WeChat is a Chinese chat application. The group chat interface has a few functionalities that are particular to itself: for example, you can subscribe to feeds of group members, you can pay them, search for people from your contact list that are nearby, or you can make your own emojis within the application by uploading the images directly into the chat – the application will do the background detection and removal for you. |
|||
|
|||
In WeChat, private group chats can be accessed by entering a four digit code and having the GPS activated to check that one is in the vicinity of the other group members. |
|||
|
|||
When looking at the group members list, it was interesting to observe that WeChat shows each participant's avatar above their name and turn each participant into an equally-sized block. |
|||
|
|||
Other options that stood out included: |
|||
* Clear Chat History and |
|||
* Delete and Leave. |
|||
|
|||
## Conversations interface, the group chat info view |
|||
|
|||
After going through the different takes we continued the afternoon by redesigning the existing Conversations group chat interface. |
|||
|
|||
We defined the user scenarios in which someone would arrive to that page as being: |
|||
* Wanting to add a new member, |
|||
* Wanting to remove a user, |
|||
* Wanting to proomote a user to an administrator, |
|||
* Changing your own notification settings, |
|||
* Changing name, avatar, subject, nick |
|||
* Seeing who's part of the group, |
|||
* Knowing which specific account you're using for the chat, |
|||
* Sharing the group by creating QR codes. |
|||
|
|||
|
|||
Below are some of the observations and the mockups that the participants came up with: |
|||
|
|||
 |
|||
Adding banner images for MUCs. Considering the technical limitations that the images are subject to, the banner could be composed of a different rearrangement of the user profile pictures, or it could be a blurred expanded version of the profile picture. |
|||
|
|||
Many of the workshop participants' efforts went towards creating a distinct identity for the group chats. Attention was given to the order in which the participants appear: the user who's viewing it can be shown first, but there should be no hierarchy between the rest. |
|||
|
|||
 |
|||
Another suggestion was to use a blurred version of one of the profile pictures as banners. |
|||
|
|||
 |
|||
One of the suggestions was to separate the menu into relevantly categorised options. |
|||
|
|||
 |
|||
Many of the ideas seemed to reverberate around the room. Other participants also suggested to use a different model to the list in displaying the members. |
|||
|
|||
 |
|||
The action of long tapping as a way to access functions was brought into question as it may not be an obvious route for everyone. Removing the role of the speaker from the list leads to a less hierarchical read. |
|||
|
|||
 |
|||
Regrouping of the options list. |
|||
|
|||
 |
|||
 |
|||
One design proposal flipped the perspective from that of a developer to that of a general user. |
|||
|
|||
All of the participants approached the group-indentity-forming aspects of the design: shared media, avatars and banners the group, or pinning messages to the top of the group chat. |
|||
|
|||
## Final outcomes: |
|||
|
|||
 |
|||
|
|||
The final outcomes cater to the perspective of the general user over that of an administrator or an owner. By attempting to use formats that overcome the hierarchy of the list, such as grids, the participants made tweaks to the design that create context around the group beyond the technical information: what is the group for? Who is part of the group? What do they share? What is their humour like? |
|||
|
|||
 |
|||
|
|||
|
|||
|
|||
|
|||
## Further reading: |
|||
[XMPP Multi-User Chat Extension](https://xmpp.org/extensions/xep-0045.html#roles-default) |
|||
@ -0,0 +1,30 @@ |
|||
Title: The Ecosystem Is Moving - documentation |
|||
Category: report |
|||
Date: 06-08-2018 |
|||
slug: documentation-conversations-gultsch |
|||
tags: instant messaging, conversations, xmpp, documentation |
|||
featured_image: images/fi_im.jpg |
|||
|
|||
|
|||
On the 1st and 2nd of June [*varia*](https://varia.zone/en/) hosted 'The Ecosystem Is Moving', a lecture by and worksession with [Daniel Gultsch](https://gultsch.de). |
|||
|
|||
## Talk |
|||
|
|||
Because of the audience's familiarty with the project the lecture turned more into an open conversation with many questions from the audience. We also couldn't resist hosting and displaying a [chat room](xmpp://wttf@muc.vvvvvvaria.org?join) during the talk for people online also to join in. |
|||
|
|||
<iframe width="560" height="315" sandbox="allow-same-origin allow-scripts" src="https://video.vvvvvvaria.org/videos/embed/0a16d1e5-59de-473d-89b1-958422ec2251" frameborder="0" allowfullscreen></iframe> |
|||
|
|||
Video documentation by [Michaela Lakova](http://mlakova.org/) |
|||
|
|||
For notes taken during the talk have a look [here](https://pad.vvvvvvaria.org/WttF.The-Ecosystem-is-Moving.talk) |
|||
|
|||
## Worksession |
|||
|
|||
The worksession itself was based around rethinking and designing the way Conversations displays information about chat groups. Arguably one of the most important features of any chat system, the groupchat view had been underdeveloped in Conversations. During the worksession we discussed the various types of groupchats that exist in the XMPP ecosystem, ranging from public topical rooms to private chats of groups of friends. By comparing what choices other chat applications make and getting a sense of what is (im)possible in the XMPP ecosystem (see [Cristina Cochior's writeup for more details](conversation-with-daniel-gultsch.html) participants got a good idea of where to go. |
|||
|
|||
Then we spent the afternoon doing a few different wireframes. These different designs all made different choices in accessibility, UX, customization. |
|||
|
|||
 |
|||
The group chat details view from Conversations version 2.2.3 and 2.2.4 where some of the propsed changes have already been implemented |
|||
|
|||
For notes of the worksession have a look [here](https://pad.vvvvvvaria.org/WttF.The-Ecosystem-is-Moving.worksession). |
|||
Loading…
Reference in new issue