4 ms·

Let me just start by saying that I'm a big fan of XMPP. I run my own server, and talked to my friends exclusively through XMPP until that fateful day that Googl

Let me just start by saying that I'm a big fan of XMPP. I run my own server, and talked to my friends exclusively through XMPP until that fateful day that Google turned off federation support for Gmail chat, and I lost contact with a bunch of friends. I still run my own server, though I don't use it nearly as much as I used to. XMPP is a well-thought-out protocol, and a lot of the XEPs are great features. The problem I always had with XMPP is that XEP support is unequally distributed among clients, and the fragmentation really undermines the amount of cool features XMPP has to offer. As a (made-up) example, Psi+ might support video calls, but not server-side history, and Pidgin only supports server-side history, and Adium is the only one that supports Service Discovery...if I want both, I have to pick a client, and possibly have to use two clients signed in with different resources. As a possible solution, we could have a "logo program" for XMPP, where a core set of XEPs are required to call yourself an XMPP client (this is the case already IIRC), and you get rights to call yourself "supporting XMPP-Enhanced" if you support these other XEPs, and "supporting XMPP-Full" if you support all of these XEPs. Something like that might work, but you'd have to have a way to actually drive development toward these features.

SamWhited 8y ago
I'm going to be pedantic here, but I think it's important to be precise: this is a problem with the public/federated XMPP network (let's call the network "Jabber", since some people use the term that way), not with XMPP (which is a network protocol that could be used by any number of services). That is to say, XMPP==HTTP, Slack==google.com. XMPP could be used to build a service like Slack (with its own clients, specific feature set, etc.) that may or may not be federated and it would still have the benefits of using an open protocol (even if it's not federated I can use a more accessible client, a client on a platform they don't support, less work to get up and running because libraries exist, etc.) I'm hoping the Compliance Suites will become something like you mentioned in the future, but I'm no longer the author so we'll see what the new authors do with it: https://xmpp.org/extensions/xep-0387.html https://xmpp.org/extensions/xep-0387.html
arendtio 8y ago
I thought about this too. My idea was to introduce some sort of version badges, like 'This client supports feature set 2018'. Every 2 to 3 years there should be new definition of which XEPs a client should support in order to be allowed to be called 'Supports feature set xxxx'. That way you could very easily coordinate a common target for XEPs. Clients which would not support the newest features would still work with the others but users could simply see which clients support the state of the art features. And for developers it would make it easier to identify and skip old XEPs (e.g. how many XEPs are there to confirm a message has been received? Which is the recommended one for new implementations?).

SamWhited 8y ago

I'm going to be pedantic here, but I think it's important to be precise: this is a problem with the public/federated XMPP network (let's call the network "Jabber", since some people use the term that way), not with XMPP (which is a network protocol that could be used by any number of services). That is to say, XMPP==HTTP, Slack==google.com. XMPP could be used to build a service like Slack (with its own clients, specific feature set, etc.) that may or may not be federated and it would still have the benefits of using an open protocol (even if it's not federated I can use a more accessible client, a client on a platform they don't support, less work to get up and running because libraries exist, etc.) I'm hoping the Compliance Suites will become something like you mentioned in the future, but I'm no longer the author so we'll see what the new authors do with it: https://xmpp.org/extensions/xep-0387.html https://xmpp.org/extensions/xep-0387.html

arendtio 8y ago

I thought about this too. My idea was to introduce some sort of version badges, like 'This client supports feature set 2018'. Every 2 to 3 years there should be new definition of which XEPs a client should support in order to be allowed to be called 'Supports feature set xxxx'. That way you could very easily coordinate a common target for XEPs. Clients which would not support the newest features would still work with the others but users could simply see which clients support the state of the art features. And for developers it would make it easier to identify and skip old XEPs (e.g. how many XEPs are there to confirm a message has been received? Which is the recommended one for new implementations?).