[Arathorn]

For what it’s worth, the thing I find most exciting about Spaces is that they provide a decentralised hierarchical namespace with decentralised access controls for every room (ie pubsub topic) in Matrix. So it’s like we’ve sprouted an openly federated global hierarchical filing system for freeform realtime data streams of all flavours - where people can go crazy defining their own trees, applying their own curation ideals; perhaps we’ll even see a single global tree emerge (although the implementation may need some more optimisation first).

It’s like a multiplayer hybrid of DMOZ and USENET and the read/write Web all rolled together. Once we start storing more interesting data streams than instant messages in it (eg forums, email, bulletin boards, DOMs, scene graphs, ticker data, IOT sensor data...) it really gets interesting :)

Plus you can use it to organise your own rooms and have Discord style communities or Slack style workspaces, but that’s the boring obvious bit ;)

Edit: for a user-facing rather than developer-facing overview, https://element.io/blog/spaces-the-next-frontier/ has more details.

[ldarby]

I wish Matrix would instead focus on fixing all the existing encryption usability issues instead of these new features:

https://github.com/vector-im/element-web/issues?q=label%3AA-...

I would love to migrate my family to Element (and also friends, and eventually also recommend it to employers if they're ever choosing something other than Teams) but can't until it's reliable as webmail. I also wrote this comment:

https://news.ycombinator.com/item?id=25271512 "Once Element is mature enough (and I'm sorry, but looking at the incoming issues on https://github.com/vector-im/element-web/issues?q=sort%3Aupd..., it doesn't look like it yet), then hopefully more companies will start considering it."

I get that E2E means it cannot be as simple as email, and I can handle the extra training that's needed, but not for figuring out all these known issues and attempting to prevent people hitting them, or having to handle the situation if they do.

[Arathorn]

So there is a finite number of active contributors to Element, and we have to prioritise what to work on. While E2EE is not perfect (the UX needs another major iteration and we are still hunting rare edge cases where messages cannot be decrypted) in practice it's usable day to day.

We consciously chose to prioritise building out Spaces over the last few months over E2EE UX as otherwise there's a risk of Discord becoming the de-facto home for open source projects, much as Slack started to be a few years ago - which would be catastrophic for open standards-based communication like Matrix.

Meanwhile, the cryptography team chose to focus primarily on implementing next-generation encryption (IETF's MLS) on Matrix rather than polishing the current behaviour - given MLS should both radically improve scalability, but also fix the majority of the edge conditions which are problematic for today's E2EE, or at least entirely switch bugs in the existing implementation for entirely different failure modes in the new implementation. We showed off MLS over Matrix last week (https://youtu.be/xn0fzyimycs?t=248), and we're now finishing the decentralisation component of it (https://matrix.uhoreg.ca/mls/ordering.html).

Eitherway, now that the Spaces beta is out the door, we're catching up on other UX issues, including E2EE. We also have more folks being paid fulltime by Element to work on encryption (amongst other stuff) starting in July. Talking of which, if anyone wants to get paid to make this happen sooner, Element is hiring at https://apply.workable.com/elementio.

[ldarby]

Thanks for the response, that sounds good and makes sense, I guess I'll continue waiting...

My family regularly does things like forget which browser they last used, or re-install windows, or otherwise mysteriously have all browser settings disappear, etc - all things that seem to be related to those key-backup issues.

[atatatat]

Put it on their phone or tablet.

PCs are no longer the right device for "mom and dad".

[natural219]

I'll just say; both of these seem like buckets of good priorities. I too wish some aspects of the onboarding were simpler, but I also am very very excited about Spaces, and have a number of communities I'm stoked to onboard once that feature launches.

Kudos to you and the team and I've been really enjoying tracking your progress over the last ~4 years.

[viccuad]

Enabling by default:

- cross-signing (so users verify their own devices themselves, and you verify users only once by verifying their public key, regardless of how many times they add or update devices)

- and key backup (so moving between devices doesn't need manual polling for other devices' keys the first time for decrypting messages)

would be a great step forward. Those are there, but they are disabled by default yet, which is a disservice.

[Arathorn]

cross-signing & key backup are enabled by default, and have been for a year or so? you have to explicitly opt out by repeatedly hitting the 'skip' button. however, the UX is certainly more complicated than it should be, and we're due to rework it in the coming months.

[viccuad]

Woops. I may be dealing with friends & family that joined prior to that. I wonder if one could get prompted again for enabling cross-signing & backup once you open a new client (I don't think it happens right now). That would help migrating everyone to enabling it.

[NoGravitas]

I'd love to see those encryption usability issues fixed, but I do want to say that e2ee on Matrix is less bad than on anything comparable (like OMEMO on XMPP). I like XMPP because of its speed, but you really can't combine OMEMO and multi-device unless you just don't mind having parts of your message history unreadable on some devices. The key backup and session validation in Matrix/Element usually solves this issue.

Unfortunately, the complexity means that even other Matrix clients that support e2ee don't support key backup and session validation, which means you either stick to Element on every platform, or live with the same history issues as on XMPP.

[archseer]

The iOS client is miles behind their Android client too.

> On iOS, we're still busy implementing Spaces. However if you join rooms which belong to Spaces, you’ll still be able to talk in them.

[anticensor]

E2EE is opt-in per-room.

[ldarby]

The entire point of Matrix is that it has E2E. If E2E isn't a requirement then my prefered communication tool is email.

[nerdponx]

> Discord style communities

Boring and obvious, but this is probably what most people would want. Now that we've seen how good and usable the Discord model is, it's pretty much the baseline now for public chat rooms.

[spicybright]

It sucks there's no open source project that mimics discord well.

They all shoot themselves in the foot by over complicating the model. It confuses users, and makes creating stable clients hard.

I don't want a tool-box of primitives and a recipe book. I want a decentralized discord clone not owned by a giant company.

Let's start there and add the crazy stuff later.

[Arathorn]

To build an open source decentralised Discord alternative you need a tool-box of primitives - that’s what Matrix is. Then clients like Element (https://element.io) sit on top to fill in the rest.

We don’t think the model for Spaces is overcomplicated. In fact it’s simpler than Discord (no role-based permissions; just power levels).

[babelfish]

Is there any documentation detailing power levels, or that decision was made to only offer power levels but not role-based permissions? FWIW, the reason most major platforms offer role-based permissions is because enterprises demand it, and it’s become the de facto primitive for authorization. User type based permissions also make sense, but are often used in conjunction with (not in lieu of) roles.

[dieortin]

https://matrix.org/docs/guides/moderation#power-levels

[xyzzy_plugh]

Power levels feels like the most IRC answer possible, and breaks down as soon you want mutually exclusive abilities.

Why is this the preferred model?

[Arathorn]

Because the decentralised ACL implementation (state resolution) relies on power levels as a simple comparator for determining merge conflict resolution. State resolution is the academically novel bit of Matrix and hard to get right, and while we can swap it out for role based ACLs in future, this is orthogonal to Spaces. Meanwhile it honestly hasn’t come up as a requirement, even from enterprisey folks, given we push power levels as hard as possible.

https://matrix.org/docs/guides/implementing-stateres and https://matrix.org/blog/2020/06/16/matrix-decomposition-an-i... give more info on how state res works and why you wouldn’t rush to jump to role based ACLs.

It’s nothing whatsoever to do with IRC or chanserv style behaviour, beyond coincidence.

[Arathorn]

I should also add that there are at least two matrix spec change proposals flying around to add role based ACLs, and one of the main reasons for switching spaces to be built on rooms is that they will automatically inherit the ACL model when it lands :)

[StavrosK]

Great response, thanks!

[cassonmars]

It’s funny you mention that — I just started such a project (three hosting modes: centralized, federated, fully decentralized) as an educational series to teach software development on multiple levels. It’s very early (read: non functional), and I’m still figuring out the best way to teach and build simultaneously, but constant weekly progress is being made.

Educational site (I’m backporting the previous sessions to the site, session 7 is the first one hosted right now): https://www.codewolfpack.com

Project repo: https://www.github.com/HowlerChat/Howler

[ognarb]

There is an attempt named harmony with multiple clients. https://github.com/harmony-development

Disclaimer: one of my friend is involved in this project

[Arathorn]

yup, and to be clear, that’s why we built Spaces. doesn’t stop the “wow we accidentally created the realtime read/write web” thing being cool tho ;P