<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Jan 21, 2018 19:08, "Aleix Pol" <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">On Sun, Jan 21, 2018 at 6:51 PM, Thomas Posch<br>
<<a href="mailto:mail.kde.org@online.posch.name">mail.kde.org@online.posch.<wbr>name</a>> wrote:<br>
> On Sunday, 21 January 2018 15:22:43 CET Aleix Pol wrote:<br>
>> On Sat, Jan 20, 2018 at 11:09 PM, Simon Redman <<a href="mailto:simon@ergotech.com">simon@ergotech.com</a>> wrote:<br>
>> > Thank you all for the feedback! My thoughts inline:<br>
>> ><br>
>> > On 01/16/2018 01:24 PM, Andy Holmes wrote:<br>
>> >> Probably the most flexible is to keep them cached, in vCard or even<br>
>> >> flat JSON since that's how it's received, in a directory with<br>
>> >> permissions restricted to the local user. It's not unlikely each phone<br>
>> >> might have different contacts (eg, work phone, personal phone) so<br>
>> >> should have their own file/directory and leaving the data in an easily<br>
>> >> parsable format means applications could write contact providers as<br>
>> >> needed.<br>
>> ><br>
>> > I don't mean to start an argument, but I don't understand what this adds<br>
>> > vs. an on-demand dbus interface which exports contact data in some<br>
>> > useful format (like vCard)<br></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">
> I don't think vCards would make it easier. Unless you use fuse or inotify<br>
> hackery it would be quite hard to sync changes from the desktop to a remote<br>
> device.<br></div></blockquote></div></div></div><div dir="auto">A KCoreDirLister may solve this</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">
>> > KDE Connect's dbus registration already supports multiple devices --<br>
>> > Just figure out the device ID you want and call the contacts/ping/etc.<br>
>> > plugin under that device<br>
>> ><br>
>> > I am new to working with dbus, so I may misunderstand this point, but<br>
>> > since KDE Connect registers to the session dbus (at least on my<br>
>> > computer), method calls are restricted to processes running under the<br>
>> > user's account<br>
> You are not mistaken.<br>
>> ><br>
>> > Saving files does have the advantage that contacts would be available<br>
>> > when the phone is disconnected, but if we want that we should avoid<br>
>> > writing our own address book application and instead integrate with one<br>
>> > that already exists, like KAddressBook<br>
> I second that.<br>
>> ><br>
>> >> On Tue, Jan 16, 2018 at 12:12 PM, Aleix Pol <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>> wrote:<br>
>> >>> On Tue, Jan 16, 2018 at 8:56 PM, Nicolas Fella <<a href="mailto:nicolas.fella@gmx.de">nicolas.fella@gmx.de</a>><br>
> wrote:<br>
>> >>>> On Dienstag, 16. Januar 2018 01:43:07 CET Aleix Pol wrote:<br>
>> >>>>> On Sat, Jan 6, 2018 at 3:03 AM, Simon Redman <<a href="mailto:simon@ergotech.com">simon@ergotech.com</a>><br>
> wrote:<br>
>> >>>>>> I have just put up a contacts plugin for review<br>
>> >>>>>><br>
>> >>>>>> In its current form, it is extremely primitive. Probably too basic to<br>
>> >>>>>> be<br>
>> >>>>>> usable. The KDE-side has a DBus slot which takes no arguments but<br>
>> >>>>>> sends<br>
>> >>>>>> a request to the Android side for its entire contacts book. The<br>
>> >>>>>> contacts<br>
>> >>>>>> book comes back, and is then sent back on DBus as a massive list of<br>
>> >>>>>> strings, one name, followed by one number.<br>
>> >>>>>><br>
>> >>>>>> I know that there are projects/people other than me interested in<br>
>> >>>>>> this<br>
>> >>>>>> functionality, so I am looking for input from those people for what<br>
>> >>>>>> they<br>
>> >>>>>> would like to see in terms of a better DBus API<br>
>> >>>>>><br>
>> >>>>>> Also code-review feedback, because I don't have much real-world<br>
>> >>>>>> experience :(<br>
>> >>>>><br>
>> >>>>> Hi Simon,<br>
>> >>>>> It's definitely interesting, something we have discussed in the past<br>
>> >>>>> even.<br>
>> >>>>> How do you expect to present these contacts?<br>
>> >>>>><br>
>> >>>>> Aleix<br>
>> >>>><br>
>> >>>> Hi,<br>
>> >>>><br>
>> >>>> thanks for your work on this!<br>
>> >>>><br>
>> >>>> Before implementing things we should think about the use-cases we want<br>
>> >>>> to<br>
>> >>>> serve. I was thinking about a import from device function in<br>
>> >>>> KAddressbook.<br>
>> >>>> Another often demanded feature is writing SMS from the desktop.<br>
>> ><br>
>> > I specifically want to support SMS from the desktop. In particular, the<br>
>> > telepathy plugin.<br>
>> ><br>
>> > Since telepathy is not a KDE-dependent protocol, I would like to make<br>
>> > that plugin also not be KDE-dependent. In other words, if someone is<br>
>> > using Empathy and KDE Connect on Gnome, I wouldn't want them to have to<br>
>> > install KAddressBook in order to use kdeconnect-telepathy<br>
>> ><br>
>> >>>> We also should<br>
>> >>>> care about privacy here (it got selected as one of our primary goals).<br>
>> >>><br>
>> >>> +1<br>
>> ><br>
>> > (Sorry if the +1 was supposed to refer to the whole paragraph and I have<br>
>> > now split it, Aleix)<br>
>> > Where can I read those primary goals? I'm still new to this project and<br>
>> > KDE, so I should read those before continuing!<br>
> <a href="https://dot.kde.org/2017/11/30/kdes-goals-2018-and-beyond" rel="noreferrer" target="_blank">https://dot.kde.org/2017/11/<wbr>30/kdes-goals-2018-and-beyond</a><br>
>> ><br>
>> >>>> Obviously the user has to consent by giving the contacts permission,<br>
>> >>>> but she/ he might want to restrict access to certain applications, so<br>
>> >>>> we might need to restrict who can read from the DBus interface.<br>
>> >>><br>
>> >>> There's no much of a security model around dbus, so it's probably not<br>
>> >>> doable.><br>
>> > Is an acceptable answer to this problem to leave the plugin disabled by<br>
>> > default until we come up with a better answer? In the worst case, nobody<br>
>> > uses the plugin and the situation is the same as today, but we have a<br>
>> > framework to move forward.<br>
>> ><br>
>> > I am not a security expert, so I can't think of a way to secure the dbus<br>
>> > interface. One thought would be to have some popup on the phone saying<br>
>> > such-and-such an app wants to access the contacts interface, but I don't<br>
>> > know how to authenticate that an app reading the dbus interface is the<br>
>> > app it says it is.<br>
> kwallet solved that: Restricted access for executables. Encrypted<br>
> communication.<br>
> This can be added once a protocol is established.<br>
>> ><br>
>> >>> Another way to implement it would be to keep a synchronized set of<br>
>> >>> vcards on the system.<br>
>> ><br>
>> > Is this the same thing as Andy suggests? If so, see above<br>
>> ><br>
>> >>> Aleix<br>
>><br>
>> To simplify:<br>
>> You don't need much of a dbus API, just a directory where the vcards<br>
>> go for every plugin within the device config.<br>
> How does this simplify syncing to a remote device? How is this more secure<br>
> than dbus? How does this simplify writing a bidirectional adaptor for e.g.<br>
> KAddressBook?<br>
><br>
> Or is this meant to only ever work from phone to desktop? I for one would<br>
> really like this to work from desktop to phone or laptop too.<br>
><br>
> Are there more severe security implications than running carddav/ldap? What is<br>
> the threat model?<br>
<br>
</div>It's simpler because everything supports vCard.<br>
KAddressBook, Evolution, Outlook, GMail, the N9 mail client that<br>
doesn't exist anymore,...<br>
<font color="#888888"><br>
Aleix<br>
</font></blockquote></div><br></div></div></div>