Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IRCv3

ircv3.net

Post reply on HN
Print view View original

1–10 of 97 posts

Re: IRCv3

#2

Post by sneak »

I really want the IRC protocol to decouple its sessions from the TCP connection and move to using HTTP as a transport, even if the only api verb is "send" and the only response is "receive output buffer".

I used to really love IRC, and think it could undergo a resurgence given the right upgrades.

Re: IRCv3

#4

Post by tastyfreeze »

sneak wrote: post #2

I really want the IRC protocol to decouple its sessions from the TCP connection and move to using HTTP as a transport, even if the only api verb is "send" and the only response is "receive output buffer". I used to really love IRC, and think it could undergo a resurgence given the right upgrades.

What upgrades do you think should be added? I miss the environment of IRC 25 years ago. Its something that no messenging application has really been able to replicate for me.

Re: IRCv3

#5

Post by pantalaimon »

sneak wrote: post #2

I really want the IRC protocol to decouple its sessions from the TCP connection and move to using HTTP as a transport, even if the only api verb is "send" and the only response is "receive output buffer". I used to really love IRC, and think it could undergo a resurgence given the right upgrades.

What's the advantage of using HTTP?

Re: IRCv3

#6

Post by metroholografix »

sneak wrote: post #2

I really want the IRC protocol to decouple its sessions from the TCP connection and move to using HTTP as a transport, even if the only api verb is "send" and the only response is "receive output buffer". I used to really love IRC, and think it could undergo a resurgence given the right upgrades.

Not everything has to run on top of HTTP or use json.

IRCv3 gets a lot more right than wrong.

Re: IRCv3

#7

Post by otherflavors »

sneak wrote: post #2

I really want the IRC protocol to decouple its sessions from the TCP connection and move to using HTTP as a transport, even if the only api verb is "send" and the only response is "receive output buffer". I used to really love IRC, and think it could undergo a resurgence given the right upgrades.

Many modern IRCDs expose a websocket connection, if that's HTTP enough

Re: IRCv3

#8

Post by sneak »

pantalaimon wrote: post #5
sneak wrote: post #2

I really want the IRC protocol to decouple its sessions from the TCP connection and move to using HTTP as a transport, even if the only api verb is "send" and the only response is "receive output buffer". I used to really love IRC, and think it could undergo a resurgence given the right upgrades.

What's the advantage of using HTTP?

I can reverse proxy it, I can dockerize it, I don't have to modify my firewall, I can TLS-SNI vhost it, I can decouple the TLS keys from the daemon process by terminating TLS on a different container, I can connect to it from weird LANs that filter non-HTTP, I can drop the TCP connections from my mobile device without dropping my whole login session, et c.

Re: IRCv3

#10

Post by swiley »

sneak wrote: post #8
pantalaimon wrote: post #5

Earlier quoted context omitted.

What's the advantage of using HTTP?

I can reverse proxy it, I can dockerize it, I don't have to modify my firewall, I can TLS-SNI vhost it, I can decouple the TLS keys from the daemon process by terminating TLS on a different container, I can connect to it from weird LANs that filter non-HTTP, I can drop the TCP connections from my mobile device without dropping my whole login session, et c.

I don't know what makes http important for reverse proxy or docker. I've reveres proxied and dockerized apps that listen on normal TCP port.
Post reply on HN