Show HN: Miaou, an OS chat for developers and gamers
github.com
github.com
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.
People 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".)