True convergence for NeoChat, Tokodon, Itinerary, Kasts, Elisa, etc

Brainstorm
,
1

Wouldn’t it be great if there were true convergence between the convergent desktop and phone applications? Let me explain…

Say you are listening to a podcast on Kasts on your laptop as you… er… “work”. But then you have to leave the house, because, you know, you have to go out an touch grass sometime. So you head out with your BT headphones and phone, and the podcast continues playing on the mobile version of Kasts from the point you left off seamlessly without you having to do anything.

Other use cases:

  • When you add a new account to your Tokodon app on your desktop, it could be picked up automatically by Tokodon on your phone and vice versa.
  • Your NeoChat configuration could be shared on your other devices so you don’t have to go through the tedious process of configuring every single device individually: configure NeoChat on one and suddenly all your other devices are configured.
  • You plan your trip on your desktop, input all the data regarding your flights, transfers and accommodation using the Itinerary PIM feature, and it automatically gets synced to your phone. Any updates (say, when you add your boarding pass or a pick your seat) get synced as they happen, so that, on the day, you just have to grab you suitcase.

Maybe this could be done over KDE Connect with plugins. For security reasons, they could be disabled by default, but, when you are in a safe area, say within the network of your own home, you could enable them and things would get synced as soon as your devices see each other.

4 Likes
2

That does sound like a great idea!

Could be offered in several levels, e.g. sharing only certain data or config with the other instance vs keep both instances in sync.

I would also love if I could simply sync files through KDE Connect instead of manually transferring them.

Almost all, if not all, solutions for keeping apps/devices in sync requires a server.
In the worst case a proprietary “cloud”.

I always wondered if KDE Connect could act like a “conduit”, similar to how you can tunnel almost everything through an SSH connection.

1 Like
3

I use Syncthing on my local network to synchronize files between my computer and my Android phone, but to sync app settings on Android they need to be stored where Syncthing can access them (i.e. not in the apps own data area).

I also would love if KDE Connect could sync files, but I don’t know what that would take to implement. You have to somehow handle the case where a file has been modified on both sides between syncs. Syncthing at least keeps a copy of conflicts, so you can manually merge the changes if it’s a text file.

4

That does sound like a great idea!

Thanks!

Could be offered in several levels, e.g. sharing only certain data or config with the other instance vs keep both instances in sync.

Yeah, even sync only certain apps and not others.

I would also love if I could simply sync files through KDE Connect instead of manually transferring them.

That would be very useful too. Maybe that should be the first thing, and, is syncing apps implies syncing configuration files, it may be the basis for everything else. Although I am not dev and I may be talking nonsense :grimacing: .

Almost all, if not all, solutions for keeping apps/devices in sync requires a server.
In the worst case a proprietary “cloud”.

Exactly. I think that KDE Connect’s proprietary copycats require you go through their online services. At least MS’s Phone Link requires you sign into your Microsoft account to sync your phone to your desktop and vice versa, even if they are sitting right next to each other and on the same network. That makes no sense… Until you remember that what they really want to do is suck your data off your devices.

Another second advantage of going through KDE Connect is that it is not only for one desktop and one phone, but say you have desktop machine and a laptop for travelling. They can be automatically synced too. With something this, you can make it so you configure your everyday apps on one device, and you can configure them on all.

I always wondered if KDE Connect could act like a “conduit”, similar to how you can tunnel almost everything through an SSH connection.

That is well beyond my knowledge, but I see what you mean.

Then of course is the fact that, although KDE Connect is already one of the most loved pieces of KDE software, the others, Kasts, Arianna, NeoChat, Itinerary, Elisa, etc., are much less known (and used). By joining them together, and giving them this feature of transparent synchronisation across devices, they would immediately become much more attractive to end users and offer something that their competitors can’t.

1 Like
5

My understanding is that, unfortunately, on mobile the config of apps is essentially only know to them (and perhaps certain OS services).

Config (and state like current music track and position) might be something the mobile instance of an app and the desktop instance of the same app need to exchange themselves.

Exactly!
And even things that are not like KDE Connect, e.g. syncing files via NextCloud.

