Hacker News Reader

Comment by antirez | Hacker News Reader

Happy for the people that built it, with the idea of improving what the chat was. Sad for the internet, because we were better in the 1980s with an open standard like IRC, and gradually the internet community lost the ability to adapt their old open protocols for the future.

View on HN

The death of the protocol.

People no longer release protocols, they release products. The open net, the open web has truly died.

I wonder sometimes what we're missing because the conditions that let the web grow out of the internet have disappeared. What next leap are we missing?

Not products, but platforms.

And in the past you could not be de-protocol-ed

Not by mobs of angry students, but protocol managing entities like Microsoft, Novell, IBM, and others sure could make your interpretation of the protocol invalid. Particularly if you had some competing software out in the wild...

You can code around a protocol change. You can't do that with a de-platforming.

Except people still release protocols. Just look at https://matrix.org/

IRC is an early protocol and wasn't designed for extensibility purposes. A new chat protocol just needs to replace it.

IRC was created in 1988. There have been several chat protocols created since then [1]. A few notable protocols that tick a lot of "modern" boxes:

- Jami

- Matrix

- Signal Protocol

- XMPP

The better question: why aren't new and existing technology companies embracing these protocols and making them ubiquitous?

Personally I think it's because companies have a vested interest in creating walled gardens. The more users that are forced onto a platform, the more money they make. It's against their business interest to create a product that works with their competitors.

[1]: https://en.wikipedia.org/wiki/Comparison_of_instant_messagin...

It might be because Slack has support, a great UI, lots of users, and 'just works'. A company I worked with tried to setup Riot and Matrix and they were having all sorts of problems. Even when they tried to use the Riot.im website there were bugs and features from Slack they needed that were missing. What Matrix and Riot.im is doing is still good though, I hope it takes off.

Matrix is improving all the time. 1.0 was just released

> why aren't new and existing technology companies embracing these protocols and making them ubiquitous?

Because they don't want to be at the behest of protocol maintainers to improve their product? Their goals and the goals of maintainers would never align.

Open source is great, but open source moves at slow pace compared to what a revenue-driven company can. There's a reason that most of the big open source projects have a company backing them.

Open source moves at a slow pace now, but look at HTML between 1994 and 1998, that was a fast-moving and exciting time.

It looks like 1-to-N protocols can grow organically without significant investment (HTTP, hypertext), but N-to-M (chat, social media) cannot.

Which was driven by Netscape, a revenue-driven company.

Complaints about corporations capturing HTML are not new; Google is merely the latest in the line. (That's not to diminish the fact that it's still bad every time. It's just this isn't the first time.)

>It's against their business interest to create a product that works with their competitors.

There's more to it than a simplistic "business interest" to explain it.

For example, the Signal protocol is free to use. No payments for patent royalties or software licenses required. Moxie Marlinspike's company Signal LLC (Open WhisperSystems) is a non-profit entity.

But notice that an organization that isn't pressured into making a profit and that's using an underlying free protocol -- does not want to federate with LibreSignal[0].

This an example of where the "openness of a protocol" runs into a hard reality of "closed wall of implementation". The protocols themselves can cost $0 but implementations (e.g. cpu+disk+bandwidth+staff) cost more than $0 which leads to complaints of it being "not really open".

If people do not examine the economic forces surrounding any protocol, they will always be perplexed why the internet is not as free & open as they think it should be. Even non-profit entities are not immune from economic forces.

[0] https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

Sad thing is that matrix is not working really well

how come?

There’s no money to be made in creating and building on open protocols. Without money to be made there’s no funding. Without funding there’s no way to create great experiences. Without great experiences nobody will use the thing.

Pretty straightforward, really

And yet, as a counterexample, HTML and HTTP persist. Maybe things aren't as straightforward as they seem.

With QUIC, even TCP is getting replaced because of the need to innovate despite protocol ossification. It's almost impossible to improve TCP at this point due to non-compliant endpoints and middleboxes.

It's a similar "lowest common denominator" issue with IRC, XMPP, mail and many others. Yes, XMPP can - in theory - do almost everything Slack does, but there's dozens of clients supporting a different subset of the protocol. Of course nobody wants to use it.

I don't get how your point is a counter example to the parent's argument? I think there is a lot of money to be made in building on HTML and HTTP. For one, a faster HTTP protocol directly means more cost efficiency in hosting and streaming content, better customer conversions, etc.

