[inopinatus]

Also in-client searchable archives, media handling, history editing. All require going outside the IRC protocols.

IRC was designed by hackers, for hackers and it shows. Twenty years ago, IRC was my talk destination of choice and I operated a server within a major IRC network; these days my startup uses Slack which I determined to be the "least irritating" of the 21st century options.

I had high hopes for Google Wave but it was sadly stillborn.

[e12e]

Much of that can be had with a IRC bot. That doesn't include media handling, but you could do search via 1-on-1 /msg (query) with a bot. Then it'd truly be "in client" search.

Most would probably prefer a web ui, with search -- but recording chat could still be done via a bot.

I wouldn't say you could get most of the whole slack experience with just IRC, and you'd probably have to do some work (if only configuring channels/bots/find a web ui etc).

[inopinatus]

This doesn't resolve the multifarious issues with identity, reliability, scalability, federation, standardisation &c &c that further rule IRC out from being the universal panacea.

[voltagex_]

It doesn't have to be. Go help with IRCv3 - http://ircv3.net/. Almost everything that's in Slack and Zulip would just be a capability extension.

[inopinatus]

I stopped reading when the charter said "we are not working on the server protocol". The server protocol is the limiting factor in IRC's architecture.

My interest is in federated, reliable, ad-hoc messaging and IRC's acyclic forwarding graph and lack of any inherent identity model make that impossible.

[e12e]

It depends on the context. You can't federate with Google, Microsoft, Facebook anyway -- and you won't convert the world to use your favourite new protocol (most likely).

So that just leaves you with an easier problem: how can I host conversations etc for my team/org/my friends? And I think a single, isolated irc server should work fine for that use case, and work fine with many different irc clients?

So no, it's not a universial solution -- I just think it's strange when people bring up slack as somehow "better". Sure it's "better" in that it's a product with backing from some fine people -- but if you wanted a solution based on open standard, Free code that you could self-host without worrying about license costs etc ... then a battle-tested IRC server still seems like a half-decent option?

Or put it a different way: if you have 100s of users, could you get many of the features with IRC, and some bots? (Or maybe a slightly tweaked IRC server etc etc)?

[ed: Not that I claim there aren't problems with IRC -- and I've yet to run a personal ircd, so I don't know a) how much work it is to force TLS+SASL[1] and disable plain IRC, or b) if there are other solutions that might be better, that are available right now.

[1] https://freenode.net/sasl/ ]

[inopinatus]

That is not an "easier problem" - that is repeating the problem: yet another venue/client/service we all have to be logged into to find one another.

Moreover, I'm really not interested in spending any time whatsoever on configuring and maintaining an IRC server and a fleet of bots, nor on teaching non-technical users in how to use the resulting heath-robinson system. Really, no. A world of no. I have run both a private IRC service and a public node of a very large network. It's a huge time sink. I've moved on.

As I see it, the only problem in this domain worth burning hours on is developing a protocol (and interoperable implementations thereof) that achieves everything the likes of Slack and Hipchat can do, only in a decentralized and federated manner.

[e12e]

> that is repeating the problem: yet another venue/client/service we all have to be logged into to find one another.

I'm not sure how you can create a new venue without creating a new venue? Perhaps have Google/Facebook/Microsoft/BigCorp create one for you, and the use that? But none of the big players appear to care a whit about facilitating a distributed, self-hosted, open Internet, so that is not going to happen?

> As I see it, the only problem in this domain worth burning hours on is developing a protocol (and interoperable implementations thereof) that achieves everything the likes of Slack and Hipchat can do, only in a decentralized and federated manner.

Any particular reason why you think IRC is inherently not a good building block for such a set of protocols/implementations? I'm not talking about IRC with legacy client support, I'm talking about a system that explicitly breaks comparability with legacy IRC, but still try to build on the years of experience and battle-testing IRC has.

You might be right that it's better to burn IRC to the ground, of course. My takeaway (as an observer, not a server operator in the trenches) is that one takeaway from XMPP/IRC is that:

1) We need authentication of users

2) We need authentication of servers

3) Today, we have no need of plain-text; encrypt and authenticate, or go home.

It appears that 1+3 leaves us with TLS-only, SASL auth if we go the IRC route. For 2) I suppose manual mediation of some kind (eg: server certs with Trust-on-first-Use, possibly a community blacklist?). I'm not sure if this would work, but on the surface it would appear to enable less spam and better security than email currently does.

And it should be much easier to strip down/adapt existing clients and servers than to build an entire new stack?

All that said, it might very well be that IRC server-server federation is hopelessly broken, and there's no hope.

Perhaps some kind of server-auth/community-web-of-trust framework on top of XMPP federation would make more sense?

[ara4n]

Matrix.org is heavily inspired by Wave, albeit using HTTP rather than XMPp, for those searching a more alive option :)

[bjeanes]

> I had high hopes for Google Wave but it was sadly stillborn.

Yeah me too. Google really effed that one up. RIP