Live data from Hacker News

Spaces launch in Element

element.io

101–110 of 129 posts

Re: Spaces launch in Element

#101
Are there any plans to add granting permissions to roles based on space membership (perhaps spaces which are not room's ancestors in any hierarchy but instead a cousin) instead of gradual power levels? And also sharing those permissions across all rooms in a space?

Re: Spaces launch in Element

#102

A week ago, I noticed that Element Desktop was starting to hide "rooms in spaces" from my home screen, which now only contains rooms not in a space. I really don't like how Element Android has you separately pick which space to view (in the sidebar), and whether to look at DMs or rooms (in the bottom bar). Now I often end up picking the KDE space, but only showing DMs, which results in an empty view (because I've onl…

> I really don't like how Element Android has you separately pick which space to view (in the sidebar), and whether to look at DMs or rooms (in the bottom bar). Now I often end up picking the KDE space, but only showing DMs, which results in an empty view (because I've only joined KDE-related chats, not KDE-related DMs).

Yes, switching between a DM in one space and a room in another takes at least one tap too many. Hopefully this paragraph in the article expresses the intention to work on this:

> Clearer interfaces: To make Spaces, Rooms, People, Direct Messages, Favourites and your conversation history easy to find over time, every time.

Re: Spaces launch in Element

#103
post #98

Earlier quoted context omitted.

In this case, the parent spec change for Spaces was MSC1772: Matrix spaces ( https://github.com/matrix-org/matrix-doc/pull/1772 ). You may also want to look into MSC2946: Spaces Summary ( https://github.com/matrix-org/matrix-doc/pull/2946 ) and MSC3083: Restricting room membership based on membership in other rooms ( https://github.com/matrix-org/matrix-doc/pull/3083 ). These will manifest in a published version of t…

I'm really frustrated that: a) Stuff like this gets released in the wild without being part of the spec making it effectively impossible for any non-element client to support at release time b) Any room that gets added to a server that supports spaces is no longer accessible to anyone whose homeserver isn't running the non-spec-compliant protocol from an unreleased version of synapse, because the default room version…

a) Agreed; the fact that spaces aren't in the spec is annoying when trying to stay spec-compliant and not realizing you also have to search through various GitHub issues to be fully informed. Granted, spaces have been one of the most hotly-discussed topic in Matrix development for months, so anyone interested in making anything Matrix related likely would have come across it.

b) Not true; spaces don't require room version 9. IIRC the only space-related feature that needs a room upgrade is "restricted rooms", ie. the ability to make a room accessible only to members of another room/space.

Re: Spaces launch in Element

#104
post #89

Earlier quoted context omitted.

You still need to go through the whole process of creating a Space even if it's just some place in a chat that you want open while you're having a conversation in another chat. You still have to use the same window to switch between them. These are not tabs.

If i read things properly, the spaces concept is not specific to the Element client (available per the underlying matrix protocol)...so technically, any other client could in fact apply a different UI/UX approach to displaying the spaces, such as tabs...again, if i'm understanding things accurately. So, maybe other clients could implement something more to your liking (such as tabs)??

This will still create a separate space that will appear in our clients, that needs the privacy settings etc.

Re: Spaces launch in Element

#105
post #98

Earlier quoted context omitted.

