3 ms·

Just like ipv6 they are over complicating things that need simplification. End to end encryption and chat room backlog would be nice. DCC and CTCP need to go

Just like ipv6 they are over complicating things that need simplification. End to end encryption and chat room backlog would be nice. DCC and CTCP need to go away. A simpler protocol that does more with less would in my opinion be optimal.

AnssiH 9y ago
AFAIU the site is just documenting existing practices, so I don't think they are over-complicating anything - things just were already complicated (and poorly documented).
- danieloaks 9y ago
  Yep, pretty much. Unfortunately the protocol's gotten fairly complex without standardisation to keep everyone on the same track. I do my best to simplify the text where I can, but a little more in-depth and correct is better than something simpler that doesn't match real-world implementations. edit: With regards to encryption and backlog, they're being worked on in the IRCv3 WG, worth checking out if you're interested in changing the protocol for the better: http://ircv3.net http://ircv3.net
- badrabbit 9y ago
  You are right. My comment was more towards the ircv3 wg.
danieloaks 9y ago
For what it's worth, there's been a bunch of work around backlogs (to simplify bouncers, though if more niche IRCds wanted to incorporate it natively that'd work too). CTCP isn't great, but the simplified CTCP I-D improves things for clients. DCC I'm documenting, hoping we can replace it with something more appropriate and/or extend DCC as it currently exists in a backwards-compatible way (there's a loooot of debate and discussion on DCC in the v3 WG. once we fix up a bunch of misc protocol stuff it's definitely something we'll approach). For sure, simplicity is better than complexity. A fair amount of the v3 work aims to simplify things that are already done in a bunch of vendor-specific ways and bring them all under one clean, well-specified roof. Always happy for extra help there :)

AnssiH 9y ago

AFAIU the site is just documenting existing practices, so I don't think they are over-complicating anything - things just were already complicated (and poorly documented).

danieloaks 9y ago
Yep, pretty much. Unfortunately the protocol's gotten fairly complex without standardisation to keep everyone on the same track. I do my best to simplify the text where I can, but a little more in-depth and correct is better than something simpler that doesn't match real-world implementations. edit: With regards to encryption and backlog, they're being worked on in the IRCv3 WG, worth checking out if you're interested in changing the protocol for the better: http://ircv3.net http://ircv3.net
badrabbit 9y ago
You are right. My comment was more towards the ircv3 wg.

danieloaks 9y ago

For what it's worth, there's been a bunch of work around backlogs (to simplify bouncers, though if more niche IRCds wanted to incorporate it natively that'd work too). CTCP isn't great, but the simplified CTCP I-D improves things for clients. DCC I'm documenting, hoping we can replace it with something more appropriate and/or extend DCC as it currently exists in a backwards-compatible way (there's a loooot of debate and discussion on DCC in the v3 WG. once we fix up a bunch of misc protocol stuff it's definitely something we'll approach). For sure, simplicity is better than complexity. A fair amount of the v3 work aims to simplify things that are already done in a bunch of vendor-specific ways and bring them all under one clean, well-specified roof. Always happy for extra help there :)