I don't really have this problem anyways, but isn't the better solution to have the serving instance of KDE Connect do the art downloading and transfer the file as normal? I think the only external input to the android app should be from the remote paired device. This also ensures the Android app (or whichever client) has it's address isolated from any outside source.

I think it would be better to not auto-send the message...

All of our SMS app works on thread_id, with the assumption that they would be unique...

There is also an error when you type the phone number for a contact with whom there is already a conversation

If I recall from when I did this, UPower has a state integer that could be used which is backwards-compatible with the current 0|1 approach.

I've removed the part about systemd as that was incorrect. All that needs to be done is to port to BecomeMonitor()

Would you consider (when you're ready) updating the README to be a little more complete, since you're probably quite familiar with the expected packet formats?

I'm a bit backed up with some other projects to jump into phabricator and Qt (both new to me) at the moment, but I'll try and get to this when I can since I've at least implemented it in GSConnect. There's probably a fair amount of time to deal with this anyways (at least another release cycle), but anyone else can obviously take it if bug reports start getting filed and I haven't come back to it.

Sorry, this was mostly a RFC on my part so I'll try to clear it up:

Haha how silly of me. Of course that makes much more sense :) I was
confused by the phrase "your extension".

If you mean GSConnect, you're more than welcome. I'm a few days away from a bugfix release, which should be pretty solid. It uses a few tricks to support being installed to both system and user directories and _should_ handle missing dependencies gracefully. Basically installing gnome-shell should cover all dependencies other than eg. sshfs.

Yes, I meant to offer it but kept forgetting about this task. Here's a paste of my current (not pushed to github) extension:

I suppose that makes sense, I know a number of people who use NextCloud for contacts. Google Contacts uses URNs such as "http://www.google.com/m8/feeds/contacts/my_name%40gmail.com/full/7c7ce738a953a16", which are obviously google specific.

With regards to contact IDs from Android, have you happened to notice if these are the same as reported by the Google Contacts API? If so, that may make some desktop integration slightly easier/more performant since at least libfolks offers these and the IDs could be used to pull photos and such from the local cache.

Why not include looped sound, which could then be identified as specifically KDE Connect. Such as with cordless house phones.

I might be late to this discussion, but I thought I'd weigh in since I've found a workable solution on the client-side for my gnome-shell extension.