Live data from Hacker News

Simplicity of IRC

susam.net

151–160 of 250 posts

Re: Simplicity of IRC

#151
I've never really played around with IRC, but I've definitely had the experience the author talks about with Matrix. The server (like mentioned about IRC) is complicated, but interfacing with it as a user or a bot is mostly a few REST endpoints. I've started using Matrix as my go-to interface for new projects. You get IO for free, plus auth, user accounts, and multi-device; leaving just the fun stuff.

Re: Simplicity of IRC

#152

Earlier quoted context omitted.

I couldn't disagree more, I think bash is a horrifically bad programming language. Honestly I'm incredibly surprised anyone could compare PowerShell and bash and think that PowerShell is the arcane one.

The problem is that you think bash is a programming language.

Its bad even for one liners.

Re: Simplicity of IRC

#153
I've been forced to use Slack for the past 5 or 6 years in my professional life and I despise it. It gives me absolutely no ability to customize or automate my workflow without my employer giving me the keys to the kingdom, which they rightly won't do. Slack's service is where the value is. The client is only a means to an end. And yet they guard it with such zeal, threatening those who develop augments or alternatives.

I have the skills. Just let me automate my own machine without making me have to fight you tooth and nail!

Re: Simplicity of IRC

#154
post #10

A number of moons ago, I switched from a company that used IRC for its internal, real-time, ephemeral communication needs to an enterprise shop that used Microsoft Teams to do that (and of course other communication stuff, as the boundaries for what was better kept in Sharepoint, Confluence, Email/Exchange, the legacy Wiki, and/or Teams were never quite clear :)) there. In the old shop, we eventually had all kinds of…

In my experience, Teams has been a terrible alternative to most every option out there, including IRC. The entire UI/UX seems like an afterthought at best.

Agree - it's just Microsoft buy-in at this point. Every product from Office 365 to Teams to just Windows itself is suffering.

To think people build their businesses on this is mind boggling.

Re: Simplicity of IRC

#155

In the beginning was the command line. Then work of bright people of Xerox PARC was used to hide from users the reality that underneath their beloved GUI, computers are just passing around strings of text. Now we yearn for a time when you were just one INT and several MOV away from putting a pixel on a screen, instead of downloading multi-GB IDE to fiddle for a weekend before you can show a simple window.

You don't understand what happened at Xerox PARC or what their "GUI" was. Smalltalk wasn't a language, it wasn't a GUI, it was an _environment_, and its whole point was that it didn't hide anything! It was a completely different paradigm to how computers and their programs are architected today. A Smalltalk system was always meant to be so simple that one could understand, and change, everything about it.

Re: Simplicity of IRC

#156
post #87

I love IRC, unfortunately it doesn't work properly with smartphones because they have a "loose" connectivity (4G towers data etc). I'm not sure IRC apps can deal with this already. It would be nice to have some update to the IRC RFC. If it was well supported for smartphones, I'm still wondering if it would cause some bandwidth costs to servers. EDIT: I know about bouncers, but I would prefer to do without.

I just pay $5/month for IRCCloud. The iOS app could be a lot better, but not only does it make IRC work like any standard chat app that allows messages while you're away, it also offers some modern bare minimum UX like inline images and link cards.

Re: Simplicity of IRC

#157
post #125

Earlier quoted context omitted.

What's more "under control of the enterprise" than a self-hosted IRC server?

It doesn't prevent clients from logging communications in that server. I know the same is possible in slack or teams, but they don't consider that from a legal perspective.

Also legal: doing it in house it's on you vs being a Slack feature means it's on them. CYA by outsourcing.

And consider this also: "hey we're quite sure pur homegrown system is as leak proof as it can be, trust us or fire up an audit team for 5 sprints to asses compliance" vs "Slack has the box checked already"

The fact that folks can e.g technically fire up a headless browser and programmatically interact with the app via capybara or whatever to rebuild a makeshift API, or just take pictures with their phones because the compliant system is inconveniencing them daily is immaterial.

Re: Simplicity of IRC

#158
post #149
post #119

Earlier quoted context omitted.

> That is, unless the enterprise has policies to abide by disallowing API calls ...What?

Welcome to enterprise, where breaking things is a feature so commonly used Microsoft has documentation for it [1] and things are often deployed by people whose sole concern is "minimize attack surfaces". Our Teams installation not only disables API calls (official Teams client only), chat sessions are deleted if no one posts to them meaning most chat history is lost every weekend. [1] https://docs.microsoft.com/en-us…

What a perfect way to describe the situation.

Imagine an enterprise disallowing all VCS service providers -- whether hosted on-prem or cloud -- because they use SSH instead of HTTP.

Re: Simplicity of IRC

#159

The simplicity also comes with problems, such as nickname registration in practice being implemented with bots that have administrative rights, which can lead to social engineering exploits and poor standardization of their interfaces, or the fact that the protocol does not seem to support sending an encoding so it relies on the gentleman's agreement that everyone use UTF-8, which works until that one user using lati…

You mean IRCv3? It’s not all ready/implemented yet, but some of it is already in daily use.

https://ircv3.net/

For example a server can tell the client that it only accepts UTF-8: https://ircv3.net/specs/extensions/utf8-only

Re: Simplicity of IRC

#160
post #155

In the beginning was the command line. Then work of bright people of Xerox PARC was used to hide from users the reality that underneath their beloved GUI, computers are just passing around strings of text. Now we yearn for a time when you were just one INT and several MOV away from putting a pixel on a screen, instead of downloading multi-GB IDE to fiddle for a weekend before you can show a simple window.

You don't understand what happened at Xerox PARC or what their "GUI" was. Smalltalk wasn't a language, it wasn't a GUI, it was an _environment_, and its whole point was that it didn't hide anything! It was a completely different paradigm to how computers and their programs are architected today. A Smalltalk system was always meant to be so simple that one could understand, and change, everything about it.

That's why I've said that their work was used, not that they did it.
Post reply on HN