Ubuntu as a community is moving over to Matrix more and more as the primary platform for development, discussion, and support for Ubuntu and its flavors. We’ve gotten to the point where the Ubuntu Technical Board has chosen Matrix as the primary communication platform for the development of Ubuntu as a whole.
One thing that’s still a slight rough edge with Matrix is that there is no “official” Matrix client for Ubuntu. Technically, the Ubuntu Matrix Council has chosen Element as the recommended client, but this has one critical disadvantage - there is no official Element package for Ubuntu. People who want it as a deb have to install it from a third-party repo, people who want it as a Snap have to use @kenvandine’s Snap, and everyone else has to use Element as a web app which is IMO a subpar experience.
Currently Ken’s Snap has been sufficient for many users - he’s a trusted developer, his package works, and it’s in the Snap store so it’s super easy to install. However, given that the Snap isn’t an official part of the Ubuntu operating system the way the Firefox and Thunderbird Snaps are, I do not believe it is allowable to include the Element Snap on any official Ubuntu images, per Technical Board policy (just like PPAs aren’t allowed).
While I’m not sure any particular Ubuntu flavor is ready to ship Element out of the box yet, Kubuntu has a bit of discussion about potentially doing it if possible and desirable. The fact that there isn’t any official Element package for Ubuntu is a blocker for this happening though. With that in mind, what would it take for the Element Desktop Snap to become an official part of Ubuntu, similar to Firefox and Thunderbird? Would it be possible for Ken’s package to “become official” somehow? (I don’t know how Snap processes work, so forgive me if this isn’t the best wording here, hopefully you know what I’m trying to say.)
Perhaps I need to look at it closer, but I was of the understanding that not just any Snap could be included for the same reason the flavors agreed to not use Flatpak and the same reason PPAs aren’t kosher. I wouldn’t expect it to go over well if Lubuntu tried to ship, say, a particular Exodus Wallet Snap (and yes, I’m referring to the malicious one). I’ll look over it closer though.
So I looked it over, and you’re right. The fact that Ubuntu Studio is shipping Freeshow is also good existing precedent.
Element still would have some hurdles to jump here though. Due to the “moving target” nature of Matrix, Element can’t pass Principle 1 of the policy, just like Firefox can’t, so it would need an exception there. Principle 2 isn’t really enforced at all for any Snap, which is arguably a problem for everything. Principle 3 would need Ken to commit to maintenance, which isn’t something any one flavor can just say “here you will do this now” for obvious reasons. I don’t know if the existing Snap passes Principle 6 (I don’t know where Ken’s sources are), and I’m not sure Element can pass Principle 7 (depends on upstream’s arch support). So there would still be quite a bit of finagling to do before this would be possible.
Forgive me if I’m wrong but I don’t think Ubuntu Developers can push to ICE branches on their own? It appears the TB can but @tsimonq2 at least lacks the ability to push updates despite being a Core Dev. (Pinging him since he’s the one who’s been the most vocal about this particular issue.) Maybe that’s not what “Ubuntu developers” means in the policy doc, I’m not sure.
I don’t think the ICE branches are special in any particular way apart from the upstream commitment to them. To snaps, they’re just general branches which the developer can create on demand at any time without having to ask. Where the official ICE branches MAY differ ( I remember this was impossible to implement properly years ago but may have changed since ) - is that these branches automatically expire after 30 days if the developer doesn’t release a new build. Their original intention is for short lived bug fixes, which is why they’re hidden generally from the API’s and store interfaces.
I would hope that given how Ubuntu utilises them; there’s now the ability to override these branches to never expire, because if they DO expire, the behaviour is the snap will revert to the next best supported available release (e.g., fall back to latest/stable) and this could cause people to break, I’m also not sure it can be fixed automatically when it does occur because to snap, it’s intentional behaviour to prevent developers forgetting to bring people back onto “supported” releases.
So, either the automatic closing problem needs administrators to sort out; or there needs to be a commitment to rebuild those branches at least once a month which runs risks if not done properly.
All that said, again, any developer can publish to their custom and self chosen branches on demand when things are working typically.
That’s fair. The key thing is that it’s implemented at the client end, so they’re ready from that perspective. Actually using these branches would require coordination between the TB and the Snap Store team. That’s as far as I could push it when I negotiated this retrospectively.
In practice, the intention is to only use these for “emergencies”, like an upstream gone rogue, so I don’t think it’s a terrible position to be in.
It isn’t the intention to use them for distro patching like we do for debs. The principle in the snap world is that the upstream primarily makes those decisions and not the distribution. That’s the choice that Ubuntu makes when it ships a snap under this framework - decisions of this sort are also delegated to upstream.
To be clear, what I meant by that is the entire body of Ubuntu developers as a whole, as led by the Technical Board. Then how that delegates to individual Ubuntu developers can be sorted out later by the Technical Board, and in this case, blocked on actual implementation. But as above, I think that’s OK for now, and much better than it was
FWIW, had I been involved when snaps were first adopted by Ubuntu, I’d have pushed for more of this to be implemented before accepting that change…
This is probably my biggest concern and my biggest concern with many unofficial Snaps like it. Heck, it’s not even obvious where to file bugs. That’s a rather huge, glaring problem.
It would seem the reasonable solution here would be to have Canonical take on the Snap, especially given the original idea that Element could be something we could ship by default, which I think we should given that IRC has essentially been superseded by Matrix.
I wonder if Element is the right client for this purpose. At the moment it seems to be, but shipping something by default is ideally a multi-LTS commitment. Even though we can change defaults every release, it wouldn’t make for a great user experience.
I’d certainly like to see something more lightweight that follows the regular distribution release cycle of a deb. I think that most software eventually reaches a pace of development where that’s feasible, and a Matrix client will be no different. Software like Firefox is the exception there really.
In the meantime, maybe use of the web client is sufficient that we don’t really need to ship a native-not-really-native client by default?
I think the one argument to be made about Element (beyond the Matrix Council’s recommendation) is how closely tied it is with the Matrix protocol. It should keep pace much closer to changes in the protocol than other clients.
I do personally use the heck out of the web client and find it really to offer almost nothing in the way of disadvantages relative to the desktop client. However, when we’re talking about shipping something by default, we want the best user experience possible. I’m not sure using the browser is the best way to do this.
The problem isn’t that the client keeps changing half so much as the network keeps changing. Clients either keep up, or they don’t, and if they don’t, they break, just like Telegram Desktop. Any Matrix client would need these kinds of continuous updates to avoid potentially becoming totally unusable at some arbitrary point in the future, regardless of which client we picked. Additionally, Element is the only client I know of that has a company behind it to drive development, the other clients might become unmaintained whenever the devs stop feeling like maintaining them.
This is a bit similar to the issues that web browsers in general face - there’s so much to implement that only well-established browsers can really keep up. Handling the basics of the protocol doesn’t seem to be too hard, but once you get into the nitty-gritty (encrypted DMs, single sign-on, threads, handling room scrolling without jumping all over the place, etc.), it becomes a massive job. At the moment Element and forks thereof are the only Matrix clients that are good enough I would consider them daily-drivable for the average user. To my awareness, the only client that is mostly feature-complete that isn’t an Element derivative is Nheko, and IMO Nheko’s UI/UX is really, really bad. (I had an easier time learning Vim than I had learning Nheko.) Nheko also has a security warning about encrypted DM handling, which is slightly concerning:
The current implementation is mostly stable, but it was never audited. If you rely on it for security, we can’t make any guarantees.
It might be, but the sad thing is Element Web cannot be used to search through encrypted chats. You have to use Element Desktop or some other client if you want to do that. The user experience of having Element in a tab is also less-than-awesome, and Element’s browser support is rather lacking (even Firefox has issues with it if you try to use it in a private browsing window, for instance).
@arraybolt3 , speaking as a member of the Matrix Council, offers some great insight here. To me, it’s clear the only reasonable solution is Element Desktop. Since it changes so often (and really needs to in order to keep up with the protocol), then it seems the solution is a Snap.
Which brings us back around to the original query and what I suggested before: what will it take for Canonical to make an official Element Desktop Snap?
On the topic of the element-desktop, the intention has always been that Element would eventually take ownership of it but that conversation has stagnated a bit. I’ll reach out to them again and see if I can get it moving again.
I’d argue that it should be published by a trusted entity. Not that I’m untrustworthy, but I’m just a single person. We could discuss transferring it to Canonical, if the desktop team wants to help own it. Of course I will still be involved, happy to keep doing the work in my spare time
There has also been interest from snapcrafters about taking over the snap as well. But that probably doesn’t fit the policy either.
The other piece to that is that, in order for a snap to be seeded, it must have a branch of latest/stable/ubuntu-yy.mm. Without that, it cannot be seeded. If Element were to take over the snap, they likely would not add that branch.
Regardless of who the publisher is, those branches can exist and we would need the release team to have access to publish to those branches, as we’ve done with other seeded snaps.