THE OPEN SOURCE POSITIVE FEEDBACK LOOP

The history of Rocket.Chat

WHY?

Why not?

+

BOOM!

BUT people liked it

THE AWESOME

Community STARTED

CONTRIBUTING

Official Docker Repo

100% done by contributors

electron APP

Massive help from

community

Unread counter

Easy way to know how much of the conversation you have missed.

Mentions Marker

Easy way to find messages that you have been mentioned

Hubot Integration

Also known as Rocket.Cat

Stars on GitHub

+400k servers

10M users

WE ARE

ONTO
something

OF CHATS!

NEW UX

Once in a decade

paradigm shift

FEDERATION

No gatekeepers!

REINVENTING

THE WHEEL?

Why has no one done this before?

There have been several attempts including SIP, XMP, RCS.

All of these have had some level of success, but many different technological, usability, economic factors have ended up limiting their success.

Unfortunately, we've not ended up in a world where everyone has a SIP URI or Jabber ID on their business card or a phone that actually uses RCS.

IRC limitations

Text only
Fragmented identity model
Disruptive net-splits
No history
No multiple-device support
No presence support
No open federation
Non-standardised federation protocol
No built-in end-to-end encryption
Non-extensible
No standard APIs
just a rather limited TCP line protocol

XMPP is more of a message passing protocol

It still largely resembles a synchronous protocol with limited support for rich media, which can’t realistically be deployed on mobile devices.

But it is so extensible, why haven’t those extensions quickly brought it up to speed with the modern world? Sparse Adoption

Stuck in time

We got to HTTP version 1.1 in 1997, and have been stuck there until now. Likewise, SMTP, IRC, DNS, XMPP, are all similarly frozen in time circa the late 1990s.

Once you federate your protocol, it becomes very difficult to make changes

break to keep moving

It’s what Slack did with IRC, what Facebook did with email, and what WhatsApp has done with XMPP.

In each case, the federated service is stuck in time, while the centralized service is able to iterate into the modern world and beyond.

Here come the Matrix.org

Matrix can be thought of as an eventually consistent global JSON db with an HTTP API and pubsub semantics.

Matrix has a deliberately extensive 'kitchen sink' baseline of functionality.

I LIKE

The Architecture

Bridges

JSON Payloads

End-to-End encryption, with no decryption or reading performed on the server.

I DONT LIKE

Matrix user IDs (MXID) are unique user IDs.

Third-party IDs (3PIDs)
IDs from other systems or contexts, such as email addresses, social network accounts and phone numbers.

The TRUTH is

The whole area of XMPP vs Matrix vs Rocket.Chat is quite subjective. Rather than fighting over which open interoperable communication standard works the best, we should just collaborate and bridge everything together.

The more federation and interoperability the better.

So let's be friends

Service record (SRV )

A Service record (SRV record) is a specification of data in the Domain Name System defining the location, i.e. the hostname and port number, of servers for specified services.

# _service._proto.name.  TTL   class SRV priority weight port target.
_chat._tcp.example.com.  86400 IN  SRV 10  60  3000 chat.example.com.
_chat._tcp.example.com.  86400 IN  SRV 10  20  3000 chat1.example.com.