Ring-KDE in kdereview

[Elv1313 .]

Hello, this I hereby announce that Ring-KDE, a secure communication client for
the GNU Ring / IETF SIP protocol, is attempting to move to Extragear (from
the playground). Below is a detailed email, but there is a video and screenshot
gallery that should give you a good enough idea if you don't have time to read.

## TL;DR

Video and screenshots:

https://imgur.com/a/ocrod

## What is Ring KDE 3.0

Ring-KDE is a software phone and multimedia platform based on the GNU Ring
network. It is the successor to SFLPhone-KDE and a full rewrite of Ring-KDE 2.0
(that was just a rebranded SFLPhone). It is a Kirigami/QML application designed
to work on both desktop and phone. The rewrite is sponsored by Blue Systems with
the intention of providing capabilities equivalent to Skype to the KDE Plasma
desktop. The goal of the project is to provide superior platform integration
with both the Plasma mobile and desktop form factors. A quick summary of the
features:

 * Uses a fully distributed system by default with options for federation and
   central server available.
 * Use open standards where possible instead of re-inventing the wheel
 * Interoperate with thousands of existing services, including bridges to the
   real phone network (PSTN) and various protocols (XMPP/Matrix/SMS/etc)
 * Make audio and video calls
 * First class contact and "people" integration instead of phone numbers
 * All data is stored locally in standard formats
 * Has plugin supports to integrate with other systems (such as Akonadi/Kontact,
   macOS AddressBook or Gnome evolution).
 * Based around the multimedia timeline paradigm

## History recap

 * The original version was released in 2004 (called sflphone)
 * Ported to KDE4 in 2009 (called SFLPhone-kde)
 * Gets into KDE playground in 2012
 * 1.4.3 was the last release for KDE4 (and SFLPhone) in 2014
 * Renamed Ring-kde and LibRingClient/Ring-LRC in 2014
 * Ring-KDE 2.0 was released in 2015 with distributed accounts and KF5 support
 * My employer refuses to let LibRingClient lives in KDE, begin moving to GNU,
   I resign.
 * 2015-2016: Continued development, but the Ring-deamon and Ring-LRC dependency
   undergo heavy development and their API/behavior change so often I cannot
   release anything. I slowly give up trying to keep up with all the
API changes.
 * 2017: BlueSystems begins to sponsor a new round of development, the QML
   rewrite begins
 * 2017 (August): Declare it stable enough for an alpha release, moves into
   KDE review. It was then decided to do another round of development so I never
   announced it.
 * 2018: The new development is done, it looks much better and has support for
   a special kind of AppImage.

## Why rewrite

SFLPhone-KDE was as good as it was ever going to be. It was IMHO the most
complete and well tested free VoIP client on any platform. Beside some issues
with non compliant providers (looking at you FRITZ!Box) it was very stable.

However the world moved on. Skype itself evolved into a social app and so did
the target users. When SFLPhone became GNU Ring, the scope changed, but Ring-KDE
did not. Ring-KDE 2.x is/was a soft phone claiming to be something else. The old
user interface was optimized and battle tested for office usage with high call
rate and dispatching in mind. Social apps, on the other hand, are optimized for
regular users talking to a smaller group of close friend. The UX could not be as
different, so salvaging the old UX with more option would not have been a good
idea.

There's also the fact that I have Plasma phone in mind and QtWidgets is ill
suited for touch. I prefer coding with QtWidgets, but it was the wrong tool for
the job and as there is no way to port, I had to rewrite. Given all the business
logic is safe and sound in its own library, only the pure GUI code had to be
recreated.

## General design

There is a bunch of protocol libraries deep below like pjproject (IEFT SIP) and
GnuTLS (IETF x509 / TLS).

On top of that a Ring protocol and hardware library called GNU LibRing available
either as a client/server (DBus/RESTful) or as a C++ library.

On top of that there is the LibRingQt middleware, it adds all the business logic
to handle "people" instead of the low level protocol. It supports both the
client/server and library modes of LibRing. It also exposes hundreds
of Qt models
and stateful objects for QML to consume.

Finally, on top of *that* is the QML/Kirigami2 client. It only has GUI code and
virtually no logic. This is what's presented here to move into KDE extragear.

The configuration dialog is still based on QtWidgets from the SFLPhone era. It
isn't a good thing as it makes the GUI hard to configure on mobile. However it
is mature code and works well, so rewriting it isn't a very high priority
compared to other aspects (see the roadmap below).

