Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Group chats work pretty well in my experience. The spec for MUC is rather large even though only a small portion of it is used in practice (the roles/ACL capabilities go way beyond that of other protocols, probably inheriting the requirements of large-scale government/corporate deployments). There were also some challenges early-on relating to mobile use-cases (e.g. how to notify/respond to a user who's not joined to the group chat because their client is offline), and XMPP has grown a set of extensions in that area (push notifications, stream resumption, …).

> Other issue with XMPP is how hard it is to find clients that don't suck

OK, but the alternative we are talking about here consists of developing the server, protocol and clients all at once and from scratch, and end-up with something that's merely a prototype heading into a decade worth of enhancement and scalability improvements, iteratively bumping into the exact same kind of problems. Wouldn't it be less effort to just make an XMPP client that doesn't suck and lead by example? (That's pretty much what the "Conversations" Android client did when it came out, and now it's used by the German government, among others).

> I think I've seen at least 3 different ways clients implemented emojis, for example

I'm not aware of anything like that. There are different ways to do certain things, like sending attachments (HTTP upload or client-to-client), but that's the good thing about XMPP: your client/server negotiate capabilities and sometimes even translate among them.

I won't pretend that everything is rosy, for sure, but it also isn't that bad.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: