Shipping the Element Desktop Snap in official Ubuntu flavors?

Project Discussion
, ,
21

To be fair, using Freeshow as an example, I publish those branches myself.

22

Is that true? Mozilla has ownership of the Firefox Snap, doesn’t it?

23

Yes, but that’s a unique cooperation between Mozilla and Canonical. A similar arrangement would have to be made with Element, but they are more likely to want Canonical to pay for it.

2 Likes
24

I don’t think that’s true? Mozilla maintains the Firefox Snap, do they not?

25

Yes, they do, but it’s a cooperative. Same with the Thunderbird snap, though that’s the Thunderbird Foundation in conjunction with Canonical.

The Firefox cooperative was probably established before you came along with Mozilla requesting that Canonical stop publishing the .deb and distribute Firefox via the snap to make maintenance easier as part of the distribution agreement. However, to do so, several things had to be done so that both could cooperate, kindof like a joint venture.

While the publisher name is Mozilla which is where bugs ultimately go, the Firefox team in Canonical does have access for app distribution purposes. At least, that’s how I understand it.

1 Like
26

Good point. Anyway, I don’t really care how it happens, I’d just love to see it happen :slight_smile:

3 Likes
27

From what I can tell, “stalled” probably isn’t the right word, exactly. Looking upstream, there’s an issue for this topic with a lot of positive feelings about Snaps in general but it all ends with them essentially saying they have no one to do the work. I see that you replied there before, so was that the conversation you’re referring to?

In the meantime, I have a question that is unanswered by the Snap metadata: where does one file a bug against this particular Snap? Knowing where to file bugs on Snaps is a really confusing thing anyways, but there are no hints on this one. I assume that would be on GitHub but I’m not sure. Could you update the metadata accordingly?

28

You know, since got involved in this conversation, I thought it wise to install Element Desktop. Regardless of whether or not I’m using the upstream deb or the Ken’s Snap, that thing is a real resource hog. It seems to be rather consistently using more resources than Firefox, which in my mind, is saying something. Perhaps suggesting Element Web is actually a better idea. Is anyone else having this experience or is it just me?

29

You’re correct, it uses quite a few CPU cycles. That said, element-desktop is merely electron, which means it’s just running a self-contained Chromium-based web browser at its core. It’s the equivalent of having Chromium up and running Element Web, since it’s using the exact same code.

In that respect, Firefox running Element Web might be more of a resource hog if it’s kept in a tab all of the time.

30

Seems to be the exact opposite to me. Now if I was only running Chromium that might be different.

31

I’m concerned we’re starting at the wrong end. Usually when identifying solutions to problems, we start with describing the problem space, and then evaluate all the options.

It feels like we’re starting with the solution “Ship Element”, and going backwards from there.

Maybe I’m mistaken, and a full evaluation of all the available clients was made, and Element was chosen?

Given the lack of resource/motivation on the upstream Matrix/Element team, should we widen the scope to look at other options? Just by way of example, there at least one another client on the list which is published (as a snap) by the upstream, and (from my experience) is less heavyweight than Element.

Maybe we could start with documenting the criteria we want to satisfy, and find the applications which fit the criteria?

As posted by @jbicha earlier, the policy, do any clients meet these?

Nice to have:

  • Is performant on a moderate spec computer
  • Integrates nicely on all flavour desktops

Did I miss anything? Are there any apps which meet, or are close to meeting these?

2 Likes
32

Not exactly. We’re starting with the policy of “Element first” and going forwards from there. This policy is currently codified in Getting Started with Matrix | Ubuntu which states explicitly:

First, you need a “Client” app in order to connect to Matrix. Although there are many clients to choose from, we strongly recommend using Element since that is the only client that supports all the features used in our community. If you already have a Matrix client, you can continue to step 2.

This decision was not made lightly - the Ubuntu Matrix Council was well aware of the fact that there were many Matrix clients and many people who would be using those clients instead of Element when we decided to do this. The rationale is explained pretty well further up in the conversation: Shipping the Element Desktop Snap in official Ubuntu flavors? - #14 by arraybolt3 The last thing we need it to give new users analysis paralysis or cause further fragmentation by recommending any one of several clients, so we picked one that worked and worked well.

Technically decisions can always be gone back on later if they prove to be the wrong decision. But we’d have to establish whether the decision was wrong first. Which, there’s no reason to not establish that now, so let’s go through every stable and beta-quality client in https://matrix.org/ecosystem/clients/. Specifically, I’m going to start with the requirements the Ubuntu Matrix Council has for a Matrix client:

  • It has to be reasonably easy to use, both for onboarding and continuous use. If the client is overly buggy, difficult to use, or targeted towards a niche user group to the exclusion of other users, it isn’t acceptable.
  • It has to be actively maintained, otherwise users are going to get left in a lurch.
  • It has to support all of the more advanced features currently in regular use in the Ubuntu Community. Some of those features are:
    • Spaces
    • Threads
    • Pinned messages
    • E2EE rooms (for DMs)
    • SSO

