Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

I personally wouldn't mind IRC (also) having some of those features, and a client with a more Discord-like UX for those that want it.

But I doubt you'll achieve that by single-handedly destroying one of the biggest IRC networks out there and basically guaranteeing folks won't want to work with you.



view as:

To offer a different point of view: If I were to create my own chat protocol, I would actively try to make it next to impossible to implement it on mobile and consider this a feature. Nothing is gained by mobile users. From the features/interfaces they expect, the kind of communication people are accustomed to on mobile, and to them just being idlers 24/7 anyways.

Let people who want smileys, gifs, fancy UI, backlogs upon reconnect, reply features, friend lists, voice features use discord and whatever, and please let IRC be a stream of text messages and old school and a haven from this modern shiny crappy world.


I agree with you, with the exception of backlogs.

I am not denying they can be useful, I am questioning how this should be achieved. You are connected, you receive the messages, you aren't, you don't. You don't want to miss anything, how about making sure you stay connected?

Is this really something that has to be built into the chat protocol, massively increasing its complexity and just giving headaches, security issues, debug problems, wasting developers' time?

I don't consider IRC a replacement for online boards / stackexchange. Even stopped logging completely, don't use a bouncer. If I am online, I'm there. Actually think it's an improvement.


That's being worked on and there are already irc daemons that support it (but it's all a bit bolted on until the standard for that is ratified).

However it is also a feature that has to be enabled by the server operator and here you may run into different opinions if this should be a thing or not.


> To offer a different point of view: If I were to create my own chat protocol, I would actively try to make it next to impossible to implement it on mobile and consider this a feature. Nothing is gained by mobile users.

I can understand where you're coming from, but it's also important to note that a huge part of this planets population doesn't have access to a computer. Many folks, if they have internet access at all, only have access to it through (cheap) mobile devices. A protocol that's explicitly designed to be impractical/hard/impossible to support on mobile would exclude large swaths of people from ever being able to participate.


So what? How come it should be my concern to include everyone, as if everyone was entitled to use my service?

A russian only IRC channel excludes everyone not speaking the language. A Playstation exclusive game title excludes Xbox owners. An OS only targeting x86_64 excludes people with only ARM and i386 machines. An Android only app excludes iOS users. An OS without certain drivers excludes tons of users and use cases.

If I purposefully want to target Desktop users, so what?


>> If I were to create my own chat protocol, I would actively try to make it next to impossible to implement it on mobile and consider this a feature.

> So what? How come it should be my concern to include everyone, as if everyone was entitled to use my service?

You weren't talking about a service, you were talking about designing a protocol in such a way that it wasn't usable for mobile users. That's a very different thing.

I'm saying we shouldn't be designing protocols in such a way as to ensure folks can't implement it in certain settings. If you want to set up an IRC network with a ToS that says "no mobile users" go right ahead.


Absolutely. Totally up for an IRC-like system with some or all of the feature gap closed compared to systems like Slack or Discord, but this Freenode stuff has nothing to do with that.

And anyway, isn't Matrix trying to be that next-gen IRC?


Legal | privacy