The future of libfolks

What uses libfolks

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 (

    • 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

Projects/Folks/FutureMaintainership (last edited 2021-01-13 17:23:10 by AndreKlapper)