> come up with a better open protocol that satisfies all the requirements. [my emphasis] Yeah, no. The email/xmpp approach of small core + extensions is probab

> come up with a better open protocol that satisfies all the requirements. [my emphasis] Yeah, no. The email/xmpp approach of small core + extensions is probably the only viable way. I've played with both rocket.chat and matrix - and while I don't really like the architecture of the former, it feel a lot more like a finished solution/product - with a sane api. I hope Matrix will become more relevant, but I think the documentation and implementation suffers under the design ambitions. In a certain sense smtp, imap and irc all use telnet for transport (and all can be augmented with ssl/tls). That's not a great choice today - but there seems to an odd resistance to combining "the good pieces we have". Maybe just demanding ssh as the (client/server) transport, for example. Use srv records for discovery. Use capnproto for serialization. I don't know, but there seems like there's and odd resistance to reusing great components that are easily tested and developed independently. In that sense the slack/rocket mission is easier: be compatible with yourself. (and using https+json for transport / rpc is perfectly valid re-use. But a promise for stable apis and a clear split between client and server (rather than client+server | bots (ie: non-Roman clients) would be nice. Allow people to bring their own server, or client or both.