Having a remote server has of course advantages, e.g. off-site backup, but sometimes you don’t want data to leave your premises (or even you directly controlled machines).

Sure, that specific service could be installed locally but how many users can actually do that?

Syncthing, as @mrp mentioned, might be a solution.
Need to look into that.

Sadly that is seems to be fine for a lot of people. Or they are not aware.

I think that is true for virtually every sync solution.
The main difference would be that everything is peer-to-peer.

Like Syncthing for data but on a higher/application level.

Weeeeelll, I think we would want other applications to be able to work through KDE Connect. We are usually not in the “this is exclusive to approved KDE apps” business :wink:

1 Like
6

Oh yeah, absolutely. The same way other projects take advantage of KDE Connect’s underpinnings. I am not suggesting we impede that! But we can lead the way with truly convergent and local synchronization across apps and devices, giving our stuff at least a set of features that make them stick out and giving the whole ecosystem a bit of well-needed shove.

You know what? I don’t even worry that much about that. All I want is to be able to pick up my phone and head to the airport, knowing that all the stuff of my trip I have arranged is already in my pocket… including the latest podcasts I have downloaded for the flight.

I am willing to bet that there are a load of end users who would see this as an advantage too.

1 Like
7

Absolutely!

An Apple-like experience without all the nasty bits.

2 Likes
8

We have a prototype doing exactly that, via hidden/“machine-only” Matrix channels. The approach seems to work, it “just” needs work to cover all objects Itinerary deals with so nothing gets lost in the process. This has the added benefit over KDE Connect that it would be relatively easy to extend to multi-traveler scenarios where you not only sync a trip between your devices but also with the devices of your travel companions.

3 Likes
9

That sounds even better. Having had to send stuff like flight details and boarding passes not only to my device, but also to my wife’s device, that would have proven very useful.

Edit: So that only leaves Kasts, Tokodon, Elisa, Tokodon, NeoChat, … :laughing:

10

Instead of app by app basis, it would be far more useful if we create a convergence API/protocol. We wouldn’t be restricted by KDE ecosystem and can support more things like Audio and Device switching. KDE Connect definitely is the way to pursue it as it is already popular on other platforms like Gnome and Windows.

Making it a protocol also lets use platform native apps (say native android app on android and a KDE app on desktop)

4 Likes
11

That sounds amazing!

1 Like
12

Oh, yeah. For sure. This would open up the door to whole new ecosystem of completely convergent FLOSS apps.

What I meant was, from the users’ perspective, they should have the ability to choose which app to sync. Not have an “all-or-nothing” situation. And, again, doing that from something familiar, like the KDE Connect configuration dialog, would be a usability boon.

2 Likes
13

Say you are listening to a podcast on Kasts on your laptop as you… er… “work”. But then you have to leave the house, because, you know, you have to go out an touch grass sometime. So you head out with your BT headphones and phone, and the podcast continues playing on the mobile version of Kasts from the point you left off seamlessly without you having to do anything.

FYI Kasts already supports playback status syncing through gpodder.net or gpodder-nextcloud. This has the advantage that it’s a protocol which is used by several podcast apps on multiple platforms. We’re even collaborating with multiple apps on an improved successor: openpodcastapi.org.

But, there’s always possibility for improvement of course.

2 Likes
14

Very nice. Thanks for the heads up!

But, again, as with the Itinerary/Matrix solution, you have to go out to the Internet and through a third party server for the synchronization to work, when your phone could be sitting right next to your laptop, both devices connected to your local network. It is technological overkill, it adds an unnecessary level of insecurity and requires too much (an Internet connection and being registered with a third party service) from the user for something that really shouldn’t need it.

It also adds a barrier for end users, which goes against its usability. You can’t woo users towards your app with “easy” convergence features and then force them through a third party service that they most likely have never heard of, and expect them to trust and embrace it. That is a lot to ask.

It is also not generative. What about Arianna when you want to sync books you are reading? Or your Elisa playlist? Or… an app that hasn’t even been written yet, but could use a convergence framework? That is the proposal.

Your synchronisation ideas are great for power users and I applaud them and will use them for sure. But for regular Joes I would argue it will be too much and will counteract any semblance of usefulness.

2 Likes