Cerulean: Experimental micro-blogging app for Matrix | Hacker News Reader

Cerulean: Experimental micro-blogging app for Matrix

matrix.org

206 pointsignoramous55 comments

This is very cool, although every additional use case for Matrix makes me wish there were ways to grant access to a subset of my account.

Worst case scenario logging into a Mastodon client is that it wrecks my microblogging data. Worst case scenario logging into a Matrix microblogging app is that it wrecks my microblogging data and drops my admin privileges on all of my Matrix chatrooms.

OAuth scope by room type, maybe? https://github.com/matrix-org/matrix-doc/pull/1840

We've had this idea for a really long time e.g https://github.com/matrix-org/matrix-doc/issues/531 and is something I would like to tinker with in Dendrite for sure. Typed rooms helps categorise but doesn't allow control over a subset of your account.

>Typed rooms helps categorise but doesn't allow control over a subset of your account.

Sure, but they could in the future, right? Couldn't a homeserver in theory generate a more restricted credential for which it would reject e.g. "PUT /rooms/<roomid>/send/..." requests after checking the room type?

None of the machinery around that exists now, but it feels like it could be done.

(FWIW, I did write MSC1840 with this use case in mind.)

Absolutely it could. In fact it would be an elegant way to handle grouping rooms together rather than specifying individual room IDs.

I'm really excited about using Matrix for more than instant messaging. This November I spent a week reading all the specs (which were really well documented!) and some spec proposals that I think are really important for non-IM clients (room types, event relations (replies), portable identities). I was able to get a simple web client up and running in ~300 lines of clojurescript.

Cerulean is looking great! Does it support e2e threads? I'm about to take a stab at implementing e2e in my application and I'm curious how much overhead it is.

Cerulean doesn't have E2EE yet because it deliberately doesn't use a Matrix SDK but just talks simple raw Matrix directly via HTTPS. However, it'd be easy to swap out for a real SDK like the one in https://github.com/vector-im/hydrogen-web to get E2EE (or pipe it via pantalaimon :)

I'd be excited to even start using Matrix for instant messaging. Elements seems pretty half-baked on my phone and I'd feel bad for convincing anyone to switch from Whatsapp to it.

I would agree, while the UI looks nice on first glance I think some UI concepts are way weird and it's over all overloaded.

On Android I quite like SchildiChat, which is a simple-at-first-look client.

We're constantly iterating on Element's UI, and the concepts are getting constantly de-weirded. For instance, one of the things many people complain about is that it's possible (and indeed easy) to end up with multiple DMs with the same person. So we're in the process of defaulting to "canonical DMs" (i.e. one DM for each pair of people). Others complain about the hassle of managing E2EE (verifying new logins; backing up your keys with recovery passphrases/keys, etc) - the Matrix equivalent of the Signal recovery PIN drama. We're going to be reworking that all (again) next year, too. So yeah, the UI isn't perfect, but hopefully we're working on it, and it should get better.

Meanwhile, the nice thing about Matrix is you can use whatever app you like - e.g. SchildiChat is a fork of Element Android, FluffyChat's good too, so use whatever floats your boat.

A big problem for me on any client is the scrollback. It sometimes gets stuck or takes longer than 15s to load the next portion. The only time I've been able to catch up with old pings was if I had the client open in the background.

using which server? matrix.org is pretty fast these days and scrollback should load instantly.

matrix.org / element. Seems to be more prevalent in larger rooms (#nixos GET /sync requests take 30s and time out)

What is the point of E2E-encryption in microblogging?

for private threads and DMs :)

But then couldn't one just use ordinary Matrix?

well, this /is/ ordinary Matrix - just with threading implemented! :)

dendrite.matrix.org is being slightly hugged to death by being on the front page of HN, but we're about to redeploy it with a fix. (All these guest accounts shouldn't be generating bcrypt passwords ;P)

Meanwhile, happy to answer any questions about the Cerulean mad science experiment :)

This is a really interesting use of the protocol and looks very cool, congratulations!

I am curious how this experiment fits with the longer term goals for the project. Do you see Matrix as a social media protocol in addition to chat? If so, do you have plans to integrate with the fediverse/speak ActivityPub?

Matrix is a generic realtime data sync protocol, so yes - we always built it with general social media uses in mind as well as chat (as well as VoIP, VR/AR, IoT etc). Hopefully someone will build an ActivityPub bridge now that Cerulean exists! :)

(more importantly, surely we need a HN bridge!)

We're having way too much fun live-profiling and optimising Dendrite thanks to the impromptu load test :D Sorry the server bounces a bit, but we're deploying stuff like https://github.com/matrix-org/dendrite/pull/1666

A week or so ago, you mentioned on HN [1] that Matrix is in a pretty good position to support a Discus-like comment section for personal blogs and articles.

I think something like Cerulean may even be a better idea. It would probably be straightforward to just make every blog post create a corresponding Cerulean/Matrix post and then have a link to it automatically inserted into the bottom of the post.