IMO, HTTP and HTML are counter-examples to the statement 'There’s no money to be made in creating and building on open protocols.' because they're open protocols that have attracted a great deal of money, and plenty of people creating and building on them.

On the other hand, I don't think anyone accused slack, with multi-megabyte webpages and even worse mobile app, of being a great experience. I think I used it once, and said no more.

Do these things matter to most users? The non engineers at my work have never complained about slack.

They do. Non-engineers just tend to blame the age/quality of their company issued hardware rather than the problematic software causing performance issues.

I've met only a few programmers IRL that complained about slack, and even then it was for ideological reasons, not user experience reasons. Everyone else, most programmers and all non-programmers I know like the user experience.

I haven't had any real issues with desktop or mobile apps either.

I use Slack for work, and while it was an order of magnitude better than the dumpster-fire of Hipchat (which it replaced for our team), I still think that the interface is kind of "meh".

Custom emojis are fun, inline markdown is useful, but it takes a lot of memory for something that, to me, seems like it should be lightweight. We've had IM since the 80's, after all. There's a part of me that has a visceral reaction to seeing an IM client taking more than 100mb of memory (though to be fair they seem to be getting improving that a lot.

I'm not sure what about the experience you had a concern about. Slack is the de facto user experience standard right now, with everyone from discord to teams copying it.

The Electron-ness and memory usage of the app on desktop are certainly annoying, but the UX is still far better than any terminal-based or open source GUI for IRC. It was better than HipChat when my company moved to Slack 4 years ago.

Overall Slack is a net UX improvement over everything that came before.

Microsoft Teams is pretty good.

And with all those problems it's still significantly better than the competition.

I wish I could upvote this comment 1000 times.

That is a very hot take. You're under the impression that nobody thinks slack is a great user experience? What?

Great experiences are dependent on funding? Going back to IRC, many of us had great experiences on there. USENET was a fountain of great experiences. All text mode. Or do you mean "great experiences" as in the kind of thing depicted in Subaru commercials where they are selling the car as a gateway to beautiful mountaintop sunsets and beach picnics?

Great experiences come from true utility and functionality. Not putting lipstick on a pig and calling it The Next Best Thing That Will Make You Happy And Productive.

Try to get the average office worker to use IRC today and see how far that gets you. It really behooves Engineers to put themselves in the shoes of actual users once in a while

Nobody is saying IRC is the greatest thing in the world today. It was very effective in its time, and it existed (and continues to exist!) without a profit-driven motive.

It was effective for orders of magnitude less users than that of current chat apps.

Great experience for a tech nerd vs great experience for your average desk jockey. Nobody is stopping us from making new protocols, continuing to use IRC, etc. The reality is software is no longer a niche thing - its just another part of mainstream business. There are still "power user" versions of formerly-niche domains.

By that reasoning (which I mostly agree with) making it cheaper to build great experiences is a good thing to do.

And yet open-source has exploded.

>The death of the protocol. People no longer release protocols, they release products. The open net, the open web has truly died.

People ascribe too much credit to a protocol. The real issue is the funding model to support spending money on that protocol.

By focusing the lens on the funding, the web wasn't as "open" as people think. The so-called "open" web was a government project which wasn't fully open to the public until about ~1995. Before then, you had to work on government-funded projects (ARPANET & NSFNET). The "open" web was actually quite closed off to people that didn't belong to an institution to give them an ".edu" or ".mil" address.

>I wonder sometimes what we're missing because the conditions that let the web grow out of the internet have disappeared.

The "conditions" were government sponsorship to pay for protocols.

- Vint Cerf developed the TCPIP protocol -- but he was funded by DARPA (USA government). Mr Cerf didn't have to go to venture capital firms on Sand Hill Rd and get funding to pay the salaries of his team to build a proof-of-concept or "MVP". He didn't have to worry about not making payroll if his TCPIP protocol project failed.

- Tim Berners-Lee developed the http protocol and also HTML language -- but he was funded by CERN...which is one step removed from being funded by a consortium of governments[0]. Therefore, TBL didn't have to wear a "salesman" hat and pound the pavement begging enterprise customers to buy his "http protocol stack" so he could buy his expensive NeXT workstation[1] to help build and test the protocol.

