The future of libfolks

What uses libfolks

• gnome-contacts, extensively

• gnome-maps, for listing people’s addresses

• gnome-shell-mailnag

• Empathy (totally deprecated)

Is there still a need for libfolks?

Which backends are still relevant?

• bluez: Potentially, for those who have contacts on their phone which don’t come from a WebDAV server
• dummy: Testing backend
• eds: Yes, definitely
• key-file: Internal backend
• libsocialweb: Nope, dead
• ofono: Potentially, for the same reasons as BlueZ
• telepathy: Nope, dead in most cases
• tracker: Nope, dead in most cases

So essentially libfolks is now just a wrapper around EDS. However, it still serves the useful purpose of linking contacts from multiple address books. For example, I still have contacts from my personal and work address books who it would be good to link together.

What is its current maintainership status?

I am AWOL. I am reviewing patches, but otherwise not actively maintaining, developing, or doing timely releases. This is unlikely to change.

What is fundamentally wrong with libfolks?

• High memory usage
• Unmaintainable programming language (Vala)
• Lack of API stability
• Awkward C API in places (use of libgee generics)
• Library rather than a daemon (debatable)
• Need to abstract over the behaviour of all of the backends; denies gnome-contacts access to the lower level functionality in EDS, for example
• We can’t hit the goal of 40000 contacts

What is fundamentally right with libfolks?

• High-level API
• Linking code and interfaces are generally fairly well thought through
• A reasonable amount of attention paid to things like naming, address handling, etc.
• Library rather than a daemon (debatable)

What is likely to happen in future in the contact management space?

• Large social networks are not going to get any smaller
• We might eventually get a federated chat system which sticks around for more than a year (Matrix?)
• Looking at phones, they seem to have given up on linked contact lists; every chat app is a silo, contact lists are pre-seeded using phone numbers
• LDAP/WebDAV/Google Contacts are not going to go anywhere
• New contact stores may appear, but will probably provide a standard WebDAV interface for compatibility with other systems

• That said, things like Mattermost now exist, and don’t provide a WebDAV API (https://api.mattermost.com/#tag/users%2Fpaths%2F~1users%2Fget)

  • Where in the stack do we ideally want to add support for them? EDS, or folks, or somewhere else?

What are the options?

1. Merge libfolks into gnome-contacts and maintain it there, trimming bits of it and eliminating a lot of the backends; other users of libfolks are on their own and port to EDS
2. Kill libfolks entirely, port gnome-contacts and other users to EDS
3. Keep libfolks alive, find a new maintainer, drop the dead backends, try and improve memory usage (we pre-create a lot of mostly-empty hash tables) and C API situation (probably by porting from Vala to C)
   • Need to port to C
   • Need to support lazy-loading of properties
   • Need to minimise pre-emptive creation of hash tables/maps/etc. and leave them as null by default (most contacts are sparse)
   • Need to eliminate duplication of every property in 3 layers: EContact, Edsf.Persona, Folks.Individual
     • In the common case of a single EContact mapping to a single Folks.Individual, could we just allow the use of Folks.Personas in stead of Folks.Individuals?
     • Would need to adjust some of the Folks.Individual-specific properties; would need some more detailed planning
     • Probably would result in API breaks, but with the small number of users of libfolks, that’s OK