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

Absence of certain features in IRC considered a feature

drewdevault.com

Post reply on HN
Print view View original

101–110 of 222 posts

Re: Absence of certain features in IRC considered a feature

#101

Post by sirn »

KirinDave wrote: post #73
ddevault wrote: post #40

Earlier quoted context omitted.

As a user of non-English languages, this is not really a problem in practice. We settled on UTF-8 years ago. My second language is pratically the worst case for bumping up against these limits and I never have an issue with them.

Really. So you don't think Japanese folks just don't run into problems? Or Koreans? Or anyone using a primarily upper Unicode alphabet that is phonetic?

Japanese and Chinese in particular can compress a lot more meaning in a byte than many other languages[1]. I pick up a random article at Nikkei.com[2] and calculate number of bytes of the first paragraph, and it's only 449 bytes in UTF-8[3]. Chinese is even more efficient at this, as you can basically fit the whole news in a Tweet.

[1]: Idiomatic Yojijukugo 四字熟語 is an extreme example for this, but there's non-idiom Yojijukugo too, e.g. 日米関係 is a 12 bytes word that translates to "United States-Japan relations"

[2]: https://www.nikkei.com/article/DGXMZO46571150V20C19A6000000/

[3]: It describes how people are walking around the park in Chicago on Jun 13 to catch a rare Pokemon with a one line interview of a son of Mr. Stuart from California.

(I speak three languages: Thai, English, Japanese)

Re: Absence of certain features in IRC considered a feature

#102

Post by la_barba »

maeln wrote: post #41

I love the simplicity of IRC, I still use it to this day, but I have to say, I understand why IRC cannot be used for any serious team communication. The two biggest pain point that I see is: 1. Because there is no real account management you don't have any proper authentication, which make administrating a channel real dodgy (even with network provided bots). 2. No offline history: You have to have a client/bouncer r…

Couldn't you layer your own account management and other conveniences on top of IRC ? Like use the underlying chansrv tech for auth but add your own layer on top for password retrieval or 2FA. You could always run a server which has dedicated bots doing the bounce per user. That way you never have to auth directly with the server, etc. Maybe a little over-complicated, but it lets you use the existing tech which is already widespread.

Re: Absence of certain features in IRC considered a feature

#103

Post by superkuh »

abstractbeliefs wrote: post #95
superkuh wrote: post #52

It isn't that the features don't exist. I think most people on IRC just see the internet as their platform. Integrating image hosting into IRC seems absurd when there are perfectly good browsers and ways to host or self host images. Stuffing everything into one client, or worse, one corporation just restricts features and provides a single point of failure in both technical and censorship terms.

An example of how this could work is that a client could support receiving an image. When this happens, it could upload it to an image host of choice, get the url, and send that. It's what users already do, but without having to pop a new tab, head to imgur, upload the image, and copy paste it back etc.

But why? Why add extra steps and add in having to keep the code to adapt to APIs or URL paths that change every 6 months? It's not like keeping a browser and IRC client open are mutually exclusive.

I personally just $ cp whatever.jpg ~/www/ because I host my static site from my home connection and have for 20 years. I know self-hosting is not for everyone but everyone self hosting would literally solve all the problems of the web.

Re: Absence of certain features in IRC considered a feature

#104

Post by johannes1234321 »

Spivak wrote: post #55
johannes1234321 wrote: post #49

Earlier quoted context omitted.