Those are prominent examples but it doesn't mean people can't create new protocols on their without government help. The SSL protocol was developed by Netscape -- a commercial business. I believe the the git protocol was developed by Linus without a government grant. (Also note that http v1 was funded by CERN (government sponsored) but http/2 & http/3 appears to be mostly funded by Google (non-government sponsored).)

But notice what happens with "open protocols" like SSL and git: they eventually run into a wall where somebody has to spend money on it. The SSL protocol is free of royalties but the Certificate Authorities issuing certificates are not free of charge. The git protocol is free but enterprise accounts for Github are not. The ActivityPub protocol is also free but Mastodon servers are run by altruistic admins spending their own money or requesting Patreon donations. Somewhere, money has to be spent and that ultimately constrains what the "free web" will be. Releasing a "free to use protocol" is not enough.

Therefore, it doesn't matter if the old IRC protocol is free of charge. People still have to spend money on auxiliary features outside the scope of the protocol. Slack spent money on those extra features (e.g. searchable history, etc) that nobody spent on IRC.

[0] https://en.wikipedia.org/wiki/CERN#Member_states_and_budget

[1] https://en.wikipedia.org/wiki/Tim_Berners-Lee#/media/File:Fi...

I think this is a very good explanation of things.

Reminds me of the "free as in puppies" angle.

ActivityPub shows a lot of promise.

Also look at dat:// take a look. Beaker browser.

ActivityPub (AP) has the advantage of running on top of HTTP. You don't have to convince people to install a new browser. All the tools that communicate over AP run on familiar technologies. The hardest part is convincing people to make an account, so most growth is from people following friends--the key incentive--to Mastodon instances. It's not a big problem in practice. Monoculture concerns aside.

AP doesn't have to run on HTTP, but any alternative has the same problem as anything else that needs its own client. Even browser support for FTP is on the way out, and it used to be standard.

IMHO there need to be balance between open source and revenue, protocol and products. Just because everyone is going one way, doesn't mean it is correct. I have a friend from banking use to make fun of Richard Stallman 15 years ago. However, looking at it not what he said is quite prophetic. What I’m most concern about is cynicism.

We never got an instant messaging that works like email, for one.

matrix is exactly this, at least from an client/server interop standpoint. email is the first massively successful federated application. matrix just needs an easy to use client/webclient. Riot.im is close, but needs some UX love.

Agree. However the fact that E2E with perfect forwarding secrecy is not guaranteed is going to be an issue.

Can you explain? My understanding is that megolm (what Matrix uses) ratchets the session forward every hour or every 100 msgs, whichever first.

Man, it's crazy how much was riding on Slack staying private.

I don't know about that. There's a flurry of open protocols being built on Blockchain and maybe there's a golden age ahead . . .

> "Historically many key protocols, such as TCP/IP and HTTP, have come from researchers. Subsequent iterations of these protocols were often handled by nonprofit organization that tried to wrangle with more or less success the various commercial interests that sprang up around this protocols (the companies that were making and selling software and hardware based on them). The more money was involved the harder this became.

> "Now, however, we have a new way of providing incentives for the creation of protocols and for governing their evolution. I am talking about cryptographic tokens . . .

> "I can’t emphasize enough how radical a change this is to the past. Historically the only way to make money from a protocol was to create software that implemented it and then try to sell this software (or more recently to host it). Since the creation of this software (e.g. web server/browser) is a separate act many of the researchers who have created some of the most successful protocols in use today have had little direct financial gain. With tokens, however, the creators of a protocol can “monetize” it directly and will in fact benefit more as others build businesses on top of that protocol. Given this new incentive I expect a lot of resources to be devoted to protocol innovation."

~ https://continuations.com/post/148098927445/crypto-tokens-an...

I'm a big fan of Pythonista. When I do a search for a topic Google often takes me to a post on the user forums. There's also a Slack channel, but Google can't see it so anything useful in there is much harder to access hence I don't use it. I don't want to encourage content migrating to a proprietary silo. That's why I don't mind Reddit, for all it's faults it's at least still an actual web site.

I think Discord is more a replacement of IRC than Slack could ever be.

Slack is enterprise and workflow-oriented, Discord is community oriented.

I'm truly hoping the Matrix protocol takes off.

