4 ms·

I'm not sure it's fair to call it a massive blob of web technologies (although I'm biased, given I work on it). To compare sending a message on IRC versus send

I'm not sure it's fair to call it a massive blob of web technologies (although I'm biased, given I work on it). To compare sending a message on IRC versus sending one on Matrix: $ telnet irc.freenode.net 6667 ... NICK Ara4n USER Ara4n Ara4n irc.freenode.net :Matthew Hodgson ... JOIN #matrix PRIVMSG #matrix :test versus: curl "https://matrix.org/_matrix/client/r0/rooms/!cURbafjkfsMDVwdRDQ%3Amatrix.org/send/m.room.message/uuid?access_token=$access_token" -X PUT --data '{"msgtype":"m.text","body":"test"}' (okay, this assume you've grabbed a valid access_token from an existing session, and already know that #matrix:matrix.org's internal ID is !cURbafjkfsMDVwdRDQ:matrix.org, but that's easy to find by curling https://matrix.org/_matrix/client/r0/directory/room/%23matrix%3amatrix.org https://matrix.org/_matrix/client/r0/directory/room/%23matri...). Meanwhile definitely are some lightweight C matrix clients out there - e.g. https://github.com/matt-williams/matrix-esp8266/blob/master/matrix-esp8266.ino https://github.com/matt-williams/matrix-esp8266/blob/master/... is a proof of concept client in C that runs on an ESP8266(!), or the libpurple plugin: https://github.com/matrix-org/purple-matrix https://github.com/matrix-org/purple-matrix. In the end, if you don't like HTTP or web technologies, there is NOTHING stopping people from contributing alternative transports - COAP, MQTT, capnproto, QUIC, XMPP, WebSockets or whatever floats their boat. But it seems that the simple HTTP+JSON API works well enough that nobody has bothered yet (other than https://github.com/matrix-org/matrix-doc/blob/master/drafts/websockets.rst https://github.com/matrix-org/matrix-doc/blob/master/drafts/...).

Arathorn 10y ago
(that said, I think the point of Dave Cheney's article is more that sync realtime chat is bad for FOSS collaboration relative to mailing lists and forums. So until Matrix finally lands threading & forum semantics and smtp/nntp bridges, I suspect it's part of the problem he's complaining about :D)
- ptman 10y ago
  Threading I know is being worked on, but is SMTP/NNTP anything other than a jape?
  - Arathorn 10y ago
    SMTP/IMAP is very serious - we would love to bridge email convos into Matrix eventually. I suspect we're a little late to rescue NNTP though but perhaps someone will write a bridge for sentimental reasons :)
iffycan 10y ago
Call me crazy, but I think your example illustrates one reason why IRC is great: I can read it. And I could probably get it right even typing it from memory.
- Arathorn 10y ago
  Agreed that the IRC line protocol is superficially easier on the eyes, but it's far from intuitive (especially the weird USER command). Whereas remembering the URL shape for Matrix is... just another URL (plus you can always cheat and just 'copy as curl' from a browser's network inspector). But each to their own :D
- duskwuff 10y ago
  The IRC protocol is surprisingly difficult to implement correctly. I'm not an expert on the issues involved, but a few of the high points include: * No standard maximum message length. If you input a line which is more than 510 characters after being prefixed with the channel name, server name, and other metadata, it may be truncated for some clients. If you're on a network which includes multiple servers, some clients may actually see your message truncated in different locations, based on how long their local server's name is. * No standard text encoding. Some clients assume ISO8859-1, some assume UTF-8, and some will mix and match (ew). * No way to determine when certain commands have succeeded. In particular, commands which can generate multiple lines of output (like WHOIS) don't have a standardized termination. Command-line clients sidestep the issue by just showing all the output in one place; higher-level clients have to guess. * No standard identity services. NickServ is a common bolt-on, but it's a total hack. (It works by pretending it's another IRC server!) * Bold, colors, and emotes (/me) are all client-side hacks. * DCC file transfer is a complete and utter mess. It's like TFTP, but poorly implemented, over a TCP transport.
  - na85 10y ago
    Agree about DCC but lot of the other issues you list are due to curmudgeonly (IMHO) users insisting on using non-modern clients and networks. If they would tolerate a little breakage of backwards compatibility, the big networks could easily move to utf8 with standardized identity and colours, etc. Unfortunately there is a small but very vocal faction of IRC users that are highly entrenched and resistant to change.
andrewprock 10y ago
You lost me at: "cURbafjkfsMDVwdRDQ"

Arathorn 10y ago

(that said, I think the point of Dave Cheney's article is more that sync realtime chat is bad for FOSS collaboration relative to mailing lists and forums. So until Matrix finally lands threading & forum semantics and smtp/nntp bridges, I suspect it's part of the problem he's complaining about :D)

ptman 10y ago
Threading I know is being worked on, but is SMTP/NNTP anything other than a jape?
- Arathorn 10y ago
  SMTP/IMAP is very serious - we would love to bridge email convos into Matrix eventually. I suspect we're a little late to rescue NNTP though but perhaps someone will write a bridge for sentimental reasons :)

iffycan 10y ago

Call me crazy, but I think your example illustrates one reason why IRC is great: I can read it. And I could probably get it right even typing it from memory.

Arathorn 10y ago
Agreed that the IRC line protocol is superficially easier on the eyes, but it's far from intuitive (especially the weird USER command). Whereas remembering the URL shape for Matrix is... just another URL (plus you can always cheat and just 'copy as curl' from a browser's network inspector). But each to their own :D
duskwuff 10y ago
The IRC protocol is surprisingly difficult to implement correctly. I'm not an expert on the issues involved, but a few of the high points include: * No standard maximum message length. If you input a line which is more than 510 characters after being prefixed with the channel name, server name, and other metadata, it may be truncated for some clients. If you're on a network which includes multiple servers, some clients may actually see your message truncated in different locations, based on how long their local server's name is. * No standard text encoding. Some clients assume ISO8859-1, some assume UTF-8, and some will mix and match (ew). * No way to determine when certain commands have succeeded. In particular, commands which can generate multiple lines of output (like WHOIS) don't have a standardized termination. Command-line clients sidestep the issue by just showing all the output in one place; higher-level clients have to guess. * No standard identity services. NickServ is a common bolt-on, but it's a total hack. (It works by pretending it's another IRC server!) * Bold, colors, and emotes (/me) are all client-side hacks. * DCC file transfer is a complete and utter mess. It's like TFTP, but poorly implemented, over a TCP transport.
- na85 10y ago
  Agree about DCC but lot of the other issues you list are due to curmudgeonly (IMHO) users insisting on using non-modern clients and networks. If they would tolerate a little breakage of backwards compatibility, the big networks could easily move to utf8 with standardized identity and colours, etc. Unfortunately there is a small but very vocal faction of IRC users that are highly entrenched and resistant to change.

andrewprock 10y ago

You lost me at: "cURbafjkfsMDVwdRDQ"