The reason all of those incompatible chat protocols pop up is that all of the popular federated protocols lack features like inline image transfer, a usable backlog, persistence, live previews or gimmicks like code formatting and editing and third party integrations.
People want those, and value them enough to give up federation.
Its threaded conversation model really helps with ignoring discussion about topics you're not interested in. When I get back to an IRC/Slack/whatever channel, I spend quite a while catching up. 99% of the conversation does not concern me, yet I have to read it. Zulip's threading is a great solution to this.
> The reason all of those incompatible chat protocols pop up it that all of the popular federated protocols lack features like inline image transfer, live previews, gimmicks like code formatting and editing, Slack's massive ecosystem and more.
Live previews and code formatting don't really have anything to do with the protocol. In Slack, if I send a link to an image or some `code in backticks`, those are sent through the protocol as-is and then the actual formatting is applied on each client receiving the message. There's nothing to prevent these messages being read on a terminal—that client will simply not have all of those features available.
I'd almost call it progressive enhancement—a lot of features can be provided by a client in a way that would be compatible with several underlying protocols.
I want these features too, but on their own they're no excuse to have a unique protocol for every chat project.
This is true. Even the old school of IRC could be wrapped in a nice client, and some formatting tricks could be used to denote rich features. Content that needs to be uploaded to be shared could be uploaded and the URL could be included in the message, so regular IRC clients could click over to see them.
A chat like Miaou wouldn't really make sense with a lesser protocol. People come to Miaou to be sure no ping is ever lost, that the guy in front of them can directly see the game in progress, that the external proven identities are displayed before entry in private rooms (Miaou is mostly used today to coordinate game teams), that other users correctly see the tabular data being shared (or that they can edit in place the whiteboard), etc. The common set of enhancement is what makes Miaou, not something that can be progressive.
A protocol is a contract for interpretations of messages. "Backticks should be formatted as code in clients when they receive them in text messages" is part of the 'protocol' of Slack, even if it's implicit.
(More specifically, you can think of each message body as having a content-type, probably something like "text/x-vnd.com.slack-slackrichtext".)
Not long ago I was shopping around for potential chat solutions for an app I wanted to develop, and I came across this project.
On the surface, the user-interface is not very polished. I'm not sure if this is intended to be an implementation detail of the consumer of this solution, bring-your-own-frontend style, or otherwise.
Additionally, the dependencies sound heavy. Express, Jade; PostgreSQL, Redis; socket.io, jQuery... Of course these are answers to real problems—api, views, persistent storage, a message cache, communication layer, a view layer. But the chances of me building anything on top of this or embedding it in another application are tiny because it already brings so much to the table.
I should clarify: Easy to actually pronounce post hoc, but hard to readily discern its correct pronunciation from its spelling (maybe it should be "meow"?).
I wasn't trying to make any ethnocentric points.
Anyway, naming is so important that YC has tons of internal advice that it gives to its companies about choosing the correct name. It's not all that uncommon for a company to get accepted into YC and then immediately change its name.
When I see tons of similar projects pop up in a short time period (such as chat applications recently), I am feeling kind of divided.
On one hand, it's cool, someone spent their time and actually shipped something. That's great, really.
But on other hand, all the hard work could be utilized so much better if a few people joined their efforts to produce one great product rather than a few less polished ones. Is it that people prefer to work alone? Or is it just too hard to join an existing project (e.g. lack of docs, build procedure and general workflow is too inconvenient)? Or maybe it's too hard to find a project that you'd love to join?
It's not something aimed personal at the OP, really no, just a though I am having when I see similar things.
Miaou is kind of old now. If you look at one of the old rooms (for example https://dystroy.org/miaou/3?Code_Croissants) and hit ctrl-F you'll see an uninterrupted flow of messages dating back from 2012, when it was released. I created it because we needed its features back at that time, and that my friends and me didn't find them anywhere (TBH it seems that many of them are still unique to Miaou).
15 comments
[ 3.1 ms ] story [ 49.4 ms ] threadPeople want those, and value them enough to give up federation.
My personal favorite is Zulip, by the way: https://zulip.org/
Its threaded conversation model really helps with ignoring discussion about topics you're not interested in. When I get back to an IRC/Slack/whatever channel, I spend quite a while catching up. 99% of the conversation does not concern me, yet I have to read it. Zulip's threading is a great solution to this.
Live previews and code formatting don't really have anything to do with the protocol. In Slack, if I send a link to an image or some `code in backticks`, those are sent through the protocol as-is and then the actual formatting is applied on each client receiving the message. There's nothing to prevent these messages being read on a terminal—that client will simply not have all of those features available.
I'd almost call it progressive enhancement—a lot of features can be provided by a client in a way that would be compatible with several underlying protocols.
I want these features too, but on their own they're no excuse to have a unique protocol for every chat project.
(More specifically, you can think of each message body as having a content-type, probably something like "text/x-vnd.com.slack-slackrichtext".)
On the surface, the user-interface is not very polished. I'm not sure if this is intended to be an implementation detail of the consumer of this solution, bring-your-own-frontend style, or otherwise.
Additionally, the dependencies sound heavy. Express, Jade; PostgreSQL, Redis; socket.io, jQuery... Of course these are answers to real problems—api, views, persistent storage, a message cache, communication layer, a view layer. But the chances of me building anything on top of this or embedding it in another application are tiny because it already brings so much to the table.
(Not a big surprise, the developer is from Lyon, France)
Startup names should be easy to spell, pronounce, and remember.
Three strikes against this one.
I wasn't trying to make any ethnocentric points.
Anyway, naming is so important that YC has tons of internal advice that it gives to its companies about choosing the correct name. It's not all that uncommon for a company to get accepted into YC and then immediately change its name.
On one hand, it's cool, someone spent their time and actually shipped something. That's great, really.
But on other hand, all the hard work could be utilized so much better if a few people joined their efforts to produce one great product rather than a few less polished ones. Is it that people prefer to work alone? Or is it just too hard to join an existing project (e.g. lack of docs, build procedure and general workflow is too inconvenient)? Or maybe it's too hard to find a project that you'd love to join?
It's not something aimed personal at the OP, really no, just a though I am having when I see similar things.