It's sad that we don't have a very good self hosted chat solution.
Last time I checked around, XMPP didn't have a client that I could recommend to business clients that looked easy/simple to use, has no gotchas and looks native.
Currently I use Mattermost, which does basic things fine and things are stable but the formatting is just getting in the way making texts unnecessary big and bold when people never intend to (there is a per user setting to disable formatting but I can't tell everyone to turn it off), and reply and quoting interface is just wrong and I never use it, so most of the other people use another vendor service which is easy and does things in a saner way.
And video/voice is apparently not in their integrated goal and is thrown to some external paid service, so pretty much only simple text and file uploads.
I'm not looking for anything too special in my opinion but I find it there's no self hosted solution that has,
- Simple interface so I don't have to lecture people 10 minutes on how to use it.
- WYSIWYG formatting instead of automatically parsing symbols into bold texts etc
- File uploads
- Decent reply/quote feature
- Multiple people voice call
- Optionally multiple people video calls
- Native clients for desktop and clients and web Interface
I'm barely mentioning the features which people would generally expect out of chat apps.
Regarding the WYSIWYG, I always hear complaints, including myself that texts get weirdly formatted when they paste from somewhere else and it does more harm than good when symbols are automatically parsed, so the other option would apparently be WYSIWYG editor, which anyone will have no problem comprehending how to use.
You can't just expect everyone to read and learn formatting rules to type. I'm an engineer but I don't even want to remember some Mattermost formatting rules to avoid unintended transformations.
You're making very strong statements that aren't backed by empirical evidence.
All I can say is that I see that successful chat apps for 'normal people' seem to have converged on something that isn't WYSIWIG, and it's probably not an accident.
P.S. Asking users what they want probably isn't the best idea. See "Homer's car" for a humorous take on this issue.
> WYSIWYG formatting instead of automatically parsing symbols into bold texts etc
Assuming you know the minimum features non-technical users want/need in such a tool is going to exclude a lot of options that might otherwise be viable.
WYSIWYG is probably the canonical example of this: non-technical users DON'T need WYSIWYG.
Slack has been the (non-self-hosted) solution du jour for what you describe. My company use Slack and we have thousands of non-technical staff on it: complaints were rife when they recently introduced WYSIWYG and we continue to get requests for help in disabling it.
For the future, I think Riot is your best bet. Matrix may suffer the same fate of XMPP, but if it escapes that fate, it'll be because of Riot.
It doesn't tick all your boxes yet, but RiotX is a hopeful project in terms of native, and the integrations it supports make a lot of features easy to add in some usable capacity.
Matrix will likely never take off, sadly. I was hoping for an alternative for a while too, but not having a proper standards body to advocate for and push the standard probably means it's not displacing XMPP any time soon. Also the protocol just isn't great for chat; if you need a giant distributed graph database, great, but for chat it's just very heavy.
XSF contributed the XMPP spec to the IETF after ~10 years, Matrix is a younger protocol (2014) and perhaps it will do something similar in the future.
Given the adoption rates of Matrix, I think it is fair to conclude it is a good fit for chat. Though it is fair to call out that it works quite differently under the hood from many other chat protocols. The decentralised architecture adds a resilience not possible in a purely federated system.
In any case Matrix would not rule out working with the IETF in the future, but for now the Matrix.org Foundation manages the governance of the protocol.
Not sure, but I really don't believe Slack's numbers either. I have a Slack account that only occasionally gets used, so they probably count me. Whatever the real numbers might be, Teams is very heavily used. My university has Office 365 and Teams comes with it for free. No need to pay for Slack. No need to expect others to use a new tool and a new app and a new login when Teams is right there.
Completely due to bundling. My last employer was using Slack until MS basically told them they could have Teams for free as part of the O365 subscription.
Not surprised there. Plenty of companies already in bed with Microsoft. This allows them to maintain a "familiar" setup to everything else they have. Still feel like competitors can do better though. Microsoft Teams looks nice but people still have issues with it. I only used it long enough to not see those issues.
> This allows them to maintain a "familiar" setup to everything else they have.
What's important is that when you log into your email account, you're logging into Teams, Planner, etc. I recently started using Planner, as awful as it is (seriously, you can't even drag cards!) because I can't expect others to adopt a new tool.
(self-promoting here) We're building Xabber in exactly this direction. Currently, of your list wee lack multiple people voice/video calls, and also a native client for desktop.
Web version is rather mature already, with android / iOS clients coming to shape fast and will soon be released. We'll likely make an Electron-based desktop version, though of course it far from ideal
However, doing all this great stuff we had to replace many common XMPP extensions, like multi-user chat, which is utter garbage. The replacement works like ... well, Telegram groups, has nice fallback capabilities to legacy clients and is generally very well working.
Nice to know someone is working to create a sane solution.
Building for the web first and porting to Electron for desktop and webview for mobile is good as you can have identical interfaces for users to switch between and less bugs to chase for developers and I see no downside with that path.
I understand multi user calls/videos isn't simple as I still use Skype just for that for a group of people and it seems to do that part fine.
No, it's not MIX. I believe that MIX will never fly, because it requires support by a participant's server. So unless all server developers will implement it, XMPP users will not be able to use it. Also, it puts too big emphasis on compatibility with old MUC, which is beyond saving.
Our approach does not require anything from a participant's server, and it does not even require a specialized support by a participant client: a reasonable fallback is provided for legacy clients, even if a participant is connected using 2 clients, one of which does support the new standard, and another one does not. It was achieved by clever dancing around how message carbons work and allows to sync clients nicely.
Absolutely. What's holding us is language barrier of some of our team. Docs are currently in Russian, and they are getting translated slower than I'd love them to.
Someone recently pointed me at DeltaChat [1]. 'Chat' over SMTP/IMAP. Apart from voice/video, it ticks all of the above (plus other features such as threading and e2e security), with the fallback of being able to use a regular email client in an emergency
Does this have a standards body behind it advocating for and developing a spec that anyone can implement? I'd argue that this is a requirement for any communication system to take off and be useful and sustainable long term.
Dino is slim and has some decent features, but Gajim is the client you want to be using today. Gajim has (although mostly broken) Voice and Video support as well as (working) plugin support and various plugins that you may expect.
Dino really fell short for me in my needs for XMPP client, though I'm happy to see federated systems and their clients being promoted.
Specifically Dino has issues with OMEMO support with Conversations, while Gajim does not see these issues. This means I can use Gajim on my computer and Conversations on my phone without issues.
We fixed some issues with OMEMO in the last months, so if your experience is a little bit older, those might be fixed already. If not, please report.
Dino has a very limited plugin system, extending it is planned for future releases. We are also interested in adding support for A/V calling and we already have some pieces of code for it, though nothing in a quality for actual usage.
As you said: Gajim does lots and lots of things, some of it only half-works. Gajim might be good for some people, but confusing for others. I probably wouldn't recommend it to my mom.
Dino has a good feature set and the user interface feels nice. It doesn't do everything, but that can also be a positive thing.
Dino's OMEMO works fine for me.
Gajim's an unstable mess that half of the time is not even connected to the server because it did not manage to reconnect after resume, or it just crashes.
It is fairly useless on dark theme, rendering grey on grey for the backlog.
Apart from a missing status notifier / appindicator, gajim is miles ahead.
What issues did you have? I used Dino and Conversations for six months or so a year ago, and enjoyed the experience. Our conversations were all OMEMO encrypted.
While I've been a believer of XMPP and still believes it has a place, I have to admit that it doesn't have the appeal it once has. Now the IM protocol du jour is Matrix, which might or might not know the same fate; who knows. And another one might come later, and there are already others today that exist and are widely used.
I think it's high time we had a concerted effort to have one great UI (probably per platform), and allow all protocol enthusiasts implement the specifics of their own choosing. It's fair to say that at this point the requirements for a "modern" UI are known, and while not all protocols may be up to the task, a very high percentage can be implemented in the most famous ones.
I feel like the focus of XMPP puts the effort in the wrong place. FreeNode IRC is still used because community effort to maintain the channels. Similarly, subreddits live or die by community moderation.
An effort that simplifies channel maintenance, like how easy it is to open a new Subreddit (the #1 portal, a static website URL representing your community identity) is the most important step forward.
Once you establish a www identity for your community, then and only then can you discuss community chat.
For example, lobster.rs community meets on IRC FreeNode, a protocol established on their about page.
------
The reason Reddit, Facebook, and Discord are popular, is because of the easy web-based onboarding process for new users. There are also web guis which make it easy to start new communities.
Support the WWW first, and users will come (as long as the onboarding process is as easy as competitors)
XMPP was primarily about person-to-person communication, with group channels being a separate add-on.
Part of iMessage's popularity is the ability to have group conversations the same way as those person to person communications - to the point where SMS users may get excluded from conversations.
IRC is just a terrible architecture which is exposed in its protocol, but it will survive a long time because you fire it up to participate in a community, not just to talk to an individual person.
IMHO paid tools like Slack got adoption when we had pre-existing protocols and clients for decades prior because it works as a package community-as-a-service (imho, to the point of being a detriment to usability). We had the technology to solve the problem, but the packaging and focus made it a legitimate product.
IRC is for public channels (and supports direct messages). It’s far from perfect, but I wouldn’t call it terrible; it works very well for its original purpose (and has been for almost 3 decades now).
IRC has a number of easily abused aspects of the protocol, such as giving away the recipient's direct address which may give away a great deal about their physical location. Just like XMPP it makes the mistake of tying the user's presence directly to their TCP connection, meaning a connectivity issue (such as another user flooding their IP) results in them being unable to use the system. Outside of privileged bots on open-source oriented networks, there are typically no accounts or registrations for names, so network attacks are fairly common in an attempt to regain a channel or nickname.
Servers in a network generally have little to no proper recovery from partitions/splits, and a split may result in changes in moderator/administrative users due to the lack of persistent permissions. There is no attempt to recover discussions during a split, or to apply consistent ordering to communication. Splits, which should be transparent, become a highly impactful event to the users within a channel.
Due to the lack of packetized responses and the simplistic method of determining an active TCP connection, it is possible to (for instance) be disconnected because of asking for a list of channels on a slow connection.
It has a _lot_ of problems, and most of the ones I listed are at the network protocol layer. It is still usable for environments where there are very active administrators and few to no bad actors, but it falls apart quickly on the public internet.
Group chats in XMPP (aka XEP-0045) is a pile of garbage, ill-conceived attempt to clone IRC to XMPP. It just can't properly work on mobile devices without a set of very ugly hacks to support it from breaking all the time. It should be just thrown away and replaced with a better solution (that's what we intend to do rather soon).
Probably any single protocol could be used to build a client that Slack or WhatsApp or [insert your target here] users would appreciate with good designers, (and/or with really little to no education.)
Multi-protocol clients are generally not optimal. The set of features that can be used will be the lowest common denominator, and if it's not the case there will be discrepancies in the design.
(Same story for bridges.)
Every protocol has their set of trade-offs, and every developer has their opinion on what's best (or the least worst). Also not every developer work with designers or have designing skills(!)
It's good for developers to be able to write what they want and how they want it. It's fine if their intended target is already with their circle of friends on the platform (if their is a target at all). It's less practical if the target is outside and their circle is not on the platform (network effect/peer pressure etc.).
That's a general "issue" in Free Software, (I'd say in software, maybe anywhere? it's just more visible here.)
Some might say waste of resources, but who gets to decide what to do with others' free time.. no easy answers.
(Sorry to spoil the fun by trying to rationalize :p)
I for one value freedom, through decentralisation (or federation as some like to insist on), and as technicalities I believe standard and extensibility of said standard are necessary. XMPP seems to fit this role ok enough to me.
Of course I'm not saying that people should stop working on what they want, they are free to spend their time however they want. I'm looking at it the other way: what if I want to create a protocol but can't be bothered to work on the UI, because I'm no designer ?
I'm not even talking about multi protocol clients because, as you said, it tends to level downwards rather than upwards. But if I could "fork" the UI and slap my protocol on it, instead of having to build it from scratch, I'd save a lot of time.
While it's worrying that Matrix uses the layer 7 HTTP (does it make it "layer 8"?) compared to XMPP's potentially more efficient use of layer 4 TCP, it's still better than the closed alternatives...
(And JSON > XML !)
It is actually a good idea to use https rather than your own protocol because then your network provider/government will not be able to (easily) find out that you aren't just making https requests using your browser. Useful for people living in oppressive governments as well as employees/students under restrictive firewalls. In addition to that this will get more efficient once we have http over quic.
Quic seems to be the UDP equivalent to TCPcrypt? Both of which should be used by default on the Internet?
But why should in your examples "the authorities" care or not whether you are using a browser over HTTP(S) or any other kind of software/protocol? If any communication channel is available, it's possible to send any kind of VPN traffic through it. Bits are bits. Especially when encrypted, so the censor has no idea as to what is inside...
Bear in mind that when students and employees are on their school/work network, they often have to accept the network admin's certificate authority in order to be allowed to connect to the network. So effectively, the network admin can spoof SSL certificates and MITM traffic, even if it's encrypted.
If that's part of the threat model, a layer 7 protocol can encrypt and sign the payload. Then anybody terminating the connection wouldn't be able to read and modify messages.
There are also replay attacks and probably many other issues I can't think about. Maybe some IM protocol already deals with that.
I'm no fan of XML and think its use is one of XMPPs biggest flaws, but I wouldn't pick JSON over it… with XML at least you get a lot of the stateful encoding and namespacing (eg. extensions) right in your XML library of choice, with JSON you have to reinvent all of that which is more code, more spec, etc. I'm not really sure if there is a good alternative to XML, sadly :(
No, YAML is just terrible in general :) (ahem, unhelpful strong opinion aside: YAML is way too complicated. If you think XML is over engineered, you really want to stay away from YAML)
Looks like a nice project, but why wouldn't one use http://pidgin.im, which also supports XMPP and as far as I know is pretty solid, works well, and is also cross-platform?
Last time I checked, Pidgin lacked proper support for multi device by not supporting Message Carbons (XEP-0280, required to receive messages on multiple devices when both are online at the same time) and Message Archive Management (XEP-0313, required to catch up with messages received while only another device was online).
There is probably also other examples of XMPP features that Pidgin does not and likely will never support, due to its nature of being multi-protocol (basically limiting features to the smallest common feature set).
If you are interested in Pidgin, the lead developer has a Twitch stream (rw_grim). He is always open to ideas, and onboarding new contributors. There is a new version of Pidgin being written that significantly improves the user, and developer, experience. If you check out the stream, you could get some swag too (I have some Pidgin stickers). That said, I am also interested in Dino, and supporting other projects. It's unfortunate that chat has become more proprietary, instead of more open.
As I understand it, Pidgin's XMPP feature hasn't been maintained for some time now. It doesn't do many core features well or at all. If you like it and it suits you, great :)
Pidgin can be very hit-and-miss with which parts of the protocol it implements. It is also a multi protocol client so a lot of the functionality is presented in a protocol agnostic way, which may not be what you're looking for if you're using it for XMPP alone.
For a desktop XMPP client, check out Gajim. It's stable and implements all that a user would expect (server side history, omemo).
I had the same question. This seemed to be their answer:
> A number of clients already exist for the XMPP protocol, however Dino sets a different focus. Existing clients target tech-savvy power users. The XMPP ecosystem lacks a client that is enjoyable to use while providing the features people expect from a modern chat application.
I'm sure one needs to be more tech-savvy to use Dino than to use Pidgin :), but I understand they were likely not thinking about Pidgin, but it does exist.
I'm not super familiar with the details, but I think Pidgin has little/no support for encryption (OMEMO & OpenPGP). This probably has support for other XMPP features that Pidgin doesn't as well.
What I don't know is how this is different than gajim.
Pidgin intentionally stores them in plain text. The logic, I believe, is that "light encryption" is worse than no encryption since it gives a false sense of security.
So rather than a reversible cypher they leave it plain so that their users will freak out and /not/ share their files with folk and will properly lock down their creds file.
Every recent graphical OS has support for key management though, whether it is the key store on mac, the credential store on Windows or the key management tools that come with KDE or Gnome (I believe both share somewhat of an API).
It might be due to Pidgin's age but in modern programs storing this data in plain text should be a last resort for systems that don't do secret management for you.
The enormous selection of Pidgin plugins (e.g. Discord, Office365, IRC, etc) also makes it really hard for me to give it up for a prettier program like Dino. I hope Dino supports at least OTR encryption.
That sounds unlikely. Now that OMEMO is the hotness the interest in OTR has dropped pretty much to zero in the XMPP world. The Conversations client used to support OTR but that support has been discontinued.
I'm using Dino daily and it works well and looks modern. It still has minor issues here and there but it's finally a desktop client I can recommend to my non-technical friends.
I'm not a linux hater, but as long as it's in linux-land, there won't be much mass adoption. Not necessarily a bad thing, but might as well named it YAXC and tossed it into the list[0] (oh turns out Dino is on the list and there's already something called YAXIM)
What's the point in this comment? What good do you possibly think could have came from saying that? Not only are you pointing out something that they have already considered, you're pointing it out in an arrogant way, right after they say that they had already considered it and wanted something that would render your comment void, and on top of that, you end it with insulting the project.
I'm genuinely fascinated: what was your mindset when posting this?
I'm actually more interested in an explication for the mindset behind this comment's condescending tone.
It's a fair enough comment to make — the notion that mass adoption comes by catering to the masses is not one that should be so readily dismissed with a downvote and aggressive italicisation.
In a discussion of an XMPP client that's specifically designed for mass appeal, in this modern world of iMessage, Facebook Messenger, WhatsApp, Slack, and Discord, it's a perfectly reasonable point to bring up.
Glad there's a modern alternative to big tech's walled chat gardens. It's tragic that this protocol has so much potential but the "last mile" of getting it out to users has prevented success since FB and Google ditched it.
Is this a client or is Dino also running a chat server/issuing accounts etc? I used to use pidgin/adium/finch back when google & facebook supported XMPP, but I'm not sure what I'd do with a client now.
Crucially: If I have Dino, can I chat with any of my friends? Or do I need to persuade them to install Dino & create an account somewhere first?
Dino is a xmpp client, so no server. You have to create an account on a xmpp server to use it, which you can do on a public server or you can install your own server otherwise.
Your friends needs a xmpp account somewhere (not required to be on the same domain) and can use any xmpp client to chat with you.
There’s a good many public XMPP servers, or you could run one for yourself and your friends (I recommend Prosody, it works pretty much out of the box for that use case). If they have any XMPP client on any server, you can talk to them.
I tried Dino for a bit but returned to gajim straight away. Apparently Dino auto-accepts all omemo keys by default and while there is a way to globally disable it all of your current contacts will keep it on by default and I really did not feel like going through every single contact that I have and disabling it (as well as the keys that it accepted in the way).
Slightly off topic but I've never had success with self hosted prosody and the "conversations" app being able to share photos/memes as one would in WhatsApp or telegram. This is the one thing keeping me from being able to sell my non-tech friends on it, has anyone had any luck in this regard?
Does this finally get away from the problem that XMPP had in the old days, where the usage model was tightly bound to the domain model, so each domain would have one and only one XMPP server (plus possibly a fallback) and if you aren't the domain administrator then you can pound sand?
It was pretty much impossible to run your own server for fun unless you registered a domain or two because of the serious business logic baked into the design of the protocol.
Ages ago when I was working on a replacement for IRC for an organization that needed to decentralize its servers because they had a lot of users spread across the world behind iffy internet uplinks but all on the same domain this was a huge headache. The old IRC system worked really well for them, but some of the higher ups were upset because it wasn't "enterprise quality" and thus shouldn't be on their network.
That sounds like a server design problem, not a client problem. XMPP is stateful, so it is harder to have a distributed server but it's also doing something more complicated than eg. serving a document like HTTP. If you use a server like ejabberd and a proxy layer you can easily do geographic distribution of the server, or at least, with no more difficulty than any other protocol.
It bled over into clients too. You would tell your client to connect to "google.com" and it was hardcoded to connect to "xmpp.google.com", with no option to choose a different server.
If you had multiple domains that you wanted to connect the servers would also default to xmpp.other.domain.
If you wanted to connect to test.my.domain to test2.my.domain you were SOL. In a lab environment you could hack it with local DNS fuckery, but to actually deploy it would have been a nightmare. The whole thing assumed the entire domain would be served by one single server and all clients would always have good connectivity.
Their old IRC model was just to have a local server at each site with a cache. When the network went down (which it did frequently), the local users would still have connectivity, and when the link came back up they would get the backscroll. Replicating this sort of config with XMPP turned out to be very difficult, and eventually the bosses relented and let them keep IRC, or at least they passed the problem off to someone else after I left.
> You would tell your client to connect to "google.com" and it was hardcoded to connect to "xmpp.google.com", with no option to choose a different server.
>If you had multiple domains that you wanted to connect the servers would also default to xmpp.other.domain.
This seems strange. XMPP has SRV records specified for discovery of the client endpoint, so the "correct" thing for a client to do would be to look up the xmpp-client SRV record for your domain and attempt to connect to that. It's possible that some clients had a fallback to prepend "xmpp" to the domain, but I'm not aware that that's ever been standard practice - more commonly they'll fall back to an A record lookup on the domain part of the account.
>The whole thing assumed the entire domain would be served by one single server
Basically, the assumption is that you have your SRV records set up properly. Modern XMPP clients, like Dino, will then reconnect automatically to a server that they can access, and read history to find anything they missed. Horizontally scaling XMPP servers exist, it's probably up to you to find one that works well in a multi-site configuration though.
Your other option is just to give everyone their own XMPP address on a subdomain for each site - foo@dublin.example.com, bar@brussels.example.com, etc. I do this with a number of independent XMPP servers and it works fine. Then you're just depending on ordinary XMPP s2s to communicate between them, which is obviously well-supported.
DNS SRV is just the easiest (IMO) and most widely supported method, so I generally recommend just doing that since you probably have DNS anyways, even if you don't necessarily have an HTTP server running on your chat machine.
Yah, if you're using this for enterprise though you probably have to jump through all the hoops either way. Eg. to provision and install a client (be it some general XMPP client, slack, hipchat server, whatever) on your dev machines, to provision machines for a server and get that setup or to contract it out to someone, and yes, finally, to setup DNS records. So I don't think it's a big deal that DNS records are required for enterprise, they're going to have to keep a papertrail and do all the extra overhead anyways. :)
It hasn't been this way for a while (since the early 2000s, I think), most things lookup DNS SRV records now, and before that most things provided a field to enter a different server address.
That was not the case since at least 15 years ago; that's when I setup a couple of jabber servers on subdomains. None of them had xmpp in their DNS name.
Matrix works well as a big distributed graph protocol, not so much for chat. XMPP works well for chat or anything where you need efficient near-realtime streams (eg. stock trading and tickers sometimes use XMPP, some accessibility caption systems, etc.). Also XMPP is better standardized (by virtue of having a long-term non-profit standards body, Matrix is sort of trying to do that, but also trying to figure out how to monetize it which is never a good recipe for long term success when your spec becomes part of your product).
However, the protocol itself is governed by the Matrix.org Foundation acting as a neutral guardian (https://matrix.org/foundation/), so it unclear how the spec itself would become part of the product.
To suggest that Matrix itself is not well suited to chat is to ignore the rapid adoption of the protocol now used by millions of people.
It really doesn't have massive adoption; it looks big because we're in a little bubble of people who play with new tech on HN, I suspect, but overall other protocols like XMPP are used by a vast number more companies and daily users.
The matrix foundation has had trouble trying to fundraise to pay developers, it's not a proper non-profit standards foundation, in my opinion. I'd be skeptical of trusting them.
I was replying to your previous comment that Matrix as a protocol is not suited to chat by pointing to the millions of people who use the service as a means to refute the point.
The Matrix.org Foundation is a non-profit UK Community Interest Company. As you might expect, it accepts donations which can be used to fund work on the project. It reports publicly on its financial status in the same was as any other UK CIC is obliged to. This doesn't seem very controversial to me.
Man, I need an XMPP client that does what slack does: group chats with the chat topics organized on the left side along with message history and status notifications.
Perhaps not the answer you are looking for, but if you can bridge XMPP groups to IRC (for example with Biboumi) then The Lounge (thelounge.chat) is a great Slack-like IRC client.
No. OTR was not considered due to its lack of multi device support. OTRv4 now supports multi device, so it could be an additional option once it becomes standardized for XMPP. We are also monitoring development around MLS.
We are aiming for support for the Librem 5 and other smartphones that use a more GNU/Linux-ish environment. For Android there is conversations.im with a similar feature set.
Congrats on release, but the title is incorrect, word 'decentralized' should be removed.
XMPP, like email, is not a 'decentralized' protocol, but a federated one. If you and your chat partners use the same server, it would be as centralized as WhatsApp or Signal.
Baran drew this pic almost 80 years ago. Since then, 'Decentralized' has become an umbrella term for both decentralized and distributed networks, and 'Federated' is currently a commonly accepted name for Email/XMPP type of networks. [1]
This makes sense, because Baran was describing a communication network, like later ethernet, where nodes were interchangeable, wherever in XMPP the nodes are not interchangeable: if you have an account on xmpp.org server, you can't connect to xmpp.jp server and receive your messages. Thus, such networks required a special more narrow name to define it.
> Congrats on release, but the title is incorrect, word 'decentralized' should be removed.
It is decentralized in theory (no one server controls the network), but 'federated' is the correct word to use here.
When I saw the title I was assuming this was some cool new sort of client that created and managed a bunch of logins/identities as one on various XMPP servers and used something like OMEMO for key management on top of that 'layer'.
Tox is a better example of a 'decentralized' protocol.
What is the purpose of this? It seems more like a pet project than a serious release considering there's no roadmap.
What is your motivation? Surely you're aware of the abundant amount of XMPP client applications that have existed for the better part of the last 20 years?
There is a section on motivation in the blog post (it literally has "Motivation" in the title):
> A number of clients already exist for the XMPP protocol, however Dino sets a different focus. Existing clients target tech-savvy power users. The XMPP ecosystem lacks a client that is enjoyable to use while providing the features people expect from a modern chat application. Dino fills that gap by aiming to be secure and privacy-friendly while at the same time providing a great user experience.
http://pidgin.im seems to be pretty easy. Doesn't require any tech-savvyness other than entering your credentials in a nice, intuitive interface, unless I'm missing something?
Pidgin is a very bad XMPP client these days - at least until you have spent quite a lot of time on gathering and configuring all the plugins needed for modern XMPP experience.
Last time I checked around, XMPP didn't have a client that I could recommend to business clients that looked easy/simple to use, has no gotchas and looks native.
Currently I use Mattermost, which does basic things fine and things are stable but the formatting is just getting in the way making texts unnecessary big and bold when people never intend to (there is a per user setting to disable formatting but I can't tell everyone to turn it off), and reply and quoting interface is just wrong and I never use it, so most of the other people use another vendor service which is easy and does things in a saner way.
And video/voice is apparently not in their integrated goal and is thrown to some external paid service, so pretty much only simple text and file uploads.
I'm not looking for anything too special in my opinion but I find it there's no self hosted solution that has,
- Simple interface so I don't have to lecture people 10 minutes on how to use it.
- WYSIWYG formatting instead of automatically parsing symbols into bold texts etc
- File uploads
- Decent reply/quote feature
- Multiple people voice call
- Optionally multiple people video calls
- Native clients for desktop and clients and web Interface