
Ruma, a Matrix homeserver written in Rust - type0
https://www.ruma.io/
======
Perceptes
Author of Ruma here. I can answer any questions people have. Ruma is in very
early stages of development, if it's not clear from the website, so it can't
actually be used for its intended purpose yet, but we're getting there. :}

~~~
akerro
How does end-to-end encryption compares to tox? Tox uses TOXID - huge
hexadecimal numbers as encryption key and DHT to find peers. Once you connect
to a friend you know their IP, all messages, AV and file transfers are
encrypted. I find a lot of documentation about it is missing. Would like to
know which tox or matrix will be better for my next project. Tox also doesn't
expose any metadata.

~~~
Perceptes
End-to-end encryption is still in the draft phase in terms of the Matrix
specification—there hasn't yet been a published version of the spec that
includes it. Synapse, the reference homeserver implementation, and Vector, the
premiere web client, are still developing the implementation and will be
deploying it sometime soon, likely followed by a new version of the spec that
formalizes it.

The documents I know of that provide details about it are here:

* [https://matrix.org/jira/browse/SPEC-162](https://matrix.org/jira/browse/SPEC-162) (the tracking issue for the feature in Matrix's issue tracker)

* [https://matrix.org/git/olm](https://matrix.org/git/olm) (C implementation of the protocol formerly known as axolotl v2 developed for use in Matrix)

* [https://matrix.org/speculator/spec/drafts%2Fe2e/client_serve...](https://matrix.org/speculator/spec/drafts%2Fe2e/client_server/unstable.html#end-to-end-encryption) (draft of the spec for E2E)

~~~
akerro
Thanks, I will try to find some time and join your team and help with
development. I lost hopes in tox despite being much more mature than matrix.

~~~
zanny
Depends on your definition of mature. The security was mature, but the UX was
always garbage and there was never consensus in the ecosystem and huge swathes
of critical features (like usable dns) have never been wholly adopted.

Matrix is lacking its E2E encryption but already has everything else. You can
use Vector today to replace Hangouts or Skype completely.

------
ambrop7
Slightly off-topic, but, as far as Rust goes, I've completely given up on it
after realizing (after much study) that it is unsuitable for event-driven
(callback-based) design. In short, its idea of ownership, borrowing and
references is incompatible with "lower" objects knowing about their "parents"
and invoking callbacks to them.

I know there are ways to get around but I don't see any which is sufficiently
good for me (e.g. low boilerplate, scalable/composable, no compromise of
performance). Some details are in my question on StackOverflow[1].

One particular example that C and C++ allow is to have an object "self-
destruct" itself in a callback (e.g. after a TCP disconnect, EventLoop
callbacks Socket callbacks MyClient which directly destroys MyClient including
Socket). Yes it is indeed valid to call a (virtual) function on a class and
for that class to proceed to delete itself [2]. This is very nice because it
removes need to have special cleanup code all around and/or half-dead states.
In Rust, this seems impossible by design (i.e. would need unsafe, and it's
unclear if the compiler itself allows it anyway).

[1] [http://stackoverflow.com/questions/36952894/event-driven-
des...](http://stackoverflow.com/questions/36952894/event-driven-design-with-
callbacks-in-rust)

[2] [http://stackoverflow.com/questions/3150942/c-delete-
this](http://stackoverflow.com/questions/3150942/c-delete-this)

~~~
devit
That's inaccurate.

You can do what you describe as long as you use Rust's reference counting
support (Rc and Arc), which includes weak references that can be used for
parent pointers, plus RefCell and Mutex for mutation.

To have an object "self-destruct", have it remove all reference counted
pointers to itself.

You can pass an &Rc<Self> (or &Rc<RefCell<Self>> or &Arc<Mutex<Self>>) as the
self parameter if you want to let an object create references to itself. If
you want an object to be able to drop itself immediately in that case, use an
Rc<Self> instead of an &Rc<Self>, and call drop(self) in the method (this also
work if you are not using reference counting and just pass Self, of course).

You should try to not do this kind of thing though, because it adds overhead
and the compiler cannot statically check that you are not leaking reference
counted cycles or deadlocking on mutexes or refcells (which is not a Rust
limitation, it's just impossible without having the programmer write a
machine-checkable proof).

If you do it in C++ the compiler also cannot check whether you are referencing
freed memory or incorrectly concurrently modifying the same object.

~~~
oconnor663
I think Rc<RefCell<T>> falls into the "high boilerplate workarounds" category
that ambrop7 mentioned they were trying to avoid.

~~~
tree_of_item
Rc<RefCell<T>> is not high boilerplate at all, and it's a super common Rust
pattern. If you think this is too much boilerplate then I'm really not sure
what you were expecting. It's just composition of reference counting memory
management and mutability, a great example of modular design. What more did
you want?

~~~
ambrop7
Rc is dynamic memory allocation, which means every element of your application
will end up in its dynamic memory block. This is inefficient and highly
undesirable for resource-restricted / embedded applications.

~~~
tree_of_item
Right, you shouldn't reflexively use Rc everywhere. That seems like a
completely different topic, though: what I was responding to was the assertion
that composition of Rc and RefCell was "boilerplate".

------
annnnd
I haven't had a chance to work on a real-world problem with Rust (I mostly use
Python, but have started learning Rust for fun), so this is genuine curiosity
speaking: is this
([https://github.com/ruma/ruma/blob/master/src/main.rs#L60](https://github.com/ruma/ruma/blob/master/src/main.rs#L60))
idiomatic Rust? If I understand correctly, lines 63-76 are using chaining
because Rust doesn't support optional / named parameters? And lines 78 - 107
are basically just "run server if no error"? Seems like an awful lot of code
for what it does... Could it be make nicer or is such level of verbosity
something normal in Rust?

EDIT: again, not trying to put anybody down, I would just like to learn if
this code is representative of bigger Rust apps.

~~~
MHordecki
Is it that verbose, though? I have a hard time seeing how it could be made any
shorter in other languages, without sacrificing functionality.

EDIT: I think what gives the code its length here is the explicit error
handling. If you do the same in Python you'll end up with the same amount of
code. In Rust, you could unwrap() everything and lose nice error messages and
probably slash the LOC in half.

~~~
reissbaker
With the built-in error handling macro, you can generally do:

    
    
        let value = try!(fn_that_may_error());
    

Rather than having to muck around with explicit matching on Ok vs Err.

The try! macro would make the linked function much less verbose... Except that
what try! does is bubble the error further up the stack by returning an Err if
the called function returns an Err — and since this is the main function,
there's nowhere up the stack to go (main() has a return type of "Unit," which
is Rust's version of void or null; for functions that pass errors up the stack
you'd have a return type of Result<ReturnType, ErrorType>, which allows errors
to be returned), so try! can't work.

I agree that some of that error handling in 79-101 is pretty awkward looking,
but luckily it's not super representative of idiomatic Rust: usually you can
make Rust much more concise by using try!, with the exception of the main()
function which can't use try! and has to actually handle the error.

~~~
moosingin3space
I'd prefer to use `expect` in this case, or if I wanted to present a non-scary
error message, write a custom macro to print the error and exit.

------
Animats
That's nice, but is Matrix going anywhere? There are so many of these
federated social systems now (Diaspora, Urbit, Gnu Social etc.) with few
users. (And they don't interoperate with each other, which is a lack.)

Maybe we just need some federated system that's a directory only. All it does
is help you find people and resources, after which they speak end to end.

~~~
Arathorn
It's worth noting that Matrix is the only federated system which sets out from
the outset to bridge together all the others (hence the name Matrix). Whilst
we don't have bridges to diaspora/urbit/gnu social yet, it's only a matter of
time. PRs welcome!

In terms of the community size - looking at just the Matrix.org homeserver,
there are around 300K messages a day, 250K users (of which about 200K are
bridged), and 30K rooms. Meanwhile there are at least 500 openly federated
homeserver installations we can see from the Matrix.org homeserver.

Synapse is relatively mature as a homeserver (although it still has
performance challenges; it is very cool to see Ruma progressing!) - meanwhile
Vector as a flagship web/ios/android client is in late public beta and very
usable too - eapecially with end-to-end encryption on the horizon.

I may be biased (being project lead for Matrix), but I'd say that it's going
somewhere :)

~~~
raphman_
This sounds promising.

Is anyone already using Matrix as an event server/queue for interactive
environments and/or sensor networks (similar to the Stanford Event Heap [1])?

What is the minimum latency for Synapse/Ruma?

[1]
[https://graphics.stanford.edu/papers/eheap/](https://graphics.stanford.edu/papers/eheap/)

~~~
Arathorn
We've done some stuff with sensor networks - eg our FOSDEM 2015 demo was
hooking up cars via OBD2 ports to stream their engineering telemetry into
Matrix for visualisation/analytics etc:
[https://archive.fosdem.org/2015/schedule/event/deviot04/](https://archive.fosdem.org/2015/schedule/event/deviot04/)

However, this is still fairly PoC. Our latency is deliberately high at the
moment (given all events are persisted on all participating servers, and
signed etc) - typically around the 100-300ms mark depending on server
performance involved. If you want lower latency stuff (eg VoIP or MIDI) the
architecture is that you use Matrix to be a signalling layer to negotiate the
realtime protocol (eg RTP).

------
chjohasbrouck
Would you say the Matrix specification is intended to compete more with
messaging (Slack, Skype, etc), email, or both? What do you think people would
use this for, and what's the value proposition?

~~~
Arathorn
Matrix itself is a fairly flexible building block for decentralised
communication of any kind where you care about decentralising the conversation
history. You can use it for messaging, VoIP, IoT data - and once threading
lands it'll be good for email and forums too.

Right now most of the clients are geared up for the messaging and VoIP use
cases.

The value prop is to provide a meta-network which connects together all the
existing communication silos, so users can talk to folks on other platforms
(eg Slack, IRC) without caring what service or client they are using. Ideally
someone on Slack could end up talking to someone on IRC, bridged via a
decentralised Matrix room, without even realising they are using Matrix.
Alternatively you could use a native Matrix client like Vector.im or the
Matrix API to get at the data. The key thing is that no single silo ends up
owning or controlling the data - it is replicated over all the participants,
who thus own the conversation equally.

The end goal is to let users select which communication apps and services they
want to trust with their data (including running their own, if they so
desire), rather than the communication and contacts being fragmented over
hundreds of different apps.

~~~
Natanael_L
On forums, here's how I'd like to have it work:

[https://roamingaroundatrandom.wordpress.com/2014/06/01/a-dec...](https://roamingaroundatrandom.wordpress.com/2014/06/01/a-decentralized-
hash-chained-discussion-system/)

It isn't very technically detailed, but it should be clear enough. Your system
sounds like a good match for what I imagine. The TL;DR: The messages are in
focus, not the servers. Content-addressing using hashes, threads managed
through messages referencing prior messages directly by their hashes. When
creating forums, servers are just (optionally) defined to simplify routing /
delivery.

One could build discussion servers on top of the matrix home server, and
discussion clients to match.

~~~
Arathorn
Heh, this is awesome and pretty much precisely what we have in mind with
Matrix. All that is missing is threading and editable message support, which
we are working on shortly. Help would be very very much appreciated,
especially in building bridges to forums!!

------
netforay
Looking for Matrix vs Jabber. Is there any comparison document?

Also I was just trying to implement our own Telegram Server to take advantage
of Free Telegram Clients available.

Can anyone compare Telegram with Matrix. (Except the Federated part).

~~~
Perceptes
Jabber (XMPP) has two fundamental differences from Matrix, as I see it: XMPP
is a spec for a system for exchanging messages. It has very small, granular
"extensions," most of which are optional. Matrix is a spec for a system that
stores arbitrary data ("events") and a way to synchronize and resolve conflict
across federated servers. It doesn't have extension specifications like XMPP
does, and includes a much more complete set of features in its core, to ensure
that all client implementations have compatible features. This is a problem in
XMPP, where many features can't be used effectively because the servers cannot
assume that all clients understand many of the extensions.

More detail in Matrix's FAQ: [https://matrix.org/docs/guides/faq.html#what-is-
the-differen...](https://matrix.org/docs/guides/faq.html#what-is-the-
difference-between-matrix-and-xmpp)

~~~
zanny
Also, it uses HTTP + Json rather than TCP + XML. Which is an instant win.

~~~
viraptor
XMPP doesn't have to use raw TCP. BOSH exists for years:
[https://xmpp.org/extensions/xep-0124.html](https://xmpp.org/extensions/xep-0124.html)

------
Mandatum
Nice little project, really clean code - super easy to understand after
reading some of the Matrix spec.

------
partycoder
how does matrix compare to the wave protocol

~~~
Arathorn
They are related to some extent. The big differences were that Wave was built
on XMPP, driven largely by and for Google, and put higher emphasis on
collaborative editing and threading and less on bridging. Matrix is non-profit
opensource and focuses on defragmentation and bridging from the outset. Matrix
also provides many more clients than were ever available for the Wave
protocol, some of which have subjectively better UX.

If Wave had bridged with protocols like email or IM, provided a clearer UX for
newbies, and nurtured an open community and network rather than focusing
primarily on Google's use cases, Matrix probably wouldn't be needed today.

------
ckok
So how usable is this atm? Can it be used with vector yet to setup a fully
working homeserver?

~~~
Perceptes
No. It's in very, very early stages of development and is not usable for its
stated purpose yet. All the attention on HN is appreciated but unfortunately
premature in terms of being able to promote it as a working program.

------
axonic
Awesome! I was selecting a Matrix implementation but not anymore I think.
Thank you.

------
tambourine_man
Matrix (the protocol) seems very interesting, I wasn't aware of it.

------
kovrik
What is `Matrix homeserver'?

~~~
DiabloD3
Literally the first paragraph answers this.

~~~
ahazred8ta
Oui. "Matrix is an open specification for an online communication protocol. It
includes all the features you'd expect from a modern chat platform"

~~~
CMCDragonkai
But what is a "homeserver"?

~~~
Perceptes
For a lot more detail, including a better explanation of homeservers, take a
look at the Introduction to Matrix guide in the documentation:
[https://www.ruma.io/docs/matrix/](https://www.ruma.io/docs/matrix/)

------
kiba
Somehow, I was expecting a virtual world simulator before opening up the link.

------
aphextron
Relevant XKCD:
[https://imgs.xkcd.com/comics/standards.png](https://imgs.xkcd.com/comics/standards.png)

Neat project though.

~~~
Perceptes
I didn't downvote your comment, but I do want to provide a response for anyone
else reading:

This comic gets linked quite a lot when discussing new systems, and I and many
others see it as a fairly low-effort jab. I'd venture a guess that anyone
reading HN has seen this comic before, and the creators of systems like Matrix
are certainly not oblivious to it as common criticism.

While there is danger of becoming yet another variation that doesn't "win" or
solve problems in a meaningful way, the folks developing systems like Matrix
think they can do more to help by approaching these problems in a new way than
they can by throwing up their hands and living with the problems, and I think
that effort deserves respect.

It'd be more constructive to do some reading about the protocol, become more
familiar with it, and share more specific criticisms that concern you than to
drop a link to the comic everyone has seen before.

~~~
_pmf_
The problem is that Matrix is positioned right in the middle of the train
wreck of unfulfilled promises left behind by Google Wave, XMPP and (for those
of enough to remember it) Chandler[0].

It's something that a lot of people (including myself) really, really want to
succeed, but all previous trials failed (even when only E-mail was around; now
we have the data silos by Twitter and Facebook that are additional obstacles).

Even after almost a decade, the well is still poisoned for everyone from
Google's botched Wave rollout; if even Google (with the tremendous leverage of
Gmail) was unable to pivot communication is this direction, who will?

[0]
[https://en.wikipedia.org/wiki/Chandler_(software)](https://en.wikipedia.org/wiki/Chandler_\(software\))

~~~
Perceptes
I definitely understand the skepticism. If you search my HN comment history,
you'll even find me saying that I'm skeptical that Matrix will achieve
widespread success, too. But I still think the way to overcome that is to keep
trying. The main edge that Matrix has over previous systems like Google Wave
and XMPP is that it's been designed from the start to be bridged to other
systems, rather than trying to fight them for mindshare. This means that
Matrix can grow and be useful even if people don't "switch" from their
existing systems to Matrix. That aspect of Matrix does make me hopeful and
optimistic about its future.

~~~
1wd
Wasn't that exactly the idea of XMPP as well? (e.g. gateways to ICQ etc.)

[https://en.wikipedia.org/wiki/XMPP#Connecting_to_other_proto...](https://en.wikipedia.org/wiki/XMPP#Connecting_to_other_protocols)

~~~
qwertyuiop924
Yeah, but XMPP never really did that. It just had the potential.

In the same way, yes, you CAN link IRC to Slack and XMPP, but how many people
have?

~~~
cxk
Then me using ICQ and MSN transports with XMPP 10 years ago was just a fantasy
and all the transports installable for ejabberd do not exist ? It's all just
potential ?

