Contacts Plugin

[Simon Redman]

Thank you all for the feedback! My thoughts inline:

On 01/16/2018 01:24 PM, Andy Holmes wrote:
> Probably the most flexible is to keep them cached, in vCard or even
> flat JSON since that's how it's received, in a directory with
> permissions restricted to the local user. It's not unlikely each phone
> might have different contacts (eg, work phone, personal phone) so
> should have their own file/directory and leaving the data in an easily
> parsable format means applications could write contact providers as
> needed.
I don't mean to start an argument, but I don't understand what this adds
vs. an on-demand dbus interface which exports contact data in some
useful format (like vCard)

KDE Connect's dbus registration already supports multiple devices --
Just figure out the device ID you want and call the contacts/ping/etc.
plugin under that device

I am new to working with dbus, so I may misunderstand this point, but
since KDE Connect registers to the session dbus (at least on my
computer), method calls are restricted to processes running under the
user's account

Saving files does have the advantage that contacts would be available
when the phone is disconnected, but if we want that we should avoid
writing our own address book application and instead integrate with one
that already exists, like KAddressBook
>
> On Tue, Jan 16, 2018 at 12:12 PM, Aleix Pol <aleixpol at kde.org> wrote:
>> On Tue, Jan 16, 2018 at 8:56 PM, Nicolas Fella <nicolas.fella at gmx.de> wrote:
>>> On Dienstag, 16. Januar 2018 01:43:07 CET Aleix Pol wrote:
>>>> On Sat, Jan 6, 2018 at 3:03 AM, Simon Redman <simon at ergotech.com> wrote:
>>>>> I have just put up a contacts plugin for review
>>>>>
>>>>> In its current form, it is extremely primitive. Probably too basic to be
>>>>> usable. The KDE-side has a DBus slot which takes no arguments but sends
>>>>> a request to the Android side for its entire contacts book. The contacts
>>>>> book comes back, and is then sent back on DBus as a massive list of
>>>>> strings, one name, followed by one number.
>>>>>
>>>>> I know that there are projects/people other than me interested in this
>>>>> functionality, so I am looking for input from those people for what they
>>>>> would like to see in terms of a better DBus API
>>>>>
>>>>> Also code-review feedback, because I don't have much real-world
>>>>> experience :(
>>>> Hi Simon,
>>>> It's definitely interesting, something we have discussed in the past even.
>>>> How do you expect to present these contacts?
>>>>
>>>> Aleix
>>> Hi,
>>>
>>> thanks for your work on this!
>>>
>>> Before implementing things we should think about the use-cases we want to
>>> serve. I was thinking about a import from device function in KAddressbook.
>>> Another often demanded feature is writing SMS from the desktop.
I specifically want to support SMS from the desktop. In particular, the
telepathy plugin.

Since telepathy is not a KDE-dependent protocol, I would like to make
that plugin also not be KDE-dependent. In other words, if someone is
using Empathy and KDE Connect on Gnome, I wouldn't want them to have to
install KAddressBook in order to use kdeconnect-telepathy
>>> We also should
>>> care about privacy here (it got selected as one of our primary goals).
>> +1
(Sorry if the +1 was supposed to refer to the whole paragraph and I have
now split it, Aleix)
Where can I read those primary goals? I'm still new to this project and
KDE, so I should read those before continuing!
>>
>>> Obviously the user has to consent by giving the contacts permission, but she/
>>> he might want to restrict access to certain applications, so we might need to
>>> restrict who can read from the DBus interface.
>> There's no much of a security model around dbus, so it's probably not doable.
Is an acceptable answer to this problem to leave the plugin disabled by
default until we come up with a better answer? In the worst case, nobody
uses the plugin and the situation is the same as today, but we have a
framework to move forward.

I am not a security expert, so I can't think of a way to secure the dbus
interface. One thought would be to have some popup on the phone saying
such-and-such an app wants to access the contacts interface, but I don't
know how to authenticate that an app reading the dbus interface is the
app it says it is.
>>
>> Another way to implement it would be to keep a synchronized set of
>> vcards on the system.
Is this the same thing as Andy suggests? If so, see above
>>
>> Aleix