4 ms·
> There is no easy way to tell if your server supports them, either. False. XMPP has excellent feature negotiation capabilities. > everyone using Conversation
by Zash 10y ago
> There is no easy way to tell if your server supports them, either.
False. XMPP has excellent feature negotiation capabilities.
> everyone using Conversations essentially has to use a server that is maintained by the developers
No, you just need to use a server maintained by someone who actually maintains it.
> Otherwise, most of the XMPP featureset they offer simply doesn't work.
Feature negotiation and graceful fallback, is it really that hard?
> I think there needs to be incentive built into the protocol for all servers to maintain a baseline of XEP parity
Incentives, yes. In the (core) protocol? No. I think publishing a new "XMPP Compliance Suite $year" XEP is better than throwing the entire thing out, in a couple of years when everyone suddenly wants a different feature set.
> At least Matrix can provide a clean slate.
A clean slate which will be obsolete in just a few years, and will have to be invented from scratch all over again.
- mynameislegion 10y agoI think you missed the thrust of my argument which is that XMPP sucks from a _user_ perspective. A non-technical user perspective which is 90% of the users in the real world. > False. XMPP has excellent feature negotiation capabilities. User don't care what the protocol can do. "How come persistent group chat isn't working? Ah, I'll just use WhatsApp" > Feature negotiation and graceful fallback, is it really that hard? This is dependent on the client. Does your client support that? Who knows? Users don't care about any of this. > Incentives, yes. In the (core) protocol? No. There's no greater incentive for public server providers than the danger of having their user base get isolated from the rest of the network. That can be done through the protocol and is the only incentive that will actually _accomplish_ anything.
- Arathorn 10y agoI'd be surprised if Matrix is obsolete in a few years. The difference between the Matrix and XMPP spec structure is simply that Matrix is a single curated monolithic spec rather than a set of XEPs. So there's only one true standard at any given point, at a given version (unless someone forks it). We've been evolving it quite rapidly so far, adding modules for the various different use cases out there (http://matrix.org/docs/spec/client_server/r0.1.0.html#feature-profiles http://matrix.org/docs/spec/client_server/r0.1.0.html#featur...), and I don't see that rate of evolution slowing down any time soon. And even if we did go and entirely rearchitect Matrix (e.g. making it entirely P2P, which is certainly a thought experiment we keep in mind), one would just go bridge it into the existing Matrix ecosystem and migrate as desired.
- emias 10y ago> We've been evolving it quite rapidly so far, adding modules for the various different use cases out there [...], and I don't see that rate of evolution slowing down any time soon. > And even if we did go and entirely rearchitect Matrix (e.g. making it entirely P2P, which is certainly a thought experiment we keep in mind), one would just go bridge it into the existing Matrix ecosystem and migrate as desired. Are you saying you might end up in a situation where "fragmentation of features between clients and servers is common"?