Hacker News new | past | comments | ask | show | jobs | submit login

I wish that someone would build an easy-to-use layer on top of an open protocol like IRC or XMPP. The tool could manage setup, configuration, archiving, and notifications.

Instead of building a walled garden that is merely accessible via an open protocol, it would be more interesting to build a thin layer on top of an XMPP server that could even be removed or replaced later, if desired.

They have - e.g. http://vector.im/beta on top of the Matrix.org protocol. [disclaimer, I work on Matrix]

Not to be too negative but based on quick glance it would seem like the Matrix protocol is really "noisy" if compared to something like IRC (which admittedly is ridiculously spartan). How much data ends up flowing down the wires for a simple "hello world" message?

Good question. The data you send in Matrix when transmitting and receiving a message is just the event (message) type, the room ID, and the appropriate key value data for the contents of the event. For an m.room.message event this is msgtype and body - e.g m.text and "hello world". The raw data is therefore only a handful of bytes.

Now, Matrix allows arbitrary transports to actually put that over the wire - but mandates only the most comically simple (and inefficient) as a mandatory baseline. This is a plain HTTP PUT request of the above data encoded as JSON and a few URI parts. The reason for this is that HTTP is insanely ubiquitous and well understood; any random device or language these days can trivially send and receive messages.

However, there is nothing stopping you from using a more efficient transport for the data between your client and your server - we've been experimenting with everything from boring old JSON over WebSockets to COAP or MQTT and even capnproto. We haven't specced any of these yet, but we'll probably add them as optional profiles to the spec in future. Meanwhile plain old REST actually works pretty well in practice :)

The fun stuff in Matrix is all about the eventually consistent decentralised conversation history between servers rather than obsessing about the most efficient way to shove some key value pairs between a client and a server.

But why does it matter? Bandwidth is super-cheap.

"But why does it matter? Bandwidth is super-cheap"

If this comment is serious (and I have my doubts), I'm left speechless... Don't even know where to start. I'll just leave it here http://www.theverge.com/2015/10/28/9625062/facebook-2g-tuesd...

> I'm left speechless...

Oh please. Without even knowing much about the protocol, I am almost positive that it's bandwidth requirements are well below even a relatively light modern webpage and likely well within 2G range.

> "Without even knowing much about the protocol"

> "I am almost positive that it's bandwidth requirements are well below even a relatively light modern webpage and likely well within 2G range."

I'm pretty sure this this is almost certainly the least, or at least within range of, quite likely the least definitive statement I might have ever read (or at least one of the lesser definitive of statements I've read within the past year, or at least the last few months, or so).

We see what you did there.

It's not about the particulars of this protocol. It's about the statement "bandwidth is super cheap". I would have called it super-oblivious first-world thinking but that statement is absurd anywhere on a mobile connection.

You just linked to a 3.5 MB web page. That's more than the complete Shareware DOOM

Any reason not to have openid or persona signup? Its just annoying nowadays to encounter a site where it still wants only plain old username / password.

Matrix as a protocol supports arbitrary login mechanisms; Vector + Synapse can hook into CAS, SAML2, LDAP and OAuth flows already. Patches more than welcome to hook it into OpenID or Persona :)

Persona support would be great!

Pretty sure I heard somewhere that Slack uses a modified IRC bouncer (e.g., ZNC[0]) to implement accounts. Could be wrong about that, but if that is in fact the case, this whole Slack vs. IRC debate would take on a whole new level of absurdity.

[0]: http://wiki.znc.in/ZNC

Slack has never been about the underlying tech (which may well be IRC), it's all about the polish. A lot of comments I see here about Slack remind me of the infamous "you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem" ( https://news.ycombinator.com/item?id=9224 ).

> Slack has never been about the underlying tech (which may well be IRC)

Yes, and that's the gripe with Slack - because it should be IRC underneath, but it isn't. Instead of using an open, standard protocol they fragmented the communications space even further.

But yeah, that's how SV rolls these days. Locking people in.

Slack offers both an IRC and an XMPP interface. I don't think it would be possible to implement all the functionality over IRC. I do agree that the protocol should be an open standard though.

Slack already has the ability to do the opposite: https://slack.zendesk.com/hc/en-us/articles/201727913-Connec...

There's some startups like https://grove.io/ that do it.

I think the biggest problem is the people who use IRC aren't the type of people to pay. Additionally, walled gardens are pretty nice when it comes to making a cohesive experience. As soon as you build on top of something else, you're beholden to its limitations.

Isn't there a more fundamental issue that IRC does not map to Slack? Mentioned over and over, but Slack backlog is crazy useful, and I don't think IRC the protocol has any mapping for that. There's also things like permission sets that don't map 1:1 (but you can find workarounds, of course)

There's also the whole way notifications work... basically Slack and IRC are only the same (or even similar) on an extremely superficial level.

IRC with a bouncer maps to it

I got pointed to irccloud.com the last time I asked about that.

I wish more people _would_ talk about IRCCloud in these threads. They don't have many people working on their product, but they give me hope that someone actually can modernize IRC. Their newly redesigned web UI is now snappier than Slack (on Chrome at least), they support emoji, cmd+k, and image/video/pastebin/gist/tweet/etc embedding. Only real downside is that they're currently developing the ability to search your logs. I know some people using it as a bouncer with their own client, but then taking advantage of mobile clients and push notifications.

Give the people what they want!

> I wish that someone would build an easy-to-use layer on top of an open protocol like IRC or XMPP.

They have: http://getkaiwa.com

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact