41–50 of 153 posts
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? What advantages does this have over Pidgin?
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 C…
Earlier quoted context omitted.
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 DN…
>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
Certainly not. Clients will (or should, anyway) try connecting to servers based on their priority/weight in the SRV record: https://xmpp.org/rfcs/rfc6120.html#tcp-resolution-prefer
As GP mentioned, this does assume that you have servers capable of scaling horizontally, because XMPP is stateful. Not all can, but some do.
What's the goto XMPP service these days?
Earlier quoted context omitted.
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.
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? What advantages does this have over Pidgin?
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.
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? What advantages does this have over Pidgin?
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).
Used to communicate with a bunch of friends via AIM, then Google Talk (XMPP), then Yahoo IM... we gave up after the last one shutdown. What's the goto XMPP service these days?
EDIT: I might have misunderstood "service" thinking you wanted to self-host.
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? What advantages does this have over Pidgin?
Pidgin doesn't support OMEMO[0], which is sad. I've also had mixed results using MUC on pidgin/xmpp in the past.. 0. https://developer.pidgin.im/ticket/16801
Earlier quoted context omitted.
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.
The Pidgin OTR plugin worked really well over many years, but I haven't used it in a while: https://otr.cypherpunks.ca/
Although IIRC Pidgin also stored network credentials in plain-text file. Maybe that has been resolved in the past 10 years?