3 ms·

Honestly neither websockets over HTTP nor the underlying protocols used by XMPP are particularly good. They should be designed more like IMAP; at CMU during the

Honestly neither websockets over HTTP nor the underlying protocols used by XMPP are particularly good. They should be designed more like IMAP; at CMU during the first significant IETF instant messaging effort, Rob Earhart distilled the lessons of IMAP into an “Access Protocol” Internet draft that makes for a better substrate for pretty much any Internet protocol: https://datatracker.ietf.org/doc/draft-earhart-ap-spec/ https://datatracker.ietf.org/doc/draft-earhart-ap-spec/ A lot of the reason the IETF process around IM was so lengthy and led to so much cruft and weirdness is that there were telco folks on the lists who insisted that only small UDP packets would ever get through telco networks and TCP was an absolute non-starter, and kept trying to center the discussion around their current data networks rather than even the planned 2G and 3G networks. Also, just like email, an instant message protocol should be connection-based (TCP), provide good response time for plain text messaging over a 9600bps or slower link, and only require a page or two of C code to parse without heavy use of the standard library.

chrismorgan 5y ago
In a vacuum, something like that Access Protocol may be good, but we’re not in a vacuum. The web has won, and basing things on top of web specs conveys significant advantages: the general tooling for HTTP/XML/JSON is much better than the tooling for any specific-purpose binary or text protocol that I know of, so you can get started building stuff much more quickly, with better understood and handled failure modes, and better tools for debugging when anything goes wrong; and the large fraction of the world’s software that runs inside a web browser can also take advantage of this without needing some kind of non-standard server proxy. Most of the time I would say these advantages significantly outweigh the disadvantages of inefficiency. There are reasons JMAP was designed to sit on top of HTTP and JSON. It makes life much easier.
octoberfranklin 5y ago
> only small UDP packets There's something to be said for that here, however. When was the last time you typed out a chat/IRC message longer than 512 bytes? That's the minimum MTU on the Internet; packets below that size can ignore fragmentation and the retransmission-amplification that comes with it. Here's a beautifully elegant chat protocol that uses only UDP: http://www.loper-os.org/?p=3992 http://www.loper-os.org/?p=3992 It also uses only symmetric crypto, for "that's a feature not a bug" reasons; among them: it forces its users to forge decentralized WoTs instead of relying on big centralized platforms to authenticate their own friends to them. > A lot of the reason the IETF process ... led to so much cruft and weirdness is that there were telco folks That has been a major problem for a long time now.

chrismorgan 5y ago

In a vacuum, something like that Access Protocol may be good, but we’re not in a vacuum. The web has won, and basing things on top of web specs conveys significant advantages: the general tooling for HTTP/XML/JSON is much better than the tooling for any specific-purpose binary or text protocol that I know of, so you can get started building stuff much more quickly, with better understood and handled failure modes, and better tools for debugging when anything goes wrong; and the large fraction of the world’s software that runs inside a web browser can also take advantage of this without needing some kind of non-standard server proxy. Most of the time I would say these advantages significantly outweigh the disadvantages of inefficiency. There are reasons JMAP was designed to sit on top of HTTP and JSON. It makes life much easier.

octoberfranklin 5y ago

> only small UDP packets There's something to be said for that here, however. When was the last time you typed out a chat/IRC message longer than 512 bytes? That's the minimum MTU on the Internet; packets below that size can ignore fragmentation and the retransmission-amplification that comes with it. Here's a beautifully elegant chat protocol that uses only UDP: http://www.loper-os.org/?p=3992 http://www.loper-os.org/?p=3992 It also uses only symmetric crypto, for "that's a feature not a bug" reasons; among them: it forces its users to forge decentralized WoTs instead of relying on big centralized platforms to authenticate their own friends to them. > A lot of the reason the IETF process ... led to so much cruft and weirdness is that there were telco folks That has been a major problem for a long time now.