CrossLink - More than what it seemed

I have been actively exploring how CrossLink can serve as a bridge to enable seamless continuity between Linux and Android devices. After careful thought and experimentation, I can say with confidence that this is not just another Evolve update. It deserves to exist as a standalone project that runs alongside Evolve rather than within it.

The first version of CrossLink, which was implemented in Flance, is something I am genuinely proud of. Its context-aware functionality was a personal milestone for me. That said, I have to admit that I barely used it beyond the early days, when I was still excited about testing the feature.

When I first introduced CrossLink on YouTube, the video received some criticism suggesting it was just another copy of tools like LocalSend or KDE Connect. I had already addressed that comparison in the video, but the same remarks kept surfacing. Hopefully, this post offers more clarity on the direction I am taking with CrossLink.

The Two-Way Connection

No, CrossLink does not use Wi-Fi Direct. The implementation turned out to be far more complex than using a standard LAN-based approach. Wi-Fi Direct is better suited for mobile scenarios where you're frequently on the move, and while it would be nice to have, it's not practical for my current setup.

The real challenge is hardware support. My laptop’s internal Wi-Fi adapter isn’t supported on Linux, so I rely on an external Wi-Fi dongle. Unfortunately, that dongle does not support Wi-Fi Direct, which makes development around that feature difficult, if not impossible, at the moment.

With that cleared up, let’s talk briefly about the different connection modes. Keep in mind that we’re still in the design phase. Not all features discussed here are guaranteed to make it into the final version, and depending on how things go, the final product may even include more functionality than originally planned.

Basic mode

No need to pair, just make sure the devices are connected to the same Wi-Fi network. Very similar to other data sharing apps. Enables you to share data (images, audio, video and more) instantly.

Advanced mode

This mode needs pairing and is available as additional features along with file sharing option. Here are the things I have thought of for adding. These are just ideas and are not the final product.

• Wallpaper Sync

  • Capture a photo on your phone, crop and set it as wallpaper on Linux PC

  • Set an image from gallery as wallpaper

  • Set phone wallpaper as Linux wallpaper

• Password sharing (Needs more research on how to store them, encrypt, decrypt and share on demand)

• Use your phone as a webcam.

• Sync light/dark mode, DnD and more with PC

• Notification mirroring from Phone

• Shared clipboard

• PC to PC syncing

PC to PC connection

All the features available in Advanced Mode are also supported in this connection mode, with the possible exception of "click picture and set wallpaper" along with "webcam mode," as these may not be particularly relevant in this context.

How will a “via phone” connection help?

A quick example might make this clearer.

Let’s say you change the theme on PC-A, and you have theme sync enabled with PC-B. However, PC-B is currently switched off. In this case, instead of the theme update being lost or ignored, the command and theme package are sent to your phone, which acts as an intermediary and holds them in standby.

Later, when PC-B is powered on, it connects to the phone and checks the timestamp of the last theme change. If the phone has a newer command than PC-B’s currently applied theme, it transfers the theme pack and applies it. If the theme on PC-B is already up to date, the phone simply discards the pending command and theme package.

This method allows your phone to serve as a persistent relay, helping devices stay in sync even when they’re not online at the same time.

How will the pairing be done?

For everything beyond basic file sharing, devices need to be paired. This is because most advanced features are only accessible to trusted devices. Here’s how the pairing process is designed:

• Each device gets its own unique hardware code

• Each connection gets its own unique connection code

• And finally each NEX app gets its own magic code.

When two devices attempt to pair, these three codes are requested and cross-verified to ensure a secure and trusted connection. Only after passing these checks is an encrypted link established.

The first step is verifying the magic code, which confirms whether the connecting device is running a genuine NEX app. In simple terms, when PC-A tries to pair with PC-B, PC-A asks, "Is the app requesting the connection a NEX app?" Once this is verified, the hardware and connection codes are exchanged, saved, and encrypted for future use.

For subsequent connections, the system first checks if it a NEX app, followed by whether the connecting device is already known by comparing hardware codes. If it’s unfamiliar, no data is shared. If it’s recognized, the session proceeds securely with all relevant details exchanged.