4 ms·

IRC originates from a time where nobody was thinking about multiple devices, or e.g. not encoding in ASCII. Speaking of nonstandard: There seems to be no canoni

by catdog 10y ago

IRC originates from a time where nobody was thinking about multiple devices, or e.g. not encoding in ASCII. Speaking of nonstandard: There seems to be no canonical specification of IRC itself. Nevertheless it's really not that bad in practice if you use a bouncer or something similar like Quassel. > There's no reason the platform has to be closed - I'm friends with the people working on http://matrix.org/ http://matrix.org/ (though not involved in it myself) and hope they succeed. There is also XMPP (and has been for years) which does not suffer from many of IRCs shortcomings.

lmm 10y ago
> not encoding in ASCII IIRC the original standard specifies a particular 8-bit character set (not ASCII), though the broader point stands. > There is also XMPP (and has been for years) which does not suffer from many of IRCs shortcomings. XMPP is useless for multiple devices: there's no way to receive messages on both (some servers will deliberately violate the spec here because the spec is stupid), and the federated history spec has been under development for about a decade now. Groupchats don't work properly with federation and have terrible UX in every client I've tried. Everyone assumes XMPP must be good because it's open-source (which is usually a pretty good heuristic) but I've come to the conclusion it's actually a really bad standard.
- catdog 10y ago
  > XMPP is useless for multiple devices: there's no way to receive messages on both (some servers will deliberately violate the spec here because the spec is stupid) XEP-0280: Message Carbons and there was that priority thing before. It somehow worked in the past and now it's definitely solved. > Groupchats don't work properly with federation The only annoying problem i can think of is when the server hosting the MUC restarts clients seemingly don't notice that they have to rejoin. > and have terrible UX in every client I've tried. Maybe you tried terrible clients? Unfortunately are few now which aren't terribly behind regarding protocol support. > and the federated history spec has been under development for about a decade now. I think thats the real problem. "Nobody" implements newer XEPs, especially if they are not finalized yet but how should they finalize if nobody puts them to trial? Everybody seems to have settled in screaming out what does not work so well but instead of helping to fix it they halfway reinvent the wheel or switch to centralized proprietary solutions which may have nicer looking clients but often don't even try to solve harder problems like multi client support. I didn't have a look at Matrix yet, maybe it's worth it but there is always the danger of creating yet another standard [1] (which may not even be as perfect as originally thought in the end either). > but I've come to the conclusion it's actually a really bad standard. But is it really that bad (especially at the basic fundaments) to justify something completely new? XMPP at least provides a lot of ability to evolve without breaking everything that was. [1] https://xkcd.com/927/ https://xkcd.com/927/
  - Arathorn 10y ago
    hopefully Matrix avoids falling into the cliché of xkcd 927 by focusing on defragmenting the existing silos - building a metanetwork between IRC, Slack, XMPP, etc etc. So rather than saying "hey everyone, throw away your current stuff", we say "hey everyone, build a bridge into Matrix - it's fun and easy (100 LOC for the slack bridge: https://github.com/matrix-org/matrix-appservice-bridge/blob/master/HOWTO.md)" https://github.com/matrix-org/matrix-appservice-bridge/blob/.... If you want to use Matrix natively via weechat or whatever then so much the better, but the intention is to be useful as way more than just another msging protocol. It's meant to more be a big open decentralised database for conversations and other realtime data - more in common with IPFS or even the Web itself. [disclaimer: I work on Matrix] [p.s: can someone work out how to send Matrix $5 every time someone quotes xkcd 927 at us...?]
    - corobo 10y ago
      > p.s: can someone work out how to send Matrix $5 every time someone quotes xkcd 927 at us...? I'm sure when Matrix is the go-to chat protocol you'll get more than that. Until then it is sorta fitting..
      - Arathorn 10y ago
        sigh no, the point is that it doesn't fit because Matrix does not try to be "yet another chat protocol that fits everyone's use cases". It aspires to be a bridging protocol that links other chat protocols together rather than replacing them.
        corobo 10y ago
        I'll be honest I've not scoured your entire site but I'm just not seeing that description (and didn't at all earlier, I've since looked further). From what I gathered you want to be the email of chat protocols. The only mention of wanting to bridge other protocols is a quick mention half way down your FAQ page.
        10y ago
