5 ms·
Indeed, the dependence on a persistent connection itself is an absolute non-starter for this feature. It's statistically guaranteed to fail, and IRC as a proto
by KirinDave 7y ago
Indeed, the dependence on a persistent connection itself is an absolute non-starter for this feature.
It's statistically guaranteed to fail, and IRC as a protocol spec is powerless to do anything other than shrug.
- ganzuul 7y agoHaving been on IRC for maybe two decades now, I find the impermanence to be part of IRC's charm. People engage with you when you ask them what has been going on; just like in real life. It's a social protocol.
- cwyers 7y agoCertain use cases that Slack et al cater to, you might not get to choose impermanence. There might be compliance/regulatory issues that require you to have document retention policies.
- ganzuul 7y agoAnd if you have retention you need retrieval, and backups, and audit trails for access, and pretty soon you're a SAP customer suffering the Curse of Greyface. I did change careers to escape that...
- asveikau 7y agoBut the lack of reliability I described a few comments up is not just a problem for 24/7 archiving. You will see it in everyday use: your connection will drop, it will take a while for a timeout to notice, and you will miss messages for that period. Now in a real life situation you can mishear or fail to hear. But technology can make this better.
- ganzuul 7y agoI meant to address the second issue you bring up; that you ask if you missed anything during the period. I might not want a 24/7 archive. Especially not for all the silly things I said in my teens.
- zapzupnz 7y ago> you ask if you missed anything during the period For high-volume, fast-paced channels this may not be appropriate. For slower channels where people rarely post anything, you constantly asking "did I miss anything while I disconnected" might be considered spam. > I might not want a 24/7 archive What you may or may not want has no bearing on what the technology should be capable of providing when others may require it. Technology can, and already has, solved these problems. If that's not your cup of tea, fine, but don't impose your own use cases on others through "but it works fine for me"-ism.
- ganzuul 7y agoThe social structure in those two examples will be very different. You would not want to do what you suggest. IRC remains popular, so same to you buddy.
- zapzupnz 7y ago> The social structure in those two examples will be very different. You would not want to do what you suggest. I didn't suggest anybody do anything in my post. I merely postulated on scenarios where technology can (and does exist to) solve problems that aren't your own. > IRC remains popular I don't doubt it; in fact, I never disputed that. Further, in no way did I imply that IRC should cease to exist because other options are out there that address other peoples' needs, nor did I indicate that I think any IRC users are wrong to prefer it. > so same to you buddy Please keep your language respectful; your tone in that reply was nothing short of dismissive and needlessly condescending.
- asveikau 7y agoThe irc userbase is pretty technical and maybe forgiving of glitches. So perhaps that is more OK there. For the general population, the user may not know to doubt reliability, nor do I think they ought to. So I think there is value in higher reliability of delivery.
- dfabulich 7y agoThe post you're replying to isn't referring to "impermanence," it's referring to messages dropped in transit. IRC is an unreliable message transport even if all users are online and trying to listen to each other. The most obvious version of this is a netsplit, but even single users can get isolated from the network and have all of their messages dropped without realizing it until minutes later (if ever). There's no cool name for that; it's just IRC being unreliable. Maybe unreliability is part of the charm for you, but that bug is absolutely not a feature, and not intrinsic to being a "social protocol."
- ganzuul 7y agoYou are correct. IRC is not airtight. You do however get informed by the server after a netsplit has occurred... and key-up retains most of what you have said recently so achieving coherency isn't difficult, although a manual task.
- caf 7y agoThat's only relevant if the feature is being used between bouncers and clients with existing servers. While this is certainly the initial deployment scenario, there's no reason in principle why you couldn't develop a server that natively supports that extension.