The Matrix Space Beta(matrix.org) |
The Matrix Space Beta(matrix.org) |
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.
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.
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.
- 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.
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.
> 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.
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.
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.
To me it shows the snowballing effect of features.
Also, Matrix's Spaces (even in Beta) seem more flexible and thought out than the second best implementation I know, in Slack.
Are you adding the each blog post comment room to a private space manually or is there way to automatically add it to that space?
For everyone who just glanced through the comment above, this is big and a major selling point compared to most competitors (IMO).
The Element blog post talks about setting up admin spaces and community spaces. So if rooms aren't exclusive to a single space I could build custom, private spaces that pull rooms from multiple different communities I'm a part of.
That's a really cool feature that Discord doesn't have right now.
Then there are what you might call "canonical" spaces, where space A labels space B as its child, and B labels A as its parent. Then you know that the relationship between the two is mutual, and clients can take that into account.
But you're free to create your own Spaces that are the parents of other rooms, where those rooms/spaces are unaware of the Space you created.
Spaces seem conceptually different from rooms.
That said, it’s subjective, and we went back and forth on it. My original proposal had a twigil of #+wherever:example.com, which in retrospect was daft. I think it was a member of the community who proposed just using plain # aliases - hard to tell given https://github.com/matrix-org/matrix-doc/pull/1772 is so heavily commented that it crashes if you expand the comments :/
https://github.com/matrix-org/matrix-doc/pull/1772#discussio...
What do you mean by 'smart widgets based on url'?
I've used the bots api for slack and discord in a corporate environment. Compared to that the matrix api is horribly behind and unreliable.
We already have a universal notation for identifying resources on the Web. Why not use that?
Edit: Just read Arathorn's comment above, very cool - I hadn't seen that one before.
That's what kept me from switching last time; to me a federation client that's going to phone home to a central server is no better from a privacy standpoint than using Signal (which isn't federated but is also end to end encrypted and phones home to its centralized server), and Signal's UX is better thus far.
If that can get solved (and it seems like it can), Matrix looks like it's going to be super awesome.
There's no centralized server. There's a server with the majority of users for now (in matrix.org), but the network is decentralized, with many servers. The server implementation run by the majority is called Synapse, but there are others (Dentrite, Conduit, Construct..).
I'm puzzled by this comment. Can you elaborate on what you mean by phoning home?
Are you talking about https://element.io, which points to matrix.org homeserver and signing server, etc?
In that case, well, just use a different server and your own client. Or self-host, and select one of many clients: https://matrix.org/clients/. That's the whole point of federation.
You can even deploy your own web client pointing to whichever server default you want, many people do. E.g: element.debian.social, chat.mozilla.org, etc.
On first launch, it connects to multiple centralized servers before you have a chance to select your homeserver.
The issue was with the default client, in the default config.
Not sure if it's still happening, but it was concerning enough that it happened in the first place.
https://github.com/vector-im/element-web/issues/13942
https://github.com/vector-im/element-web/issues/12712
https://github.com/vector-im/element-web/issues/11655
https://github.com/vector-im/element-web/issues/11655#issuec...
It would also appear that it intends to maintain a Solarwinds-style remote code execution vulnerability on the machine on which it is installed:
https://github.com/vector-im/element-web/issues/11655#issuec...
Not sure what problems you're seeing with the Matrix API; it's lightyears ahead of Slack & Discord in my experience, but I guess i may be getting high on my own supply...
Maybe in Matrix the hierarchy would be implemented by nested spaces? A space for the stream and one for each topic? That would probably work if not for the critical Zulip feature of being able to move messages between topics (and between streams?) to better organize the conversation.
Maybe one Zulip instance is a giant Matrix room and the threading model that's landing soon is used to implement the relationships? I know the upcoming threading model can dynamically change event relationships. But then maybe it would be better to avoid giving single rooms that much traffic.
There are probably lots of ways to implement that functionality. I'm curious as to what you were thinking.
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.
PCs are no longer the right device for "mom and dad".
Kudos to you and the team and I've been really enjoying tracking your progress over the last ~4 years.
The comment you're linking to says that there are no current plans to change the default request to matrix.org from the login page, and that you explicitly plan to keep the current auto-updating behavior.
(also, of course "we will fix that" implies that it is currently still broken, which is what the original commenter was pointing out)
> we're going to fix this, and yes, imo, autoupdates need an opt-in.
i'm not sure how clearer i can be.
We don’t think the model for Spaces is overcomplicated. In fact it’s simpler than Discord (no role-based permissions; just power levels).
Why is this the preferred model?
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.
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
Disclaimer: one of my friend is involved in this project
However, actually competing with Discord will require a tonne of hard work in Element. The little things like automatic voice activation, echo cancellation and volume normalization are the reasons Discord are as fantastic as it is, so Element will need to be excellent with those to compete.
Also, if you move on for reasons that aren't bike-shedding then I'd love to know what the architectural/technical reasoning is.
Voice activation is a client side thing.
Feels like a needed step for community-building after having used Discord for so long. You are doing awesome work.
Many thanks for the work you do!
> As should be pretty clear from #11655 (comment), we're going to fix this, and yes, imo, autoupdates need an opt-in.
The comment #11655 says:
> Auto-updating for default Riot distributions will continue as before to ensure security fixes are delivered quickly
So at this point already it becomes unclear to the reader which of these has precedence.
So, assuming you're asking in good faith, if you wanted to be clearer you should have written something like:
"*Despite* what's written #11655 (comment), I disagree with the product teams assessment and think autoupdates need an opt-in, therefore I will make sure this is implemented."
(not sure if the content is 100% what you wanted to express in the comment, but you get the idea)