7 ms·

With your IRC system, how did you deal with channel history, i.e. seeing messages that were delivered to the channel while the user wasn't there, something that

With your IRC system, how did you deal with channel history, i.e. seeing messages that were delivered to the channel while the user wasn't there, something that slack and teams does well?

Fuzzwah 5y ago
I'm not the OP, but the usual method is that everyone runs an irc client in a screen on a server that they SSH into from their workstation.
- pmarreck 5y ago
  I did this years ago and this was indeed one way to do it (apparently still is)
  - gaws 5y ago
    I can confirm that I use this method. It works.
    - pmarreck 5y ago
      I have a possible thing I discovered recently that you might like (especially if the machine you leave screened is on your home LAN): https://tailscale.com/ https://tailscale.com/ has a free tier that lets you pretty trivially set up a VPN (with separate DNS and everything) from anywhere, to anywhere (and the name resolves correctly from anywhere as well). Avoids having to map ports etc. Anyway I've been playing with it and it's a neat toy at least, for sure, being able to access anything in my network from anywhere without having to manage port-mapping at my router, etc. I'm actually going to use it to set up my own cloud dev I can access from anywhere, but it has tremendous utility beyond that
c0l0 5y ago
We had an internal instance of ZNC for human users to connect their clients to (at their option - but that was the documented and preferred way of getting onto the IRC network). Creating ZNC user profiles was part of the semi-automated onboarding/setup procedure, whilst ZNC authentication was done against the dovecot IMAP/SASL server we had for email. More casual IRC users in the company (marketing etc.) usually preferred to use an intranet-hosted web application (The Lounge) to access it from their browser, while most IT people had native clients of their choice set up (hexchat, irssi, etc.). Worked well.
- tarkin2 5y ago
  Thanks, I was inspired by your post and looked at irc servers. The main problem, vis-a-vis slack, was the channel history. There are modules but they have timestamp and limit problems. And irssi in gnu screen would only work while screen is running and would only work for those happy with the setup. ZNC, although sadly adding more complexity, seems to be the way to go.
  - progval 5y ago
    > There are modules but they have timestamp You need a client and bouncer (or server, if you connect directly) that supports this extension: https://ircv3.net/specs/extensions/server-time https://ircv3.net/specs/extensions/server-time > and limit problems. ditto, but https://ircv3.net/specs/extensions/chathistory https://ircv3.net/specs/extensions/chathistory if I understand you correctly.
- zacmps 5y ago
  ZNC has its own issues. We had a repeatable crash that happened every time a particular user connected (it took us a while to figure that out).
  - c0l0 5y ago
    Sure, most software projects and products have their share of flaws and bugs :) I do not claim ZNC or our whole IRC setup was perfect, but for me and many others, it did a very decent job of providing effective, no-frills, getting-things-done means of communicating, all while consuming little resources on both server and clients, and being simple, underestandable, and easy to hook other software into. I really miss it, and personally dislike (especially the client UX of) most trendy/recent alternatives.
jethro_tell 5y ago
We had a similar thing going, people could set up a packages znc bouncer but the general rule was to assume everything was pretty much ephemeral to anyone not there. the best part to me about irc rooms is that they are allowed to be considered ephemeral, just like hallway talk and coffee breaks. If something comes of the discussion. Update docs, post the chat log in the wiki, send an email with cliff notes and ask if others care to discuss, halt and get the right people in the room. When you decide, 'hey, we have an idea, or a change in direction' you'd then document or make the case in a way that is more clear and user friendly than a mile of ephemeral chat. This is the same reason people send out meeting summaries instead of transcripts. We've moved to this point where nothing is ephemeral. But a random chat isn't a good way to understand why things are being done. It's just too much to parse. And at some point new people are looking for a needle in a haystack and they just kinda checkout. I thing documentation should be intentional, the why should be clear in a doc that doesn't waste time and is formated in a way that we have come to understand as the best practices of technical documentation. You'd start with a quick overview of both the problem and proposed or adopted solution and the reader can decide if they need more info. Especially with remote work, I think it's important to have ephemeral areas for discussion without expectations that everyone keeps up on the whole chat. Thinking every team member needs to know every word of discussion is ludicrous.
- benhurmarcel 5y ago
  I don’t think it’s about referring to the chat log in the long term, it’s just about not obligating people to constantly follow the chat. I’d be fine with all chats being deleted after a month. But if I’m out one day I’d like to see my colleague’s message about the project I currently work on.
- jimmaswell 5y ago
  > everything was pretty much ephemeral Reminds me of this classic: https://www.youtube.com/watch?v=O2rGTXHvPCQ https://www.youtube.com/watch?v=O2rGTXHvPCQ