zeveb 10y ago
> There is also XMPP (and has been for years) which does not suffer from many of IRCs shortcomings. In return, it suffers from its own shortcomings, mainly XML and second-system effect (leading to too much complexity & too many options). What we really need, I think, is exactly what Slack, Mattermost &c. give: persistent, multi-device, multi-group chat. I think that solving that problem in a nice, small, secure protocol (one that doesn't imply a browser-first way of doing things — and indeed, 'secure' probably prevents using a browser in the first place) is more than enough of a problem for someone to solve. Heck, even just the multi-device shared-identity problem is surprisingly difficult.
stonogo 10y ago
> There seems to be no canonical specification of IRC itself. Is this a joke? Did you think all this stuff just accidentally worked? I'm not sure how seriously to take your entire message because of this bizarre idea. https://tools.ietf.org/html/rfc1459 https://tools.ietf.org/html/rfc1459 https://tools.ietf.org/html/rfc2810 https://tools.ietf.org/html/rfc2810 https://tools.ietf.org/html/rfc2811 https://tools.ietf.org/html/rfc2811 https://tools.ietf.org/html/rfc2812 https://tools.ietf.org/html/rfc2812 https://tools.ietf.org/html/rfc2813 https://tools.ietf.org/html/rfc2813
- catdog 10y ago
  Sure it's standardized enough to generally work but to my knowledge only RFC1459 is widely seen as authoritative. The protocol evolved quite a bit over the years but a lot of the extensions covered (and maybe not covered) by those later RFCs are handled to some extent differently between IRCd implementations. There at least seems to be some effort [1] now to fix some of IRCs issues and bring the whole mess more in line again. As IRC is still widely used and probably there to stay I hope it will work out. [1] http://ircv3.net http://ircv3.net

by catdog 10y ago

lmm 10y ago

> not encoding in ASCII IIRC the original standard specifies a particular 8-bit character set (not ASCII), though the broader point stands. > There is also XMPP (and has been for years) which does not suffer from many of IRCs shortcomings. XMPP is useless for multiple devices: there's no way to receive messages on both (some servers will deliberately violate the spec here because the spec is stupid), and the federated history spec has been under development for about a decade now. Groupchats don't work properly with federation and have terrible UX in every client I've tried. Everyone assumes XMPP must be good because it's open-source (which is usually a pretty good heuristic) but I've come to the conclusion it's actually a really bad standard.

catdog 10y ago
> XMPP is useless for multiple devices: there's no way to receive messages on both (some servers will deliberately violate the spec here because the spec is stupid) XEP-0280: Message Carbons and there was that priority thing before. It somehow worked in the past and now it's definitely solved. > Groupchats don't work properly with federation The only annoying problem i can think of is when the server hosting the MUC restarts clients seemingly don't notice that they have to rejoin. > and have terrible UX in every client I've tried. Maybe you tried terrible clients? Unfortunately are few now which aren't terribly behind regarding protocol support. > and the federated history spec has been under development for about a decade now. I think thats the real problem. "Nobody" implements newer XEPs, especially if they are not finalized yet but how should they finalize if nobody puts them to trial? Everybody seems to have settled in screaming out what does not work so well but instead of helping to fix it they halfway reinvent the wheel or switch to centralized proprietary solutions which may have nicer looking clients but often don't even try to solve harder problems like multi client support. I didn't have a look at Matrix yet, maybe it's worth it but there is always the danger of creating yet another standard [1] (which may not even be as perfect as originally thought in the end either). > but I've come to the conclusion it's actually a really bad standard. But is it really that bad (especially at the basic fundaments) to justify something completely new? XMPP at least provides a lot of ability to evolve without breaking everything that was. [1] https://xkcd.com/927/ https://xkcd.com/927/
- Arathorn 10y ago
  hopefully Matrix avoids falling into the cliché of xkcd 927 by focusing on defragmenting the existing silos - building a metanetwork between IRC, Slack, XMPP, etc etc. So rather than saying "hey everyone, throw away your current stuff", we say "hey everyone, build a bridge into Matrix - it's fun and easy (100 LOC for the slack bridge: https://github.com/matrix-org/matrix-appservice-bridge/blob/master/HOWTO.md)" https://github.com/matrix-org/matrix-appservice-bridge/blob/.... If you want to use Matrix natively via weechat or whatever then so much the better, but the intention is to be useful as way more than just another msging protocol. It's meant to more be a big open decentralised database for conversations and other realtime data - more in common with IPFS or even the Web itself. [disclaimer: I work on Matrix] [p.s: can someone work out how to send Matrix $5 every time someone quotes xkcd 927 at us...?]
  - corobo 10y ago
    > p.s: can someone work out how to send Matrix $5 every time someone quotes xkcd 927 at us...? I'm sure when Matrix is the go-to chat protocol you'll get more than that. Until then it is sorta fitting..
    - Arathorn 10y ago
      sigh no, the point is that it doesn't fit because Matrix does not try to be "yet another chat protocol that fits everyone's use cases". It aspires to be a bridging protocol that links other chat protocols together rather than replacing them.
      - corobo 10y ago
        I'll be honest I've not scoured your entire site but I'm just not seeing that description (and didn't at all earlier, I've since looked further). From what I gathered you want to be the email of chat protocols. The only mention of wanting to bridge other protocols is a quick mention half way down your FAQ page.
        10y ago

zeveb 10y ago

> There is also XMPP (and has been for years) which does not suffer from many of IRCs shortcomings. In return, it suffers from its own shortcomings, mainly XML and second-system effect (leading to too much complexity & too many options). What we really need, I think, is exactly what Slack, Mattermost &c. give: persistent, multi-device, multi-group chat. I think that solving that problem in a nice, small, secure protocol (one that doesn't imply a browser-first way of doing things — and indeed, 'secure' probably prevents using a browser in the first place) is more than enough of a problem for someone to solve. Heck, even just the multi-device shared-identity problem is surprisingly difficult.

stonogo 10y ago

> There seems to be no canonical specification of IRC itself. Is this a joke? Did you think all this stuff just accidentally worked? I'm not sure how seriously to take your entire message because of this bizarre idea. https://tools.ietf.org/html/rfc1459 https://tools.ietf.org/html/rfc1459 https://tools.ietf.org/html/rfc2810 https://tools.ietf.org/html/rfc2810 https://tools.ietf.org/html/rfc2811 https://tools.ietf.org/html/rfc2811 https://tools.ietf.org/html/rfc2812 https://tools.ietf.org/html/rfc2812 https://tools.ietf.org/html/rfc2813 https://tools.ietf.org/html/rfc2813

catdog 10y ago
Sure it's standardized enough to generally work but to my knowledge only RFC1459 is widely seen as authoritative. The protocol evolved quite a bit over the years but a lot of the extensions covered (and maybe not covered) by those later RFCs are handled to some extent differently between IRCd implementations. There at least seems to be some effort [1] now to fix some of IRCs issues and bring the whole mess more in line again. As IRC is still widely used and probably there to stay I hope it will work out. [1] http://ircv3.net http://ircv3.net