A portal for contacts

[matthiasclasen]

We could have a very simplified vcard-based API that works as a frontend for eds/akonadi, with a way to get the current contacts and an update signal.

[marcosps]

@matthiasclasen is this a good start point to contribute to portals?

[matthiasclasen]

Sorry, didn't see this question. I don't know enough about contacts apis to say how easy it will be. But you shouldn't let that stop you

[mjog]

From the GNOME side, it would be good to have a Folks backend that implements access via the portal, so apps already using Folks out of the box can keep on doing so unmodified when running sandboxed.

[mjog]

Hmm, so some people running Geary are having issues with EDS version mismatches between the package and the host, and I think the correct fix for that would be to have this portal implemented. If there was as suggested a Folks backend for it, then it should start Just Working™ with such a portal installed. For KDE apps, I imagine an Akonadi client API backend could similarly be added?

For Geary, the minimum requirements would be as follows:

• Represent contacts with VCard-like capabilities
• Represent a photo for contacts
• Search for a contact using some known details (email)
• Lookup a contact with an opaque ID
• Create a new contact using some known details (name, email)
• Display a contact's details
• Update a contact using some known details (favourite)
• Signals for contacts added/modified/deleted
• Performant for rapid/large number of lookups

The Create action would likely want to want to open the desktop's default contacts app (PIM) to allow the user to implicitly request permission to add the contact to their database - it's not saved until they click Create in the PIM. The Display action would similarly open the contact in the desktop's default PIM, so applications don't need to reinvent a complete contact viewer every time. I'm not sure how permissions for Update would be managed - can we assume once we have access to contacts we also have permission to update existing contacts?

The above assumes a single contacts database. Some apps like Contacts and Evo support multiple address books and so having a representation of these, as well as a way of listing/creating/getting the default/etc would also be needed.

I figure VCard despite being terrible is the least-common-denominator serialisation format and so should be used for contact transmission over the bus, but avatars could be sent as raw RGB (pixbuf?) data to avoid the Base64 encoding overhead, or maybe as a sandbox-accessible file handle?

@matthiasclasen Given EDS/Folks are not GTK APIs, would it still be fine to pull those deps in to xdg-desktop-portal-gtk? This wouldn't be a problem for KDE presumably, since the portal there seems KDE-specific and hence shouldn't have a problem depending on Akonadi.

@marcosps did you make a start on this yourself?

[marcosps]

@mjog unfortunately not, and right now I don't have time to invest in flatpak... So feel free to assign other developers to work on this task.

[matthiasclasen]

I've been liberal in using gnome plumbing in the 'gtk' portal backends. They try to fall back where possible, but if they functionality can't be provided without gnome, then just not providing that portal is fine too.

[mjog]

@marcosps okay, no problem.

@matthiasclasen Sounds good. Do you have any comments about the requirements above? Do they seem too expansive for a portal?

[matthiasclasen]

"Display a contacts details" seems out of scope for a portal. I mean, the portal wll certainly display a contact in some form, so the user can make a decision on whether to allow the app to use it or not, but displaying it is a side-effect of accessing it, not a separate portal request.

"Signals for added/modified/deleted" implies a permanent connection, which can be done (see various "Session" things we have), but makes everything more complicated. I might leave that out at first.

[mjog]

Okay, will keep that in mind, thanks!

[mjog]

I've put up a RFC for a possible public API for the portal over at #413 - comments welcome!