In this case, the parent spec change for Spaces was MSC1772: Matrix spaces ( https://github.com/matrix-org/matrix-doc/pull/1772 ). You may also want to look into MSC2946: Spaces Summary ( https://github.com/matrix-org/matrix-doc/pull/2946 ) and MSC3083: Restricting room membership based on membership in other rooms ( https://github.com/matrix-org/matrix-doc/pull/3083 ). These will manifest in a published version of t…

I'm really frustrated that: a) Stuff like this gets released in the wild without being part of the spec making it effectively impossible for any non-element client to support at release time b) Any room that gets added to a server that supports spaces is no longer accessible to anyone whose homeserver isn't running the non-spec-compliant protocol from an unreleased version of synapse, because the default room version…

> effectively impossible for any non-element client to support at release time

While I understand where you're coming from, it's just not the case in this instance:

Cinny, a one-man project, landed support for Spaces several weeks ago. FluffyChat, which wrote its own complete Matrix SDK in-house, supports Spaces. Nheko, which also rolled its own stack of client libraries, supports Spaces.

If your client of choice does not support Spaces, it very likely will soon.

> Any room that gets added to a server that supports spaces is no longer accessible to anyone whose homeserver isn't running the non-spec-compliant protocol from an unreleased version of synapse, because the default room version is 9 and synapse's latest release doesn't know wtf that means

I believe you're unfortunately mistaken on a few points here. We really did put a lot of care and consideration into how we rolled this out, and I'm sorry that we've somehow failed you. In particular:

1. "the non-spec-compliant protocol": Spaces followed the normal, public process for spec change proposals documented at https://spec.matrix.org/unstable/proposals/. The related MSCs have merged, and thus Spaces have been accepted as part of the Matrix Spec. They've not yet been incorporated into a versioned release of the Spec, but the MSCs are there, enumerated, and ready for implementation.

2. "an unreleased version of synapse": Actually, the past eight releases of Synapse have supported Spaces by default.

3. "the default room version is 9": The default room version is still 6, which is universally supported across the publicly visible federation as seen from matrix.org. Room version 9 is only used when a client explicitly requests the creation of a "restricted" room (a room which is private, but joinable by members of a given space).

4. "synapse's latest release doesn't know wtf that means": The past two releases of Synapse understand version 9 rooms, and only the latest release instructs clients that they should use version 9 when creating restricted rooms. We monitored the upgrade rates of servers publicly visible to matrix.org to ensure that the majority the population was on a version of Synapse which supported Room Version 9 before we cut a Synapse release which informed clients that they were allowed to create v9 rooms.

But v9 rooms are a red herring: Spaces can contain rooms of any version, and clients still default to creating v6 rooms except when explicitly asked to create a "restricted" room. It's simply not the case that a room getting "added to a server that supports spaces" means it's "no longer accessible" to anyone. Adding a room to a Space does not change the room's version, or any state within it. Rooms are only upgraded to v9 through direct, intentional action on the part of the room's owner to switch the room to a "restricted" access model. At which point, yes, your homeserver needs to understand that, which current Synapse releases do.

Re: Spaces launch in Element

#106

A week ago, I noticed that Element Desktop was starting to hide "rooms in spaces" from my home screen, which now only contains rooms not in a space. I really don't like how Element Android has you separately pick which space to view (in the sidebar), and whether to look at DMs or rooms (in the bottom bar). Now I often end up picking the KDE space, but only showing DMs, which results in an empty view (because I've onl…

> Element Desktop was starting to hide "rooms in spaces" from my home screen, which now only contains rooms not in a space.

To change this behavior, enable "Show all rooms in Home" under Settings > Appearance

Re: Spaces launch in Element

#107

A week ago, I noticed that Element Desktop was starting to hide "rooms in spaces" from my home screen, which now only contains rooms not in a space. I really don't like how Element Android has you separately pick which space to view (in the sidebar), and whether to look at DMs or rooms (in the bottom bar). Now I often end up picking the KDE space, but only showing DMs, which results in an empty view (because I've onl…

Great suggestions - thanks.

The information architecture of Spaces as presented in Element isn't perfect, and is at the top of the list of improvements we'd like to make as we iterate on the feature.

Releasing out of beta doesn't mean we intend to stop iterating on Spaces - it simply means we think the feature brings enough value to share it with everyone and open it up to the whole user base for feedback.

Re: Spaces launch in Element

#108
post #98

Earlier quoted context omitted.

I'm really frustrated that: a) Stuff like this gets released in the wild without being part of the spec making it effectively impossible for any non-element client to support at release time b) Any room that gets added to a server that supports spaces is no longer accessible to anyone whose homeserver isn't running the non-spec-compliant protocol from an unreleased version of synapse, because the default room version…

> effectively impossible for any non-element client to support at release time While I understand where you're coming from, it's just not the case in this instance: Cinny, a one-man project, landed support for Spaces several weeks ago. FluffyChat, which wrote its own complete Matrix SDK in-house, supports Spaces. Nheko, which also rolled its own stack of client libraries, supports Spaces. If your client of choice doe…

Moreover, the Matrix spec process requires that you have proven that a proposal actually works in the wild before it’s merged into the spec. This is a feature, not a bug. Just like browser vendors demonstrate a feature behind a prefix before it makes it into HTML, so do we with Matrix… to avoid a situation where the spec contains vaporware or spec for the sake of spec.
Post reply on HN