So, here’s the list:

  • chatrix: Matrix client for Wordpress.
    • Obviously not suitable due to use case scenario, end-user desktops are not Wordpress.
  • Cinny: A Matrix client focusing primarily on simple, elegant, and secure interface [sic].
    • No threads support.
  • matrix-commander: Simple but convenient CLI-based Matrix app for sending and receiving.
    • CLI-based = targeted to a niche user base, unacceptable.
  • kazv: A convergent Matrix client and secure messaging app.
    • Beta-quality, does not support spaces which makes it unsuitable for use with the Ubuntu Community space.
  • Tammy - Tammy is a fast Matrix client focusing on simplicity and extensibility.
    • No threads support.
  • Element X - Element X is pioneering the Matrix 2.0 implementation, notably supporting fast sync with sliding sync.
    • Can’t log into the Ubuntu homeserver due to incompatible SSO implementation, mobile-only.
  • iamb - A terminal-based Matrix client with Vim keybindings written in Rust.
    • Terminal-based and Vim-based, thus targeted to a niche user base.
  • Thunderbird - A free open-repo email, calendar & chat app.
    • This one sounds hopeful at first, Thunderbird is already everywhere, right? Unfortunately Thunderbirds Matrix client is an utter disaster - there’s no profile pictures (and I don’t think there’s even room icons), formatting is very bad, messages are duplicated in weird ways, and trying to manage Matrix accounts is a pain (especially trying to remove them when you inevitably get a headache from trying to use it). This is not OK from a usability standpoint, therefore can’t be used.
  • Fractal - A Matrix messaging app for GNOME, written in Rust. Its interface is optimized for collaboration in large groups, such as free software projects, and will fit all screens, big or small.
    • No threads or spaces.
  • gomuks - A terminal Matrix client written in Go.
    • CLI-only.
  • Nheko - Desktop client for Matrix using Qt and C++20.
    • This is probably the single best non-Element-based client out there. Unfortunately the best option for installing it on Ubuntu is via a Flatpak (there is a deb of it but due to the moving target nature of Matrix, a deb-packaged Matrix client cannot be recommended or relied upon). The user interface is additionally very difficult to use for anything beyond the bare basics, and even for basic use it’s painful. I’ve tried to use it for moderation tasks and I want to pull my hair out sometimes when trying to make it work. This flunks the “difficult to use” test similar to Thunderbird.
  • Fluffychat - Cute instant messaging app for all platforms.
    • No threads support.
  • Ement.el - Ement.el is a Matrix client for GNU Emacs, the text editor and Lisp environment (which runs on GNU/Linux, MacOS, and WIndows, as well as other platforms). It aims to be simple, fast, featureful, and reliable, while integrating naturally with Emacs.
    • Niche target user base. We can’t make everyone use Emacs, the Vim wizards will kill us.
  • SchildiChat Next - A fork of Element X with additional features such as Spaces support.
    • Mobile-only.
  • Hydrogen - Lightweight matrix client with legacy and mobile browser support.
    • No threads, no spaces.
  • Quaternion - A Qt5-based IM client for Matrix.
    • No spaces, no E2EE support. Also I’ve tried using this myself, it’s a bit clunky.
  • matrix-commander-rs - Simple but convenient CLI-based Matrix app for sending and receiving.
    • CLI-only.
  • Quadrix - Minimal Matrix client available in all main app stores
    • No E2EE, no spaces, no SSO, probably no threads.
  • chatty - A simple to use messaging app for 1:1 communication and small groups supporting SMS, MMS, Matrix and XMPP.
    • No threads, no spaces, no SSO.
  • Neochat - A Matrix client for desktop and mobile
    • This is an official KDE project. Of the Matrix clients I’ve used, this is a pretty good competitor in the Matrix client world, less featureful than Nheko but far more usable. That being said, it has some bugs with the chat area jumping around in very weird and frustrating ways that make it a pain to use. It’s also crashy oftentimes, and the Snap seems to lose my account information a lot. It also appears to lack threads support.
  • SchildiChat - Based on Element, with a more traditional instant messaging experience.
    • If it’s based on Element, it’s going to have a lot of the same technical issues as Element. Given a choice between a community-maintained Element spin off and Element itself, I personally think Element is preferable because Element is less likely to become unmaintained than SchildiChat based on the fact that it has a company behind it and SchildiChat doesn’t. That being said, if we overlook that aspect, it might be suitable as a competitor against Element. It seems to support all needed features, and is actively maintained. I’ve never used it so I can’t speak to its usability.
  • Element - Element is a glossy client with an emphasis on performance and usability.
    • I don’t know why this rendered at the bottom of the list of clients in the link I shared, but it did :stuck_out_tongue: Anyways we’ve already established this is a usable client in real-world use, so we know it’s acceptable from a “does it work” standpoint.

So of all of the existing Matrix clients that exist and are documented on Matrix.org (and aren’t alpha-quality or worse), we have two possible options, Element and SchildiChat.

So now, do either of them meet all of the requirements @jbicha mentioned? Nope. Both of them flunk Behavior will remain "stable" for the lifetime of an Ubuntu release right out of the starting gate, and probably also flunk the architecture support requirement, since they’re both based on Electron which is based on Chromium. The other requirements can almost certainly be met, and Firefox has exceptions for the two troublesome requirements already so there’s precedent here.

tl;dr: Our set of ideal Matrix clients that can actually be used and match all of the requirements listed is exactly zero. Our set of potentially reasonably usable clients is Element and SchildiChat, and of the two the Ubuntu Matrix Council picked Element.

4 Likes
33

sudo snap connect neochat:password-manager-service

(just sharing for a solution and in brevity, not endorsing)

1 Like
34

It sucks that the one feature that is probably the most polarizing (threads) is the one thing that kills so many options.

1 Like
35

Thank you so much for posting that detailed summary. I really appreciate it.

What I hear is the solution is to build our own client, right? :smiley:

(I am of course kidding)

2 Likes
36

Only allowed if we pick a yet unpopular and unknown new toolkit :wink:

3 Likes
37

Or, and hear me out: tk/tcl :laughing:

3 Likes
38

No, no, no. Ncurses. But there’s a Desktop Entry to open it up in terminal window. You know, for convenience.

2 Likes