Is it time to sunset GSConnect?

[andyholmes]

This project moved to a community-driven model since I stepped down as primary maintainer almost 3 1/2 years ago. As evidenced by the amount of work put into #1683 and prerequisite PRs, by an experienced developer, the project is clearly in late-stage bitrot. We could push that PR through in spite of the test problems, but the test suite is really the only thing confirming the project works at all.

There are in fact still several CVE reports affecting GSConnect receiving no attention, and we've been advertising invalid verification keys for pairing since November 2020. These kind of critical issues are more than an inconvenience for users, since there are many distributions shipping GSConnect in repositories, some as part of their default install.

The constant "me too" comments on issues resulted in me (and probably others) turning off notifications at least two years ago. Without a serious, committed contributor willing to do more than throw water on an oil fire, we should probably consider just giving a release-cycle's notice and shutting the project down.

There are a number of us old-timers hanging around, but I'm getting the impression none of us really have much time to spare. So I'm opening the floor to hear a good reason why we shouldn't just sign the DNR and let the old girl R.I.P.

cc @daniellandau @ferdnyc @sonnyp (feel free to include others, if I've missed anyone that makes sense)

[andyholmes]

I didn't actually realize putting this in announcements would make it largely read-only, so I've moved it into General.

[sonnyp]

I think it's the responsible thing to do. I'm sorry I couldn't help more with maintenance.

I haven't been using GSConnect for a while since I switched to Valent. I think a dedicated app is the right primitive for supporting KDE Connect on GNOME going forward.

[ferdnyc]

Here's my take:

I don't actually use much of GSConnect anymore.

• SFTP browsing never worked well due to gvfs-sftp's limitations, and there are better ways to move files between my phone and my desktop (including Dropbox and Google Drive).
• Messaging, I haven't had any use for since Google created Messages for the Web.
• Clipboard sharing was nice while it lasted, but the writing was on the wall when it comes to that feature for quite some time.
• I don't use remote commands or remote input, in either direction.
• I don't use any remote photo capture, remote phone-finding, contacts syncing, or battery/connectivity monitoring.

But the limited set of things I do use it for, I still find significant value in.

• First and foremost, the ability to open web pages in my desktop browser by using Share > KDEConnect Send to device.
• Notification syncing is also a big time-saver, particularly when some website sends me a 2-factor code via text message.
• The MPRIS media controls still very occasionally come in handy. The ability to auto-pause/mute my desktop's media player on an incoming call, even more so.
• Ditto the ability, very occasionally, to send a small file from my desktop to my phone, which still works even though SFTP mounting is a bust.

I don't know anything about Valent and it's not in the Fedora repos. Perhaps it would serve my needs.

I have thought about the possibility of using kdeconnectd as a backend daemon, along with a pared-down extension that interfaces it to the GNOME Shell desktop. That would have a reasonable chance of replacing GSConnect, but it's a question of how conducive kdeconnectd is to integration with non-KDE code. I haven't explored it deeply enough to answer that question.

I guess my point is, implementing an entire network service in GJS JavaScript was an interesting experiment, but probably overambitious. Nevertheless, if at all possible I'd like to see the GSConnect userbase directed to viable alternatives, as a prerequisite for it being mothballed. Rather than just leaving them high and dry.

[ferdnyc]

Oh, and re: #1683, I've always found the project's testing infrastructure to be intimidatingly complex; it was probably one of the primary reasons I'd never even have considered taking on maintainership. Far more than the actual extension code itself, that's for sure! 😆

[andyholmes]

Yeah, in fairness I kind of ran out steam updating jasmine-gjs, which probably would've helped clean up the test suite. That being said, it was really just a cardboard cutout of me I left to slip away :D

[daniellandau]

I have a somewhat complementary set of features I use and don't. I do use remote input (phone as input to computer) and clipboard sync, and used to use phone finding often before I got a smart watch for that. I never use the web page sending, as I just use Firefox sync for that. I don't send files from my computer to the phone, nor the mounting feature, but I do sometimes send individual pictures from my phone to my computer when I'm on a computer that doesn't sync my whole Nextcloud auto upload folder.

[daniellandau]

I don't agree. I think GSConnect is stable, and used by many people (me included) every day and sunsetting it without a continuation plan is a bad idea. That said, if this line in Valent README changes

This project is currently in alpha. It generally works as intended, but is still missing some features and may contain bugs.

I'd be open to changing the technology stack of GSConnect to Valent / other migration plan.

About some individual points:

the test suite is really the only thing confirming the project works at all.

I do manual testing before every release. In Arch when it's a new shell release as that's the easiest access I have to the next shell release and I run stable latest releases of Ubuntu and Fedora with the latest GSConnect.

There are in fact still several CVE reports affecting GSConnect receiving no attention

I guess I must have read that at some point, but had completely memory holed it. That's not exactly great, but DoS against a laptop isn't the end of the world, and this attack doesn't seem to happen much in real life.

we've been advertising invalid verification keys for pairing since November 2020.

That issue I think is open by mistake, as we fixed the verification keys on our end while KDE Connect Android still had an off by one error in theirs: #1493

The constant "me too" comments on issues

I think quite a bit of that traffic is people who have a network that makes device visibility difficult, or firewalls not configured correctly etc, and the mount feature which is problematic indeed but hard to fix (especially when the real fix would be for the Android side to use a better cipher).

turning off notifications at least two years ago

I do have notifications on, and I'm very well aware that I haven't been contributing as much as I would like. Two small kids and a job :/

Without a serious, committed contributor willing to do more than throw water on an oil fire

I'd be happy to help maintain Valent instead when that's ready for prime time. Until that, this thing still works and I don't think we should have a time period where no KDE Connect protocol client is considered "stable" in GNOME Shell.

I do realize that it's easy for me to say that, when you Andy are still doing most of the maintenance work. I don't know how to express it well, that the whole community is very thankful, but you don't have to keep doing it.

[ferdnyc]

I think GSConnect is stable

I mean... except for all the ways in which it's horribly broken. I suppose technically, broken is a stable state...

The sticking point for me (and this is regarding software in general, not just GSConnect — but GSConnect is very much included)... the sticking point for me is differentiating between "stable" and "stagnant".

People talk about "stable software" and "stable releases" as though software exists in a vacuum, and once something is "stable" it will never break unless someone goes and changes it.

But any software that interacts with other software is guaranteed to become unstable, if that other software changes but it does not. And KDEConnect has changed a lot over the years, primarily because Android has changed a lot over the years, and it's been forced to make reactive changes the same way we have with GNOME.

We've done a pretty good job of tracking GNOME changes, primarily because we've simply had no choice. Whenever something changes in GNOME Shell it usually breaks the extension for everyone. So it has to be fixed, and it gets fixed.

We've done a much worse job of keeping up with KDEConnect changes. When something changes in KDEConnect, it usually manifests as subtle and hard-to-troubleshoot/debug issues for whatever subset of users even have that GSConnect feature enabled and are attempting to get it working. The extension still functions exactly the same, because it's stable, so it's not like we broke anything on our end.

...Anyway, I digress.

If GSConnect is going to continue, I do think there need to be some major changes. To the code itself.

1. We should rip out the SFTP-mounting code and stop pretending it's ever going to work.

   It can't, due to a combination of KDEConnect Android using a massively outdated library as the basis for its implementation, and GVFS' inflexibility preventing us from employing the same tricks and kludges that the KDEConnect Linux side relies on to work around that.

   Remote mounting should just be declared a non-feature in GSConnect.

2. We should probably rip out Messaging entirely, as well.

   Since the changes KDEConnect made to how they respond to message requests, I don't believe it actually works correctly for anyone anymore. And it won't, unless it receives a pretty significant rewrite. (Message threads only showing most recent message until first usage #1625 — see my Message threads only showing most recent message until first usage #1625 (comment) in particular)

   Even if Messaging got the backend rewrite it needs to work with current KDEConnect, it's still a pretty crippled feature with no support for shared images and video, no previewing of embedded links, and none of the other bells and whistles people expect from a modern SMS application — all things that Google's web interface provides.

...There's probably more, but those are the two big craters that always leap out at me in GSConnect's current codebase. Lots of code for both of those features, unfortunately none of it actually works anymore.

(They're also both devoid of any debug logging. Except for noisy packet dumps that don't actually help at all, because the issues have nothing to do with the data being communicated between the devices.)

[andyholmes]

Remote mounting should just be declared a non-feature in GSConnect.

That's going to ruffle some feathers, but I don't use it myself so I don't really have a strong opinion 🙂

We should probably rip out Messaging entirely, as well.

Probably the easiest thing to do is just replicate what KDE Connect does and read on-demand. I never ended implementing an on-disk database that's read or really searchable, but for some reason no one's ever complained we keep the entire database in-memory 🙃

The format ultimately changed due to performance issues, which I believe are imposed by the Android APIs. Since then much better protocol features for requesting threads and messages have been added, so it's not a lost cause. Just need contributors 🤷

Except for noisy packet dumps that don't actually help at all, because the issues have nothing to do with the data being communicated between the devices.

Definitely agree here, this is a debug build only feature in Valent for that reason. We have shared JSON Schemas upstream now, which is much better suited to automated tests, where we can also do fuzzing.

[daniellandau]

Should we take those two out right now? Judging by the amount of bug reports and users helping each other getting the kludge working, the mounting feature does seem to be used by people. Maybe since it requires manual config file updates anyways we could make it a CLI only feature?

[andyholmes]

I'd guess the other option is to revert to sshfs. I believe the switch to GVfs was to get mounts to show in Nautilus and there's no way to bundle sshfs. @ferdnyc probably recalls the PackageKit nightmare :)

[ferdnyc]

^ Ugh. I'd sooner burn the whole thing to the ground!

[daniellandau]

We had 5 separate people submit code to make 46 support happen + other community members contributing other code improvements. Can we agree that it is not time to sunset GSConnect and close this discussion? Once Valent is ready we can have another discussion if it's time to do a tech base migration.