#xmpp #omemo #conversations #psi #gajim #zom #chatsecure #dino #jsxc #federation #encryption
Why it took us more than two years to enable End-to-End encryption by default: The first in a series of essays leading up to the release of Conversations 2.0
The other big hurdle we had to overcome was the adoption rate in clients. If you send OMEMO encrypted messages by default you should have a reasonable expectation that your contact will be able to decrypt the message. Reasonable expectation doesn’t mean that every single client out there has to support it—In an ecosystem with hundreds of small, badly maintained clients that’s just not feasible—but the major clients should at least have a plugin available.
In March 2018 we finally reached the point where every plattform has one or more clients with OMEMO support. Conversations and Zom on Android, ChatSecure on iOS, Psi and Gajim on the desktop. The up and coming desktop client Dino—despite not having had an initial release—already has support for OMEMO as well. And even the webclient JSXC has a plugin available.
Considering the complexity of OMEMO and the fact that most of these clients are developed by people in their spare time, this is actually quite an impressive adoption rate.
Moxie Marlinspike, in his 2016 propaganda piece ignorantly bashing XMPP, had one valid point: Enabling end-to-end encryption in a homogenous environment is easier than introducing it in a heterogenous one like Jabber. Nobody is denying that. However, if something is hard to achieve there are two possible approaches: Either try your best and don’t give up, or put your head in the sand and create yet another walled garden that is no different from other proprietary solutions.
Admittedly it has taken us a while to get to a point where we can enable end-to-end encryption by default, but it was worth the effort in that we ended up with something that is different from WhatsApp in more than just marketing.
#slack #xmpp #federation #surveillancecapitalism
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.
I have grudgingly joined three Slack workspaces, due to me being part of proejects that use it as a communications center for their participants. Why grudgingly? Because there is very little that it adds to well-established communications standards that we have had for long ~~years~~ decades.See also @Carl Chenet, another Debian developer, post The Slack Threat.
On this topic, I must refer you to the talk and article presented by Megan Squire, one of the clear highlights of my participation last year at the 13th International Conference on Open Source Systems (OSS2017): «Considering the Use of Walled Gardens for FLOSS Project Communication». Please do have a good read of this article.
Thing is, after several years of playing open with probably the best integration gateway I have seen, Slack is joining the Embrace, Extend and Extinguish">-minded companies. Of course, I strongly doubt they will manage to extinguish XMPP or IRC, but they want to strengthen the walls around their walled garden...
So, once they have established their presence among companies and developer groups alike, Slack is shutting down their gateways to XMPP and IRC, arguing it's impossible to achieve feature-parity via the gateway.
Of course, I guess all of us recognize and understand there has long not been feature parity. But that's a feature, not a bug! I expressly dislike the abuse of emojis and images inside what's supposed to be a work-enabling medium. Of course, connecting to Slack via IRC, I just don't see the content not meant for me.
The real motivation is they want to control the full user experience.
Well, they have lost me as a user. The day my IRC client fails to connect to Slack, I will delete my user account. They already had record of all of my interactions using their system. Maybe I won't be able to move any of the groups I am part of away from Slack – But many of us can help create a flood.
Say no to predatory tactics. Say no to Embrace, Extend and Extinguish. Say no to Slack.
Language will probably be English or German. Or Volapük. Let's see.
Let's talk about Movim, and about the XMPP Summit!
This time, we will talk about Movim (the "kick ass social network"!), and about the latest XMPP Summit, which took place in Brussels a few weeks ago. Hope to see you all on Monday!
Version 0.3, 2017-12-30#xmpp #jabber #spam #spim #yaxim #draft #federation #abuse #server #s2s #manifesto
The Jabber network (a federated set of thousands of servers with many
tens or hundreds thousands of users) is under a continuous flood of spam
messages for multiple years. Similar to the open email relays of the
mid-1990s, public (and often abandoned) XMPP servers are being abused to
deliver those messages.
We, as the operators of public XMPP servers, commit to the following
Server Policies to fight spam on our servers, and we announce our intent
to block incoming communication from public servers that distribute spam
messages and do not adhere to the Server Policies. Furthermore, we
will inform other Public Server operators and the general public of
domains sending spam and not reacting to abuse reports.
A Public Server is an XMPP server that allows both the registration of
accounts by third parties (either via [In Band Registration][XEP-0077]
or by other means, like a web form), and federation to other XMPP
servers, making it possible for its users to reach out to other XMPP
The operators of a Public Server shall perform the following actions to
* Implement [XEP-0157: Contact Addresses for XMPP Services][XEP-0157] and
react to incoming abuse reports in a timely fashion.
* Limit the number of new user registrations per IP address and hour.
* Monitor or block registrations from IP addresses with bad reputation
(open proxy servers, Tor exit nodes), or enforce additional checks on
those users, like a CAPTCHA or a valid phone number.
* Throttle the traffic from local clients, especially unsolicited
subscription requests and messages.
With our signature under this Manifesto, we assure that our servers are
already following the above stated Server Policies.
Starting with July 1st, 2018, we will start blocking incoming server
connections from Public Servers not following the Server Policies above,
if those are forwarding spam messages to our users. The blocking message
will contain a reference to this Manifesto.
Georg Lukas, yax.im (https://yaxim.org/yax.im/)
* Ported to GTK3 / Python3Congratulations!
* Flatpak support
* Lots of refactoring
* New Emoji support
* New Chat Window design
* New StartChat Window (Ctrl+N)
* New ServerInfo Window
* AccountWindow Redesign
* Moved some encryption code out into Plugins (see PGP Plugin, Esessions Plugin)
* OTR Plugin was not ported, use OMEMO
* Added mam:1 and mam:2 support (mam:0 was removed)
* Added MAM for MUCs support
* Added support for showing XEP-0084 Avatars
* Added xmpp URI handling directly in Gajim
* Removed Gajim-Remote
* Removed XEP-0012 (Last Activity)
* Removed XEP-0136 (Message Archiving)
* Added XEP-0156 (Discovering Alternative XMPP Connection Methods)
* Added XEP-0319 (Last User Interaction in Presence)
* Added XEP-0380 (Explicit Message Encryption)
* Added Jingle FT:5 support
Movim is a distributed social networking platform founded in 2010. It can be accessed using existing XMPP clients and Jabber accounts, and is a free and open source software licensed under the AGPL.#movim #ejabberd #socialnetwork #federation #xmpp #agpl #prosody #debian #freesoftware
With version 0.12 released in October, Movim migrated its official server to ejabberd. Before, they were using Metronome, a Prosody fork. Today, we are chatting with Timothée Jaussoin, the founder of Movim, about this very complex migration.
We now have a proper packaging for our Linux distribution – Debian, which certainly makes it easier to maintain. There’s also an improved scalability and more stable CPU and memory consumption, which helps to predict hardware requirements.
Even if I see ejabberd more as a tool that needs integration and tuning to create a proper platform, ejabberd seems to be the more serious solution to build proper messaging systems using the XMPP protocol.
$ echo deb https://deb.debian.org/debian/ experimental main | sudo tee /etc/apt/sources.list.d/experimental.list
$ sudo apt update
$ sudo apt -t experimental install dino-im
<br> ## Settings related to relays<br> relay: ## Section<br> <br> ## Relays are applications that exist to push public posts around to<br> ## pods which want to subscribe to them but would not otherwise<br> ## receive them due to not having direct contact with the remote pods.<br> ##<br> ## See more regarding relays: https://wiki.diasporafoundation.org/Relay_servers_for_public_posts<br> <br> outbound: ## Section<br> ## Enable this setting to send out public posts from this pod to a relay<br> send: true<br> ## Change default remote relay url used for sending out here<br> url: 'https://relay.iliketoast.net/receive/public'<br> <br> inbound: ## Section<br> ## Enable this to receive public posts from relays<br> subscribe: true<br> <br> ## Scope is either 'all' or 'tags' (default).<br> ## - 'all', means this pod wants to receive all public posts from a relay<br> ## - 'tags', means this pod wants only posts tagged with certain tags<br> scope: tags<br> <br> ## If scope is 'tags', should we include tags that users on this pod follow?<br> ## These are added in addition to 'pod_tags', if set.<br> include_user_tags: true<br> <br> ## If scope is 'tags', a comma separated list of tags here can be set.<br> ## For example "linux,diaspora", to receive posts related to these tags<br> pod_tags: "diaspora, podmin"<br> <br>
While Signal technically is free software it doesn't feel like free software.
You can change it, but then you're no longer welcome in the Signal ecosystem and can't send messages to other Signal users.
But Riot has other advantages that make it, in some aspects, superior to Signal. Riot is based on the so-called Matrix protocol which is a federated protocol. That means that anyone who wants can run a Matrix server can do so and Riot users from all these servers can communicate with one another. There is no central instance that controls Matrix or Riot.
Today, the new attempt is Keybase.io, which many users like for its convenience (linking PGP keys to social media accounts). But it fundamentally violates the end-to-end privacy principle of PGP by binding keys to privacy-invading services. Periodically, he said, proposals pop up to implement "validating" PGP keyservers—but none of them work in a decentralized fashion. He urged users to stand up against all attempts to centralize PGP.
Finally, he looked at federation in general. Mail servers have more and more difficulty interoperating, he said, and XMPP has "lost its track" and is being replaced by centralized systems like WhatsApp and Signal. He encouraged developers to make federation a priority and to design for it from the beginning.