6 ms·

You still can, it's just that you have to switch apps too. Which undoubtedly creates more upheaval, and I am guessing that a lot more people would get left behi

You still can, it's just that you have to switch apps too. Which undoubtedly creates more upheaval, and I am guessing that a lot more people would get left behind in the process. But still, it's not like communities that don't use IRC are helpless.

mbreese 5y ago
However, this does reinforce the idea that: protocols > programs But you can’t get funding for managing a protocol.
- Pet_Ant 5y ago
  Protocols are better than programs because they give users power. Programs are better than protocols because they don’t give users power. It’s a matter of perspective.
  - mbreese 5y ago
    You’re right, of course. But I think that if your goal is to build a robust system, protocols win. If you want to monetize your users, then you absolutely need that walled garden and ease of use that a program provides. If you have a protocol based application, then you can only really monetize the service, not your users. For example, only a few email providers have enough users to sell ads (Gmail). There are far more providers that sell the service as opposed to advertising to users. Although, I will admit building a robust protocol is difficult. It is much easier to iterate a feature set if you only have to worry about one implementation. But this is a trade off between short term gains at the expense of the long term. Email for all its warts will still be around in 10 years. Can we say the same for Slack?
- mumblemumble 5y ago
  There's also an ease of use thing. "Slack" and "Discord" can both be thought of as monolithic entities. For less technical communities, that helps with the onboarding. You don't have to worry yourself about the details of networks and servers and clients and nickservs and whatnot. Teaching someone to use irc is a rather thornier issue, and even some tech people might bounce off of it unless they have a compelling reason to burn time on RTFM. Depending on the values of the community, those practical concerns may or may not outweigh other considerations. There's a lot to be said for open protocols, but there's also a lot to be said for UX.
  - swiley 5y ago
    >Teaching someone IRC You mean handing them xchat/colloquy/kiwichat and telling them to come up with a name and click this text box to send a message? Sure irssi is hard to use but unlike Slack and Discord you're not stuck with a single terrible client.
    - TheAdamAndChe 5y ago
      And tell them how to register the nickname, and tell them how to log in, and tell them how to list rooms and join them. Then teach them about op codes. (Lack of) Ease of use is a big reason for IRC's loss in popularity.
      - swiley 5y ago
        You don't need to register a nickname (I didn't when I used freenode) In the clients I mentioned listing and joining rooms works the same way it does on discord and slack: you open the list and click the ones you want to join.
      - SamoyedFurFluff 5y ago
        Discord/Slack already has a bunch of those things- how to mute channels is a big one, as well as how to change ones nickname, how to get a role, and managing permissions for various channels.
      - welterde 5y ago
        Registration is a bit of a sore point (and is being worked on in the IRCv3 WG), but login, ops, channel listing, etc. afterwards isn't - that's all handled quite well by modern graphical IRC clients.
    - tnorthcutt 5y ago
      Try going to https://libera.chat/guides/clients https://libera.chat/guides/clients and reading through that page, and keep track of how many words a non-technical user would not understand. Here's my list: client IRC SASL authentication graphical clients terminal clients bouncers From the very beginning there's jargon. The page does do a good job of explaining the jargon though, so they get points for that. However, if you're a new user, the difference between this 365 word wall of text full of new words and strange client names is striking compared to e.g. Slack's obvious "TRY FOR FREE" button.
- marcodiego 5y ago
  This! Skype users had no choice after microsoft take-over. Whatsapp users had no choice after facebook take-over. Proprietary software is a choice you impose on yourself; proprietary protocols and formats a choice you impose on the others too.
- halfmatthalfcat 5y ago
  Comes down to UX. If your frontend isn't ergonomic, you're doomed. OSS chat protocols suffer from too much choice. Users don't want to go app hunting, they want one stop shopping and be told what to use. Having a centralized platform is making the choice for the consumer and they're happy to oblige.
  - thomasahle 5y ago
    > they want one stop shopping and be told what to use Until that app becomes unusable / bought by Andrew Lee and they wish there was an alternative they could easily migrate to.
