| > I mostly agree; I'd hope that we could get to a place where the requirement to "know" XMPP was roughly that of needing to "know" HTTP. So simple use cases could be done without truly understanding the guts. I'm afraid that will never happen, though, due to the way extensibility is built into XMPP. HTTP is only very superficially extensible - you can provide custom headers (which are really just formatted strings) and custom-encoded body data. Both can be rather challenging to understand, in some cases, but the core protocol is easy to abstract, and usually is all you need. For XML, that is much harder - without the right set of XEPs, XMPP isn't very useful for a real-world application. If only one single XEP is not implemented on your platform, you have to write your own, and immediately have to deal with the entirety of the XMPP/XML (protocol) design. You can't superficially string something together, like with a HTTP header. > I'll confess to not being your typical XMPP developer, but I was under the impression that successfully hitting the XML with libraries like Smack was actually quite hard. Things seem slightly more well-supported in Java-land, but in most other ecosystems, there are no implementations of XMPP that are both feature-complete and easy to use. A complex protocol invites developers who build complex abstractions, not easy ones. > OK, so Pidgin is a multi-protocol client which means the UI is abstracted out... But... https://developer.pidgin.im/ticket/15508 I don't understand their logic there, I have to say. I have no idea, but some of my contacts use other clients, and they haven't gotten it to work either. > For OTR, by the way, that just breaks with multi-device anyway. There's some experimental work with Axolotl underway which looks very promising. Depends. XMPP seems somewhat lacking in its notification of which resources are 'active' (in common implementations), which is something that would help to at least synchronize online devices (by sending differently encrypted messages to different resources). Log synchronization is trickier, but really should be possible as well. > I won't disagree there. The lack of a consensus on UX considerations (in fact, the lack of any attempt to get such a consensus) means that different clients present even simple things like jids differently. That's something the community (or the XSF) could seek to address. I am not just refering to end-user UX, though - also to developer UX. Complex protocols with complex libraries aren't developer-friendly, and the same issue occurs as above: complex abstractions invite developers who write complex end user products. It's very hard to get simple end user products built for complex protocols, because those require two fundamentally different types of developers. > That said, I'm aware that one key problem faced by a federated network is that client on-boarding can't, so easily, create your account for you, and early attempts to streamline that process have left serious abuse problems in their wake. I think the big mistake there was to leave the exact registration data undefined. Rather, there should have been a standardization of 'common registration fields' (including eg. CAPTCHA data), and later amendment XEPs if things like CAPTCHAs were to have to change. As it is, in-band registration is disabled almost everywhere, because no client can deal well with bot prevention measures. |