One question I have, though, is how performant it is to have thousands and thousands of these small Matrix rooms around. Are rooms that lightweight? One for each post seems like it could be a lot, but I'm not familiar with the intended internals for servers to use in how they represent rooms.

[1]: https://news.ycombinator.com/item?id=25336352

yup, rooms are lightweight - not much heavier than just sending a message. I suspect the only reason that people assume they are heavyweight is psychological because in real life rooms are... heavy :)

Totally agreed that turning Cerulean into a Disqus-clone would be awesome; hopefully someone will pick it up and do so!

> It has zero dependencies (other than React)

Well, if you’re gonna draw the line there... React alone and the tooling it requires already gives you about 1400 dependencies. That is not what people mean by “zero dependencies”, especially choosing the framework that is one of the worst offenders.

sigh the point is that the interesting bit is the Matrix client, and we are not cheating and using some preexisting Matrix SDK but doing it all raw so people can see how it works.

The web framework is irrelevant.

> React alone and the tooling it requires already gives you about 1400 dependencies

When you throw around FUD like this, can you please also give us some credible sources? You can use cdnjs to get react and react-dom in exactly 2 .js files.

  $ npm install https://github.com/matrix-org/cerulean
  [71 lines of logs]
  added 2371 packages from 808 contributors in 62.487s

Once built, the only frontend dependency is React. Most of those packages are tooling related to the build process.

> Most of those packages are tooling related to the build process.

So? jiofih's claim was about "React alone and the tooling".

heh, that’s because the dev dependencies (prettier and the test suite) have been accidentally added as runtime deps.

but seriously, the amount of deps react has is really not the point i was making on the blog post...

waves arms helplessly

> heh, that’s because the dev dependencies (prettier and the test suite) have been accidentally added as runtime deps.

fixed - thanks akx (and congrats on the first PR to cerulean :D)! https://github.com/matrix-org/cerulean/pull/30

see https://www.netlify.com/blog/2018/08/23/how-to-easily-visual...

That is visualizing source files _within_ a package, not cross-package dependencies.

Entirely different beasts.

Features like these make me wonder what the goal and direction of Matrix really is. I can see how this is a nifty demo of how the Matrix protocol can support many use cases, but the base use case (open communications) isn't nearly complete yet.

Element is the only application supporting all Matrix features, but it's look and feel are off, it's speed leave things to be desired and I'm still getting issues with fetching the right keys for a chatroom on some of my devices. The file picker on mobile is wonky, some very basic features (like adding a caption to an image you're sending) just don't work. I'm definitely not convincing anyone to consider this over the existing, isolated, closed-source messaging applications out there.

Then there's the fact that there's very little chat clients that support most of the protocol, especially with encryption. To combat this, you can run pantalaimon if you can ever get it to work (its dependency on things like dbus makes it very hard to run well on a VM or in a container) to add encryption to more well-integrated chat clients like Fractal.

I love the premise and the idea behind Matrix, but I do fear that the focus on expanding and experimenting will eventually prevent it from reaching the critical mass necessary to ever be used outside of the enthusiast circle. All the (optional?) additions to the protocol also make me fear that Matrix will end up dead like XMPP, with different features implemented across different applications all in a way that things just don't work well together.

Why put all of this work into running a daemon 24/7 on your phone that will end up sucking battery to run an app with bad usability in peer to peer mode? What's the end goal? I just want to rid myself of Whatsapp and Telegram, is that even a valid use case for the Matrix system anymore? Should I start looking in other directions?

The reason we occasionally do experiments on Matrix (VR, 3D video calling, low-bandwidth, P2P and Cerulean) is to try to remind folks of the broader use cases of Matrix beyond chat and to encourage contributions and experimentation from the wider community, so these ideas can evolve outside the core team. In the case of Cerulean, it's also as a test jig to test out threading in Matrix for use in Element and other clients.

Meanwhile, just because one person (kegsay) spent a few weeks putting together Cerulean doesn't mean that the other thousands of people in the Matrix ecosystem were idle. For instance, Fractal merged matrix-rust-sdk support 2 weeks ago, which implements full E2EE (https://gitlab.gnome.org/GNOME/fractal/-/merge_requests/626), so your complaints about pantalaimon should shortly be irrelevant. (Plus it seems pretty miserable to complain about pantalaimon's dependencies; the fact that the project exists at all as an E2EE stopgap is unusual - XMPP has no equivalent for instance, as far as I know). In terms of other clients supporting E2EE: weechat-matrix, Mirage, FluffyChat, Seaglass, Nheko, Gomuks, Daydream and more have support. Complaining that there are clients which don't have E2EE is like trying to denounce the Web because there are browsers out there which don't implement HTTPS.

