Contacts Plugin

[Aleix Pol]

On Sat, Jan 20, 2018 at 11:09 PM, Simon Redman <simon at ergotech.com> wrote:
> 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
>
>

To simplify:
You don't need much of a dbus API, just a directory where the vcards
go for every plugin within the device config.

Aleix