## What is LibRingQt and how does it relates to its various other name and forks

Quick timeline:

 * 2004: First commit (mixed with Qt3 GUI code)
 * 2009: Major refactoring for KDELibs4 (still mixed with GUI code)
 * 2011: Split the GUI and logic, LibQtSFLPhone is born
 * 2013: Major refactor for QML/PlasmaActive/UbuntuSDK (with Qt model/view)
 * 2014: Renamed LibRingClient / ring-lrc
 * 2015: Major expansion to support other platforms (GTK/macOS/Android)
 * 2015: It gets kicked from KDE because without me pushing back, they start
     moving to GNU and otherwise take "black box" decisions.
 * 2015: I leave my job working on it
 * 2017: The co-author also leaves, the new maintainer wish to remove the Qt
     supports. Upstreaming patches becomes impossible.
 * 2017: (july) I soft-fork and the 2 codebases slowly diverge as they remove
     Qt models while I double down on them.
 * 20??: Finish to port/cleanup the API and code to Qt5 (6?) and C++14 (17?) and
     attempt to move the code back into KDE. Maybe split into smaller
     components and get rid of a couple layers of abstraction.

Right now the code base is *very* complex and has many workarounds for Qt4 lack
of C++11 support and other platform support. Some parts could also be spitted
into smaller libraries or share code with KDEPIM (once again), such as the vCard
format support or meta collection support. With the support for other platform,
the dependency on Akonadi was dropped, so some code duplication began to crawl
into the codebase. Until the currently fragmented KDE PIM API landscape gets
clearer, it is also unfortunately still going to require those components for a
while.

As for the fork, I still talk to them and agree for their point of view what
they are doing (remove Qt) makes sense given the current clients are mostly
GTK, HTML5, Android/Java and macOS/iOS. On the other hand, writing complex and
business logic intensive QML applications requires strong C++ QML bindings so no
logic ends up being written in JavaScript (and become unmaintainable). It isn't
a "screw them" type for fork, but rather diverging interests that makes
sharing code more trouble than it's worth. It is also impractical to try to
have a Qt overlay on top of the shared library because they don't plan to freeze
the API/ABI and still ships some Qt code that would conflict with the newer
version of those classes (from a QML binding point of view).

So the plan is to slowly modernize the codebase. It isn't a priority and as the
code is very mature and battle tested in production. Going slowly is a better
idea than breaking everything. On the other hand, it means the API will change
a lot, so getting it back into KDE at this point makes no sense given it breaks
the KDE Libraries stability guidelines with every commits. Most of the code is
also still C++98/Qt4 in appearance and does many things "the old way". Finally,
my former employed never prioritized documentation and proper unit tests, add
the mind boggling complexity of some of the code and only 2 people on Earth
can understand how the whole thing works. As-is, it has little value as a
shared framework. Hopefully this can be worked on.

I plan to release versions alongside each Ring-KDE release (bumping the
so-version) and otherwise require the git master version for the Ring-KDE
master branch. The release tarball will include the library as a
CMake `add_subdirectory` until the API/ABI is frozen. This isn't a perfect
solution, but as I don't want to merge the 2 repositories, it's a good enough
compromise for a while.

## Known issues

 * Corners were cut during development and the performance and resource usage is
   sub optimal (it uses an abusive number of QML elements and has some property
   loops causing higher than expected CPU usage). Now the the basic features
   are done, I consider this the highest priority.
 * tosky greatly helped improve the i18n situation, but it's still quite bad
 * The documentation is outdated (~KDE 4.2) but still useful-ish enough
 * There *is* tests, but they are so all over the place that running them on
   build.kde.org is currently impractical/impossible
 * The QML code underwent multiple series of changes / prototyping to make it
   look pretty and there is some leftover to cleanup.
 * SFLPhone-KDE used to require a lot more memory than really required.
   LibRingQt uses more and more QSharedPointer to avoid keeping some models in
   memory. However QtQuick2 use of them is really, really buggy and the
   workaround to avoid crashes cause crashes of their own when quitting.
   I see this mostly as a Qt problem for now unless I missed something
