Earlier quoted context omitted.
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…
Any chance we can see your XEP about this new group chat ?
Dino: An open-source application for XMPP messaging
151–153 of 153 posts
Re: Dino: An open-source application for XMPP messaging
#152Earlier quoted context omitted.
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. You can see numbers for the public network here ( https://matrix.org/faq/#what-is-the-current-project-status ), though these figures do not include installations that choose not to federate publicly. The Matrix.org Foundation is a non-profit…
Re: Dino: An open-source application for XMPP messaging
#153Earlier quoted context omitted.
I agree, somewhat. 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 be…
> IRC is just terrible architecture 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).
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.