tallanvor 5y ago
It's been 15 years since I've used IRC, but what changed with the apps? All the apps I used to use let you choose what domains to connect to.
- swiley 5y ago
  iOS isn't designed for apps that connect to servers not run by the App Author. Push messages must be signed by a key registered to the developer and there is no mechanism to delegate that (for example.)

mbreese 5y ago

However, this does reinforce the idea that: protocols > programs But you can’t get funding for managing a protocol.

Pet_Ant 5y ago
Protocols are better than programs because they give users power. Programs are better than protocols because they don’t give users power. It’s a matter of perspective.
- mbreese 5y ago
  You’re right, of course. But I think that if your goal is to build a robust system, protocols win. If you want to monetize your users, then you absolutely need that walled garden and ease of use that a program provides. If you have a protocol based application, then you can only really monetize the service, not your users. For example, only a few email providers have enough users to sell ads (Gmail). There are far more providers that sell the service as opposed to advertising to users. Although, I will admit building a robust protocol is difficult. It is much easier to iterate a feature set if you only have to worry about one implementation. But this is a trade off between short term gains at the expense of the long term. Email for all its warts will still be around in 10 years. Can we say the same for Slack?
mumblemumble 5y ago
There's also an ease of use thing. "Slack" and "Discord" can both be thought of as monolithic entities. For less technical communities, that helps with the onboarding. You don't have to worry yourself about the details of networks and servers and clients and nickservs and whatnot. Teaching someone to use irc is a rather thornier issue, and even some tech people might bounce off of it unless they have a compelling reason to burn time on RTFM. Depending on the values of the community, those practical concerns may or may not outweigh other considerations. There's a lot to be said for open protocols, but there's also a lot to be said for UX.
- swiley 5y ago
  >Teaching someone IRC You mean handing them xchat/colloquy/kiwichat and telling them to come up with a name and click this text box to send a message? Sure irssi is hard to use but unlike Slack and Discord you're not stuck with a single terrible client.
  - TheAdamAndChe 5y ago
    And tell them how to register the nickname, and tell them how to log in, and tell them how to list rooms and join them. Then teach them about op codes. (Lack of) Ease of use is a big reason for IRC's loss in popularity.
    - swiley 5y ago
      You don't need to register a nickname (I didn't when I used freenode) In the clients I mentioned listing and joining rooms works the same way it does on discord and slack: you open the list and click the ones you want to join.
    - SamoyedFurFluff 5y ago
      Discord/Slack already has a bunch of those things- how to mute channels is a big one, as well as how to change ones nickname, how to get a role, and managing permissions for various channels.
    - welterde 5y ago
      Registration is a bit of a sore point (and is being worked on in the IRCv3 WG), but login, ops, channel listing, etc. afterwards isn't - that's all handled quite well by modern graphical IRC clients.
  - tnorthcutt 5y ago
    Try going to https://libera.chat/guides/clients https://libera.chat/guides/clients and reading through that page, and keep track of how many words a non-technical user would not understand. Here's my list: client IRC SASL authentication graphical clients terminal clients bouncers From the very beginning there's jargon. The page does do a good job of explaining the jargon though, so they get points for that. However, if you're a new user, the difference between this 365 word wall of text full of new words and strange client names is striking compared to e.g. Slack's obvious "TRY FOR FREE" button.
marcodiego 5y ago
This! Skype users had no choice after microsoft take-over. Whatsapp users had no choice after facebook take-over. Proprietary software is a choice you impose on yourself; proprietary protocols and formats a choice you impose on the others too.
halfmatthalfcat 5y ago
Comes down to UX. If your frontend isn't ergonomic, you're doomed. OSS chat protocols suffer from too much choice. Users don't want to go app hunting, they want one stop shopping and be told what to use. Having a centralized platform is making the choice for the consumer and they're happy to oblige.
- thomasahle 5y ago
  > they want one stop shopping and be told what to use Until that app becomes unusable / bought by Andrew Lee and they wish there was an alternative they could easily migrate to.

tallanvor 5y ago

It's been 15 years since I've used IRC, but what changed with the apps? All the apps I used to use let you choose what domains to connect to.

swiley 5y ago
iOS isn't designed for apps that connect to servers not run by the App Author. Push messages must be signed by a key registered to the developer and there is no mechanism to delegate that (for example.)