obvious, so
   I am not willing to implement huge workarounds on my side.
 * The next few version will probably require the latest release of
   KF5::Kirigami2 and KF5::qqc2-desktop-style to work properly since Ring-KDE
   is among the first complex multimedia application using them and hit
   some bugs / missing features.
 * Since the 2 most important dependencies have unstable APIs, it can be
   confusing to pick the right commit to compile Ring-KDE. Only time can fix
   this and AppImage/Flatpak/SNAP will be provided. KDenLive suffers from the
   same limitation since forever. It sucks, but it's better than having
   monolithic projects with 5+ million lines of code.
 * build.kde.org support was there, but it's down since Ring-KDE moved into KDE
   Review. I got a pre-commit CI with Clazy/Krazy/ScanBuild/Coverity/
   ASan/HeapTrack/Clang-tidy/GCC_Warning/CLang_Warning/GCC_AppImage/
   CrossDev_AppImage jobs. Given the dependency commit mismatch problem
   highlighted above, build.kde.org can only compile LibRingQt and Ring-KDE,
   it won't attempt to build the full stack, so the tests cannot be executed on
   the KDE CI. It would waste tons of CPU cycles and realistically almost
   always fail. (see roadmap).
 * Setting message as read/unread is broken / not fully implemented. It isn't
   an high enough priority at this stage.
 * The (+) Button to add contact field isn't doing anything yet. I left it there
   so some UX decisions look a little less arbitrary.
 * The contact adressbook tab is very minimal, the bookmark and history ones
   (hidden by default) are not usable at all. Keep in mind that they are
   redundant for 95%+ of the potential use cases (due to the timeline panel)
 * The account list in the setting (and managing accounts in general) is a bit
   broken. As the code is going to be rewritten for QML, I don't care all that
   much. It isn't necessary for 99% of users as the 2 most important aspect
   (creating new Ring account with the wizard and creating SIP accounts) work.
   This really, really needs unit tests.
 * There is plenty of scary bugs upstream in LibRing. Not much I can do about
   it. There is many crashes on ARM, random runaway CPU usage requiring restart
   and general lack of robustness to events such as temporarily losing access
   to the internet. Patches sent upstream by 3rd parties are very often ignored
   so there is little point for me to try to fix any of those.
 * The plasma phone version and generally the ARM version is very buggy and
   far from ready for dogfooding
 * Video is known to cause crashes with buggy drivers + hardware accelerations

## Mid term roadmap

 * Fix issues that arise from the review
 * Release 3.0
 * Do a large round of optimization to fix the CPU usage issues
 * Improve CI support and general testability before it is too late
 * Release 3.1
 * Do a catchup round to sync the feature set with the Gnome client
   * Enable contact requests (partially implemented)
   * Implement the file transfer GUI (todo)
 * Rewrite the configuration dialog in QML (todo)
 * Release 3.2

## Long term

It isn't very clear yet given once I activate file transfer and contact request,
it will be "done" as far as basic features go. However it leaves plenty of way
to make it more useful:

 * Implement support for emails and other media for the timeline
 * Support more open protocols such as POP3, iCAL, (Web|Card|Cal)DAV and
   maildir to improve interoperability with existing infrastructure
 * Better sync between mobile and desktop versions
 * Better support multi party chat even if it isn't and wont become the primary
   use case of the app.
 * Make sure bridges for other protocol work fine and officially support them.
 * Keep improving security with better sandboxing, a modular design, hardening
   and better runtime threat detection / mitigation.
 * Add more tests, including various 3rd party service providers

## Try it!

I strongly suggest using the AppImage instead of trying to compile it for a
quick test. GNU Ring is a complex beast to get going. Even when you *think* you
compiled it, dependency version mismatch are known to cause runtime bugs. On
top of that, upstreams view the project as bleeding edge, so they tend to apply
patches on everything rather than workaround their packaged dependencies
limitations. The LibRing API also has a tendency to break its API without
prior notice and/or bumping the so-version.

**The AppImages are stored on github until the review ends: this is temporary**

x86_64 (for regular use):
https://github.com/ring-project/ring/releases/download/3.0.0-alpha3/ring-kde_3.0.0-alpha3-x86_64-X.appimage

x86_64 with dummy/demo data (do *not* create an account, press skip):
https://github.com/ring-project/ring/releases/download/3.0.0-alpha3/ring-kde_3.0.0-alpha3-x86_64-X-demo.appimage

If you *want* to compile this, use the Docker.io automated builders:

x86_64:
https://github.com/ring-project/ring-kde-appimage-builder/tree/gentoo_base

armv7ahf:
https://github.com/ring-project/ring-kde-appimage-builder/tree/arm7

(find&replace the name for aarch64-linux-gnu for ARMv8)

Report bugs at https://bugs.kde.org/enter_bug.cgi?product=ring-kde&Bugzilla_restrictlogin=on&GoAheadAndLogIn=Log%20in