3 ms·
That exists. Here are the 2018 profiles (they are split into basic/advanced): https://xmpp.org/extensions/xep-0387.html https://xmpp.org/extensions/xep-0387.htm
by MattJ100 8y ago
That exists. Here are the 2018 profiles (they are split into basic/advanced): https://xmpp.org/extensions/xep-0387.html https://xmpp.org/extensions/xep-0387.html
They are only part of the solution however because:
- Open-source projects are developed by volunteers, and implement what their users (actually typically their developers) want implemented. Having a document that says "you should implement these things" is good for guidance, but it doesn't magically get them implemented.
- Commercial projects will implement the things that they can get revenue from. Having a document that says "you should implement these things" doesn't magically make those things earn the company money.
E.g. in the open-source category, Pidgin is the classic example of a once-popular client that has fallen behind (with feature requests for some "new" protocol features open on their bug tracker for many many years). The document doesn't fix this part.
But yes, I do agree it's an essential part of solving the problem.
- dnel 8y agoIt's still so common to see clients tout a list of supported XEPs like they expect users to know what any of it means. It's great there is a list of importantant XEPs but this must be communicated to users better so that it's easier to find suitable clients. It might even be good to refer to compliant clients as something other than Jabber/XMPP then you can easily search for an "XTalk" (for example) client and know this means the full list of XEPs are supported. Part of this might include some new XEPs to indicate to users when they are communicating with non-XTalk users so the experience might differ. A certification programme even might help motivate devs to meet compliance quickly. One can dream anyway.