> This is all very true but they're also a company that wants to push their API since that's where most of their stickyness comes from as a business. This is what people said about Twitter as well ;) And slack, for instance, discontinued their IRC gateways as that limited their possibilities to "innovate" and I can image Slack, being pushed by shareholders, restricting free add-ons to getting data into slack (from Ve…

Well yeah, I'm in no way saying that people in the OSS world should standardize on single company's proprietary protocol and platform and if IRC is the only thing people from two projects can agree to speak then it's what we've got. But we really need to stop trying to make IRC 'work' and build something more usable that can interop with existing IRC networks (hi Matrix!). IRC is fundamentally not a good enough proto…

There were attempts to replace IRC with more modern (back in those days ...) architecures. For instance jabber/xmpp. But between IRC and commercial alternatives it hardly played a role. (I see more usage of commercial jabber extensions in Cisco than jabber itself these days)

Re: Absence of certain features in IRC considered a feature

#105

Post by mceachen »

Karunamon wrote: post #93
frou_dh wrote: post #88

Kooky "reaction GIFs" in work chat are so inane. I mean, there's certainly a time and a place for browsing funny GIFs on the web, but making it a first-class part of work chat is so juvenile it's unreal.

This mindset is alien to me. Humor is a generally positive thing and can't help but improve mental state while working.

> can't help but improve mental state

Unless you regard it as inane.

Throwing reaction gifs at a happy birthday/congratulation post is one thing.

Throwing them into the oncall production ops channel and context switch everyone so they can see Homer back into a hedge is another.

Re: Absence of certain features in IRC considered a feature

#106

Post by alyandon »

Karunamon wrote: post #93
frou_dh wrote: post #88

Kooky "reaction GIFs" in work chat are so inane. I mean, there's certainly a time and a place for browsing funny GIFs on the web, but making it a first-class part of work chat is so juvenile it's unreal.

This mindset is alien to me. Humor is a generally positive thing and can't help but improve mental state while working.

I just turn off notifications on Slack and only pay attention to it when I choose to. As a result, someone being silly with reaction emojis or memes in a channel just doesn't really bother me.

Re: Absence of certain features in IRC considered a feature

#107

Post by abstractbeliefs »

superkuh wrote: post #103
abstractbeliefs wrote: post #95

Earlier quoted context omitted.

An example of how this could work is that a client could support receiving an image. When this happens, it could upload it to an image host of choice, get the url, and send that. It's what users already do, but without having to pop a new tab, head to imgur, upload the image, and copy paste it back etc.

But why? Why add extra steps and add in having to keep the code to adapt to APIs or URL paths that change every 6 months? It's not like keeping a browser and IRC client open are mutually exclusive. I personally just $ cp whatever.jpg ~/www/ because I host my static site from my home connection and have for 20 years. I know self-hosting is not for everyone but everyone self hosting would literally solve all the proble…

well, it's an entirely client side thing to have, so the "why" very much comes down to the developers balance on adding extra code for extra convenience. The developer might like it personally, or they might find it's a feature that their users want, or both.

As an example, I have my thinkpads prtscr button hooked up to automatically capture the screen, upload to 0x0.st, put the url into my clipboard, and then alert dunst to pop a notification that it's done.

It takes a very common 60 second process and makes it almost as fast as prtscr, ctrl+v

Re: Absence of certain features in IRC considered a feature

#108

Post by enlyth »

superkuh wrote: post #103
abstractbeliefs wrote: post #95

Earlier quoted context omitted.

An example of how this could work is that a client could support receiving an image. When this happens, it could upload it to an image host of choice, get the url, and send that. It's what users already do, but without having to pop a new tab, head to imgur, upload the image, and copy paste it back etc.

But why? Why add extra steps and add in having to keep the code to adapt to APIs or URL paths that change every 6 months? It's not like keeping a browser and IRC client open are mutually exclusive. I personally just $ cp whatever.jpg ~/www/ because I host my static site from my home connection and have for 20 years. I know self-hosting is not for everyone but everyone self hosting would literally solve all the proble…

Because I want to be able to simply drag and drop an image for someone to see it immediately and not faff about with 15 extra steps of alt tabbing through browsers and copying links and waiting for uploads to finish.

Re: Absence of certain features in IRC considered a feature

#109

Post by alyandon »

mceachen wrote: post #105
Karunamon wrote: post #93

Earlier quoted context omitted.

This mindset is alien to me. Humor is a generally positive thing and can't help but improve mental state while working.

> can't help but improve mental state Unless you regard it as inane. Throwing reaction gifs at a happy birthday/congratulation post is one thing. Throwing them into the oncall production ops channel and context switch everyone so they can see Homer back into a hedge is another.

How is that really any different from someone engaging in off-topic banter in an IRC channel? Humans are being human and I don't really see how the problem as you describe it is somehow specific to non-IRC mediums.

Re: Absence of certain features in IRC considered a feature

#110

Post by KirinDave »

sirn wrote: post #101
KirinDave wrote: post #73

Earlier quoted context omitted.

Really. So you don't think Japanese folks just don't run into problems? Or Koreans? Or anyone using a primarily upper Unicode alphabet that is phonetic?

Japanese and Chinese in particular can compress a lot more meaning in a byte than many other languages[1]. I pick up a random article at Nikkei.com[2] and calculate number of bytes of the first paragraph, and it's only 449 bytes in UTF-8[3]. Chinese is even more efficient at this, as you can basically fit the whole news in a Tweet. [1]: Idiomatic Yojijukugo 四字熟語 is an extreme example for this, but there's non-idiom Y…

This is fair, I should have thought more about the list.

For Japanese, I don't think the way people talk casually to one another is as amenable to compression as newspaper headlines

But surely for Thai you're in a sub-optimal boat?

Post reply on HN