Hello dear #fediverse I’ve been doing many research about #instant #messaging and I’d love to have your advices here: #XMPP looks best as it’s a protocol but I couldn’t understand well how to explain and onboard someone who’s not a super user on it. I’m a big fan of #Wire for their design which is perfect for anyone, also client and server are open but not federated. Thing is, all of these feature seem to be already in XMPP ? So is there a cool app which allows anyone enjoy XMPP benefits?

@imacrea have you tried delta.chat? It's cross-platform and uses normal email accounts as the back-end for a chat UI.

@strypey Thanks for these first tips. I have tested Movim but really couldn’t we’ll understand how it all works, even though after discussing about it with its creator. It add a certain level of abstraction which I find make its quiet complex ultimately. What I’m looking for is a solution that I can suggest to people as a great messenger alternative which is not going to be fade out against in 6 months. Something robust enough and safe. Which is why I’m thinking about XMPP

@strypey Thanks for Conversations, it looks pretty amazing. Any server you recommend?

@imacrea if you can afford it, paying for an account on the conversations.im server is a good way to support the work on the app. Otherwise, Disroot.org, Riseup.net, and many other community-hosting groups offer #XMPP accounts. I believe the #Librem.one paid service does too.

@strypey Thanks for your precious tips on that. I'll check them out. Regarding domain name, I understand it's great to have a custom domain as I can change then my provider without havin interuption with friends. but.. does it open an eventual security breach to do that? considering domain names are centralized by ICANN. I might mix up different concepts here as I don't understand fully all that. which is why I'm asking :) (cc @bortzmeyer ?)

@imacrea @strypey Sorry to correct but #DNS is not centralized (you can created mastodon.example or something.mastodon.example without authorization or even informaiton of a "center").

@imacrea @strypey If you have reservations with #ICANN, you can stay away from ICANN-regulated TLD. There are many more, with very different policies. eff.org/fr/node/96673 (I observe that most Mastodon instances seem to ignore this survey and instead choose a TLD just because it "looks cool".)

@imacrea @strypey Regarding the "security breach", I assume that you refer to the risk of losing your domain? It may happen, both from your own mistake (forgetting to pay for the TLD that require it) or from a 3rd party (governement, for instance).

But the same risk exists for the services like ProtonMail or RiseUp. (Although one may say they do better diligence in domain name management than Mr Smith; the choice is not obvious).

@imacrea @strypey I also suggest to do some assessment of the actual risk. True, if Trump is pissed off by mastodon.social, he has, at least in theory, the power to delete the entire TLD .social. But the actual risk seems low.

(The US governement also has the power to destroy human life by sending all its nuclear bombs. Technically, it is possible. In practice, although it's annoying, it is not the biggest issue today.)

@bortzmeyer @strypey Thank you very much for all these details Stéphane! I’ll look into this eff link.

@bortzmeyer @strypey BTW the way, in the end would you recommend XMPP (with conversation for ex) or Matrix ? I'm not sure to understand the difference but Matrix is quiet hard to use I find for any folks.

@imacrea @strypey For the end user, it is not really important, both protocols are open standards. It probably depends on your friends...

@bortzmeyer @imacrea
in theory, either protocol can be used for any kind of chat. But while the #Riot client is great for team chat, I haven't seen a #Matrix client with an instant messenger UI I would recommend for friends and family use. #Jabber (#XMPP) is the opposite. Apps like #Conversations (Android) and #Pidgin (desktop) are fine for one-to-one IM but I have yet to see a Jabber client that does group chat as well as Riot. This piece explains the differences well:

I'd really like to see a group of #Jabber champions take the #Riot source code and modify it to connect to servers using #XMPP, #MUC, and #OMEMO, instead of the #Matrix protocol. This would conclusively prove their constant claims that their preferred protocols can do everything Matrix can do. I would be curious to know what proportion of existing Jabber servers such a modified client could connect to without losing any functionality.
@bortzmeyer @imacrea

@strypey it would be better to go for a Electron #ConverseJS version but I agree with @debacle here

you could just use a seperate browser or designated Firefox profile for Webchat, basically the same but even without #Electron

@Muto @strypey @debacle

has some unique characteristics which no other chat app which I'm aware of has.

It has view modes, so you can have separate chat boxes overlayed over an existing website, a fullscreen app or an embedded "widget".

It's pluggable and you can remove core plugins to shape it into the form you need. E.g. you can remove groupchats entirely, or the roster view or OMEMO etc.

Almost anything is changeable or overridable and it has lots of configuration settings.

@Muto @strypey @debacle

It's not meant just as a standalone chat app... it's built to be as versatile, customizable and configurable as possible.

In a way, it's a lot like XMPP. Everybody laments the proliferation of XEPs and the lack of a unified experience.

I agree when seen from a certain perspective, this is a big drawback.

But the advantage of this approach is that you can use XMPP as a framework within which you can build unlimited functionality.

@jcbrand flexibility is great, but what it means in practice is that while all sorts of things can be built with #XMPP core and different #XEP
combinations, those things don't automatically exist. They have to be defined as meta-standards, sets of XEPs that are compulsory to properly serve Use Case X (eg personal IM, team chat, social media).
@Muto @debacle

@jcbrand #Jabber might get more uptake if every team focused on a serving a particular use case well, as #fediverse apps have been doing more recently (eg #Mastodon for micro-blog, #PeerTube for video, #PixelFed for images). Rather than a confusing foam of mostly identical, outdated IM interfaces, most of which get developed for a few years and then die. There are great apps with solid development teams, like #Conversations and #Conversejs, but these seem to be the exception.
@Muto @debacle

@strypey @Muto @debacle

> might get more uptake if every team focused on a serving a particular use case well

"Uptake", while desired, is less important to me than being able to earn a living off my work on Converse. Being able to do that makes this project sustainable and viable long-term.

Slack is a 16 Billion dollar company, the only way I can "compete" is to do what they cannot do, which is to make the project as open, customizable and configurable as possible.

It's a true dilemma indeed. If a company tries to compete with Slack, their primary concern is to be as reactive to user demand as Slack is, because that's what Slack users expect. So there is little incentive for them to adopt open standards that might slow their development process down.
@strypey @Muto @debacle

@stevenroose unless your project is an itch-scratching hobby and you don't care if you're the only person that uses it, being responsive to user feedback ought to be standard practice. So my questions here would be; why would implementing an #OpenStandard make a developer's that harder, instead of easier, and what can be done to reverse that? Off-the-shelf federation libraries in a range of languages? Community forums where implementers can support each other?
@jcbrand @Muto @debacle

@strypey @stevenroose @Muto @debacle

> why would implementing an make a developer's that harder?

In some ways it's easier, in others harder. It's easier because difficult problems (like federation) have been solved.

It's harder because you can make fewer time- and complexity-saving assumptions.

For example, if your eco-system supports only one chat client or one server, then you don't have to deal with feature discovery at all. That's a lot of complexity avoided.


@strypey @stevenroose @Muto @debacle

I've noticed something similar with open source code in general.

When writing FOSS, you often have to write more generic code and take more edge-cases into consideration than when writing closed-source code where you can make all kinds of time-saving assumptions on how the code will be used or executed.

Writing more abstract or generic code is often harder, but if done well it results in much better code quality IMO.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!