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?
@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 If you have reservations with #ICANN, you can stay away from ICANN-regulated TLD. There are many more, with very different policies. https://www.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.)
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.
#conversejs 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.
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).
@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.
> #Jabber 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
> why would implementing an #OpenStandard 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.
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.
@jcbrand sure, like I said Converse is an example of how to do Jabber dev right. It does one thing (web-based personal IM) and does it well. A network of Converse instances on community-hosting groups running a Jabber server (eg #Disroot, #libremOne) would be sufficient to create a user-friendly federated IM network. Especially if the instances were configured to warn users before accepting connections from client/servers that can't fulfill the promises made by the Converse UI.
Next time someone wants to create a web-based Jabber client, they would be better to make something different, eg a #Riot-like team chat UI, and again, have it warn users when they're connecting to a client/server that can't fulfill all its UI promises. That way the flexibility of #XMPP actually serves an asset, not a liability (user confusion), and the existence of multiple clients serves a useful purpose, rather than just reinventing the wheel and then dying.