(FWIW, /me has been using Matrix-based chat clients for group and individual chats at conferences. Quite happy with it.)

Is it not an inevitable result of federation and decentralization as governance? A camel is a horse designed by a committee, as the saying has it.

I dont think federation has anything to do with it. There were no incentives to bring it to consumers though (in contrast e.g. to email), and by itself it is not easy to use for vast majority of end users.

The email protocols pre-date commercial access to the internet. So incentives were very different when it was created.

so does IRC. I believe even if it adopted IRC as a protocol, slack would still be successful, it's all about the UI being dumb-proof, friendly and capable and seemingly in-vogue. Discord, even more.

If Slack adopted the IRC protocol, it would be subject to the same issue Microsoft had with the early web -- either implementing proprietary extensions to the spec to enable features, kludging in new features by abusing existing functionality, or waiting for spec consensus before expanding.

And furthermore, it'd be reimplemented almost instantly by Facebook / Apple / Microsoft / Google.

So I can see why they decided to chart a different path.

> it'd be reimplemented almost instantly by Facebook

wait, how? It's not like there was/is a lot of ppl on IRC, just a handful, and it doesnt fit into their product (talking with strangers)

Clearly defined spec + order of magnitude funding difference + new market = ideal product cloning opportunity

As has been mentioned here, Facebook is running out of strangers to connect: future growth will depend on adding new types of users.

>it's all about the UI being dumb-proof

Make something idiot-proof and the world will make a better idiot. And it looks like I'm the bigger idiot here because I don't understand the interface at all.

I'm in two servers for two open source projects but my ID seems to be different for the two servers and not federated for some reason. Or is it? I don't really know. ¯\_(ツ)_/¯

Yeah because u re smart enough to understand the IRC so you naturally expect a single identity. Try to empathize with us mere mortals who still have not fully grasped the concept of the emoji.

Federation prevents experimenting, iterating and developing the protocol forward.

Yes there are all sort of workarounds like protocol extensions and what have you not, but then you add massive new friction to the system ("No sorry my client doesn't do OpenVideoCall2.0 it only does LibreAVConference0.3"). That type of friction isn't that hard to deal with if you have a bunch of tech savvy people with time on their hands. But it is no longer appropriate for todays web that is used by everyone.

> Indeed, cannibalizing a federated application-layer protocol into a centralized service is almost a sure recipe for a successful consumer product today. It’s what Slack did with IRC, what Facebook did with email, and what WhatsApp has done with XMPP. In each case, the federated service is stuck in time, while the centralized service is able to iterate into the modern world and beyond.

https://signal.org/blog/the-ecosystem-is-moving/

There s nothing wrong with extensions unless they break the entire system, but seems there was no One IRC company that would essentially dictate extensions to everyone else. Google has changed HTTP and HTML a lot, and email too. Slack could have done the same with IRC (maybe someone else will do in the future? ). Yes, walled gardens are a recipe for success , but despite massive walled gardens we still have not switched wholly to those gardens, because they come and go.

> Federation prevents experimenting, iterating and developing the protocol forward.

How so? Nothing prevent versioning a protocol and having experimental servers.

But you still have to support the old stuff, which at internet scale, is never upgraded. So you have to support a really long tail of old versions.

I talk about that _literally_ in the sentence after the one you quoted.

MLP's "On Port 80" hits on much of the "why": Firewalls increase friction of new protocol development.

There's moe to it, but this is definitely a factor.

https://medium.com/@maradydd/on-port-80-d8d6d3443d9a

Seems like there are 16 billion reasons NOT to choose IRC. From Slack's perspective (and you could argue most of it's users) this was a good choice.

FWIW, I've been using IRC for over 20 years.

We still have IRC for those that choose to use it

IRC has terrible UX, and Slack beat it because the experience is better.

That's not an intrinsic problem with IRC-the-protocol. The only technical issue with it is the lack of server-side channel history scrollback which makes it inconvenient for users who aren't connected 100% of the time. This could have been entirely solved with a single extra server command - "/fetch-channel-history". But I suppose no one was convinced of the need.

If you wanted to make a modern, user-friendly chat application that relies on central servers, there's no reason not to base it on IRC.

By the time slack published the RFC and got a few people on board someone else would have launched and taken all its customers

Twitch.tv uses it

Reply on news.ycombinator.com