With your IRC system, how did you deal with channel history, i.e. seeing messages that were delivered to the channel while the user wasn't there, something that slack and teams does well?

Fuzzwah 5y ago

I'm not the OP, but the usual method is that everyone runs an irc client in a screen on a server that they SSH into from their workstation.

pmarreck 5y ago
I did this years ago and this was indeed one way to do it (apparently still is)
- gaws 5y ago
  I can confirm that I use this method. It works.
  - pmarreck 5y ago
    I have a possible thing I discovered recently that you might like (especially if the machine you leave screened is on your home LAN): https://tailscale.com/ https://tailscale.com/ has a free tier that lets you pretty trivially set up a VPN (with separate DNS and everything) from anywhere, to anywhere (and the name resolves correctly from anywhere as well). Avoids having to map ports etc. Anyway I've been playing with it and it's a neat toy at least, for sure, being able to access anything in my network from anywhere without having to manage port-mapping at my router, etc. I'm actually going to use it to set up my own cloud dev I can access from anywhere, but it has tremendous utility beyond that

c0l0 5y ago

We had an internal instance of ZNC for human users to connect their clients to (at their option - but that was the documented and preferred way of getting onto the IRC network). Creating ZNC user profiles was part of the semi-automated onboarding/setup procedure, whilst ZNC authentication was done against the dovecot IMAP/SASL server we had for email. More casual IRC users in the company (marketing etc.) usually preferred to use an intranet-hosted web application (The Lounge) to access it from their browser, while most IT people had native clients of their choice set up (hexchat, irssi, etc.). Worked well.

tarkin2 5y ago
Thanks, I was inspired by your post and looked at irc servers. The main problem, vis-a-vis slack, was the channel history. There are modules but they have timestamp and limit problems. And irssi in gnu screen would only work while screen is running and would only work for those happy with the setup. ZNC, although sadly adding more complexity, seems to be the way to go.
- progval 5y ago
  > There are modules but they have timestamp You need a client and bouncer (or server, if you connect directly) that supports this extension: https://ircv3.net/specs/extensions/server-time https://ircv3.net/specs/extensions/server-time > and limit problems. ditto, but https://ircv3.net/specs/extensions/chathistory https://ircv3.net/specs/extensions/chathistory if I understand you correctly.
zacmps 5y ago
ZNC has its own issues. We had a repeatable crash that happened every time a particular user connected (it took us a while to figure that out).
- c0l0 5y ago
  Sure, most software projects and products have their share of flaws and bugs :) I do not claim ZNC or our whole IRC setup was perfect, but for me and many others, it did a very decent job of providing effective, no-frills, getting-things-done means of communicating, all while consuming little resources on both server and clients, and being simple, underestandable, and easy to hook other software into. I really miss it, and personally dislike (especially the client UX of) most trendy/recent alternatives.

jethro_tell 5y ago

We had a similar thing going, people could set up a packages znc bouncer but the general rule was to assume everything was pretty much ephemeral to anyone not there. the best part to me about irc rooms is that they are allowed to be considered ephemeral, just like hallway talk and coffee breaks. If something comes of the discussion. Update docs, post the chat log in the wiki, send an email with cliff notes and ask if others care to discuss, halt and get the right people in the room. When you decide, 'hey, we have an idea, or a change in direction' you'd then document or make the case in a way that is more clear and user friendly than a mile of ephemeral chat. This is the same reason people send out meeting summaries instead of transcripts. We've moved to this point where nothing is ephemeral. But a random chat isn't a good way to understand why things are being done. It's just too much to parse. And at some point new people are looking for a needle in a haystack and they just kinda checkout. I thing documentation should be intentional, the why should be clear in a doc that doesn't waste time and is formated in a way that we have come to understand as the best practices of technical documentation. You'd start with a quick overview of both the problem and proposed or adopted solution and the reader can decide if they need more info. Especially with remote work, I think it's important to have ephemeral areas for discussion without expectations that everyone keeps up on the whole chat. Thinking every team member needs to know every word of discussion is ludicrous.

benhurmarcel 5y ago
I don’t think it’s about referring to the chat log in the long term, it’s just about not obligating people to constantly follow the chat. I’d be fine with all chats being deleted after a month. But if I’m out one day I’d like to see my colleague’s message about the project I currently work on.
jimmaswell 5y ago
> everything was pretty much ephemeral Reminds me of this classic: https://www.youtube.com/watch?v=O2rGTXHvPCQ https://www.youtube.com/watch?v=O2rGTXHvPCQ