Element Android still has work to be done, as you've pointed out, but it is growing rapidly (https://github.com/vector-im/element-android/graphs/contribu...) and if development continues at this rate you should see perf, encryption bugs (almost all caused by https://github.com/vector-im/element-android/issues/2518), and even the "wonky file picker" and "off look and feel" and "captioned images" fixed.

Ironically, Cerulean is the first Matrix client to implement captioned images (after a fashion), so your captioned images on Android might benefit directly from Cerulean's work there...

> Why put all of this work into running a daemon 24/7 on your phone that will end up sucking battery to run an app with bad usability in peer to peer mode? What's the end goal? I just want to rid myself of Whatsapp and Telegram, is that even a valid use case for the Matrix system anymore? Should I start looking in other directions?

XMPP isn't dead at all. OMEMO offers all the benefits of Signal's double-ratchet encryption and it's supported by at least one good client on every platform. Both ejabberd and Prosody are actively maintained servers, and there are still over a hundred XMPP hosts with open public registration. [And countless other hosts that aren't public.]

And it's way way way faster than Matrix. The servers are lightweight and don't require tens of GB of RAM, and the modern clients (like Dino and Conversations.im) are quick and snappy.

I wonder if the Matrix protocol can be extended to do realtime document collaboration. I’ve been yearning for end-to-end encrypted realtime collaboration solution via OT or CRDT, I just don’t really have the skills to do the encryption part on my own. The idea would be that the “room” is just a shared document, and the messages are the edits to the document.

People have tried doing document collaboration in a project called matrix-notepad. Though, I'm not sure how active it still is.

https://github.com/KB1RD/matrix-notepad

There's a whole community of folks on Matrix focused on experimenting with realtime document collaboration over Matrix - they hang out at #matrix-collaboration:kb1rd.net. It's pretty early days, but https://github.com/KB1RD/matrix-notepad is fun, and if coupled with some of the stuff that Martin Kleppmann & co are up to (https://arxiv.org/abs/1608.03960 etc) it could be super interesting :)

This forum is such a great technical resource, thank you.

Is Matrix/Riot/Element related to Cerulean Studios that built Trillian for Instant Messaging?

(Because I need to be a bit more confused!)

> Matrix is an open standard for interoperable, decentralised, real-time communication over IP.

> Element is a new type of messaging app. You choose where your messages are stored, putting you in control of your data. It gives you access to the Matrix open network, so you can talk to anyone.

> Cerulean Studios was officially founded in 2000, the same year Trillian started its long journey as an interoperable instant messaging client.

> Trillian[0] is modern and secure instant messaging.

> Cerulean: a highly experimental new microblogging app for Matrix

[0] https://trillian.im/

No connection. And Cerulean here is just a codename; we have no desire to use it seriously - it’s more likely the threading will get pulled into Element and other Matrix clients when baked.

(also, microblogging is sufficiently far from Trillian that we assumed nobody could get confused. there’s a lot of shades of cerulean out there.)

Awesome! Is it going to be possible to do Craigslist on Matrix? Does anyone see it? Is there going to be a way to index the blog posts and for some servers/participants to hold the index?

yeah :) the idea is to be able to use Matrix for moderated forums etc too - and perhaps we'll have payments in there one day too.

I was wondering, where would the indexes be stored? If I search "blog post about cats", where does it search the forum posts about cats?

Also, if payments can be done, that would be awesome, though it seems that is not something Matrix is trying to achieve?

search isn’t a solved problem yet. you could search your local server, or spider your neighbours, or build some kind of decentralised search engine. it’s the same problem for Matrix in general; we tend to cheat and just rely on Google to have indexed everything for now :)

Matrix is an exciting platform. I would love to see someone build a simple universal notification system on top of it.

We did the groundwork for this with the ultra-low-bandwidth Matrix stuff last year: https://matrix.org/blog/2019/03/12/breaking-the-100-bps-barr.... But frustratingly nobody has picked up that work yet.

How should I approach learning about the matrix protocol? The api is a simple json over rest, but that doesn't seem to reveal much about how eg conflict resolution strategies are defined and implemented or how to conceptualize the data model. Any pointers?

the spec covers more than just the client/server API. the server/server API covers the basis of how data is replicated, and conflict resolution is defined on a per room version as per https://matrix.org/docs/spec/rooms/v2. there are then guides like https://matrix.org/docs/guides/implementing-stateres which help expand on that and other areas to make it easier to conceptualise.

It reminds me of Diaspora* (https://diasporafoundation.org) and GNU Social (https://gnusocial.network) - both free and federated.

Movim tried this with xmpp as backend.

I am curious about the backend server of Matrix. Can it be scaled beyond 1 server? For example, by using Kafka or Nats?

Cerulean is backed by Dendrite, which scales horizontally via Kafka, but is in beta: https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta

Most other production deployments of Matrix are backed by Synapse, which is out of beta, and which scales horizontally via Redis: https://matrix.org/blog/2020/11/03/how-we-fixed-synapses-sca...

Im sorry but React is not zero deps.

Reply on news.ycombinator.com