telepathyim/telepathy-qt

Telepathy Qt bindings

telepathy-qt's Issues

Improve service Chan.I.ChatState API

The API of the interface is too primitive. The proper way to go is to use setChatStates that emits signals automatically (based on the diff to the previous ChatStateMap.

a6f99ea#diff-9668508553087a0327d2979cf288a691R435

Delayed DBus answer

We need to be able to delay DBus answers, but it is not possible with current design.
Some methods need to make a network request before complete the call.

Examples:

• Connection.Interface.Addressing: method GetContactsByURI
• Connection.Interface.ClientTypes: method RequestClientTypes
• Connection.Interface.ContactInfo: method RequestContactInfo
• Channel.Interface.Password: method ProvidePassword

Telepathy-Morse also needs to delay Connection.Interface.Requests CreateChannel() to get a native identifier of created group chat.

use GNUInstallDirs

GNUInstallDirs.cmake has correct default for all sorts of directories, it also handles things like lib/lib32/lib64/… automagically. Porting to this module is advisable, it makes things much more portable. It also has a mechanism for users to override these defaults if necessary, which is also one that can be used on all projects using this modules.

Using the CMAKE_INSTALL_FULL_* variables of this module in the generated .pc file is advisable as it is the only way that things will work if e.g. the include dir is placed outside of ${prefix}.

SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) supports

"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".

Can you add support for?

• SCRAM-SHA-1(-PLUS):
  -- https://tools.ietf.org/html/rfc5802
  -- https://tools.ietf.org/html/rfc6120

• SCRAM-SHA-256(-PLUS):
  -- https://tools.ietf.org/html/rfc7677 since 2015-11-02
  -- https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA

I add SCRAM-SHA-512(-PLUS): https://xmpp.org/extensions/inbox/hash-recommendations.html

Linked to:

• scram-sasl/info#1

Add initializer_list constructors to all generated list types

We need to adjust generator (qt-types-gen.py:302, qt-types-gen.py:563) to add
std::initializer_list<T> args, where T is array_of.

Expected diff in generated files:

struct TP_QT_EXPORT UIntList : public QList<uint>
{
    UIntList() : QList<uint>() {}
    UIntList(const QList<uint>& a) : QList<uint>(a) {}
+   UIntList(std::initializer_list<uint> args) : QList<uint>(args) { }

    UIntList& operator=(const QList<uint>& a)
    {
        *(static_cast<QList<uint>*>(this)) = a;
        return *this;
    }
};

Add support for ConnectionManager interfaces

https://telepathy.freedesktop.org/spec/Connection_Manager.html#Property:Interfaces

Hide Requests and Contacts from (Base)Connection public API

Add client-side API for Channel.Interface.RoomConfig1

Develop a specification of API to retrieve logs

API description

Use cases

Channel.Type.MessageArchive

Description

A channel type for logs retrieve. Inspired by Channel.Type.RoomList. Can be used to retrieve logs without opening channels for all possible targets.

Methods

GetMessages (a{sv} filter) -> void

Acceptable filter keys listed in FilterKeys property

Signals

MessagesReceived (aaa{sv}: array of Messages)

MessageHeader part:

• message-sender (u - Contact_Handle) The contact who sent the message. If omitted, clients MUST fall back to looking at message-sender-id.
• message-sender-id (s) The identifier of the contact who sent the message.
• scrollback (b) Must be presented and must be true.
• channel-type (u - Handle_Type) Must be presented.
• target-id (s) The identifier of the target. Must be presented.

Properties

FilterKeys — as

Possible (optional) keys:

• with-id - s (string) Identifier of the contact.
• with-type - (u - Handle_Type) Must be presented, if there is with-id key.
• start-timestamp - x (Unix timestamp)
• end-timestamp - x (Unix timestamp)
• start-message-token - s (Protocol_Message_Token)
• end-message-token - s (Protocol_Message_Token)
• limit - u (uint)
• offset - u (uint)

Channel.Interface.MessageArchive

Objects implementing this interface must also implement: Channel.Type.Text and Channel.Interface.Messages.

Methods

GetMessages (a{sv} filter) -> void

Acceptable filter keys listed in FilterKeys property

Once the method is called, it emits Channel.Interface.Messages MessageReceived (aa{sv}: Message) signals for received scroll-back messages

Properties

FilterKeys — as

Possible (optional) keys:

• start-timestamp - x (Unix timestamp)
• end-timestamp - x (Unix timestamp)
• start-message-token - s (Protocol_Message_Token)
• end-message-token - s (Protocol_Message_Token)
• limit - u (uint)
• offset - u (uint)

Links

Report on FreeDesktop.org

Exists API

XMPP

XEP-0136: Message Archiving
XEP-0313: Message Archive Management

Telegram API

messages.getMessages#4222fa74 id:Vector<int> = messages.Messages;
messages.getDialogs#6b47f94d offset_date:int offset_id:int offset_peer:InputPeer limit:int = messages.Dialogs;
messages.getHistory#8a8ec2da peer:InputPeer offset_id:int add_offset:int limit:int max_id:int min_id:int = messages.Messages;
messages.deleteHistory#b7c13bd9 peer:InputPeer max_id:int = messages.AffectedHistory;
messages.deleteMessages#a5f18925 id:Vector<int> = messages.AffectedMessages;

https://core.telegram.org/method/messages.getHistory
https://core.telegram.org/method/messages.deleteHistory
https://core.telegram.org/method/messages.getDialogs
https://core.telegram.org/method/messages.getMessages
https://core.telegram.org/method/messages.deleteMessages

BaseConnection::addChannel -> addChannels

"If additional channels are created as a side-effect of a call to CreateChannel, these channels SHOULD appear in the same NewChannels signal as the channel that satisfies the request."
(from http://telepathy.freedesktop.org/spec/Connection_Interface_Requests.html#Signal:NewChannels)

We should allow to add several channels with single NewChannels signal emission.

See also: http://telepathy.freedesktop.org/spec/Channel_Future.html#Property:Bundle

Add a documentation for Tp::BaseDebug class

Besides of the documentation, it would be good to also add an inline example, such as:

#include <TelepathyQt/BaseDebug>

static QPointer<Tp::BaseDebug> debugInterfacePtr;
static QtMessageHandler defaultMessageHandler = nullptr;

void telepathyDebugHandler(QtMsgType type, const QMessageLogContext &context,
                           const QString &msg)
{
    if (!debugInterfacePtr.isNull()) {
        const QString domain = QStringLiteral("%1:%2, %3")
                .arg(QString::fromLatin1(context.file))
                .arg(context.line)
                .arg(QString::fromLatin1(context.function));

        switch (type) {
        case QtDebugMsg:
            debugInterfacePtr->newDebugMessage(domain, Tp::DebugLevelDebug, msg);
            break;
        case QtInfoMsg:
            debugInterfacePtr->newDebugMessage(domain, Tp::DebugLevelInfo, msg);
            break;
        case QtWarningMsg:
            debugInterfacePtr->newDebugMessage(domain, Tp::DebugLevelWarning, msg);
            break;
        case QtCriticalMsg:
            debugInterfacePtr->newDebugMessage(domain, Tp::DebugLevelCritical, msg);
            break;
        case QtFatalMsg:
            debugInterfacePtr->newDebugMessage(domain, Tp::DebugLevelError, msg);
            break;
        }
    }

    if (defaultMessageHandler) {
        defaultMessageHandler(type, context, msg);
        return;
    }

    const QString logMessage = qFormatLogMessage(type, context, msg);

    if (logMessage.isNull()) {
        return;
    }

    fprintf(stderr, "%s\n", logMessage.toLocal8Bit().constData());
    fflush(stderr);
}

bool enableDebugInterface()
{
    if (!debugInterfacePtr.isNull()) {
        return debugInterfacePtr->isRegistered();
    }

    debugInterfacePtr = new Tp::BaseDebug();
    debugInterfacePtr->setGetMessagesLimit(-1);

    if (!debugInterfacePtr->registerObject(TP_QT_CONNECTION_MANAGER_BUS_NAME_BASE
                                           + QLatin1String("example"))) {
        return false;
    }

    defaultMessageHandler = qInstallMessageHandler(telepathyDebugHandler);
    return true;
}

void disableDebugInterface()
{
    if (debugInterfacePtr.isNull()) {
        return;
    }

    qInstallMessageHandler(defaultMessageHandler);
    debugInterfacePtr->deleteLater();
    debugInterfacePtr.clear();
    defaultMessageHandler = nullptr;
}

Wire up Account .Storage properties

Wire up org.freedesktop.Telepathy.Account.Interface.Storage properties, such as
StorageRestrictions, StorageIdentifier, StorageSpecificInformation and StorageProvider.
StorageRestrictions is wanted for TelepathyIM/telepathy-ofono#1 (account presence service needs to know StorageRestrictions, especially Cannot_Set_Presence.

Improve documentation for linux newbies

More clear documentation would help linux newbies to solve the problems.

Make QtWidgets to be an optional dependence

Remove Qt4 support

This will let us to fix tests (which are hardly maintainable with qt4) and just clean the code.

Default implementation for AbstractDBusServiceInterface::immutableProperties()

Two commits:
the first adds the default implementation, which returns empty map,
the second removes all override implementations, which return empty map.

Tag new release 0.9.9?

0.9.8 was released four years ago. The commits since then appear to be mostly bug fixes. Would be nice to have them in an official release.

Modernize the codebase (C++11)

Implement Connection.Interface.ContactBlocking

Remove own smart pointers

Remove own smart pointer classes or rationalize their existance.

• Tp::WeakPtr
• Tp::SharedPtr
• Tp::RefCounted

Remove deprecated API

• remove org.freedesktop.Telepathy.Connection.Interface.Capabilities
• remove org.freedesktop.Telepathy.Connection.Interface.Presence
  With this done, we will have no difference between connection.xml and svc-connection.xml, so may be it would be the right time to merge xmls (make service lib to rely on the main xml).
• clean channel-factory.h.

Missing dbus/dbus-glib.h

On NixOS, the build fails with the following error:

[ 62%] Building CXX object TelepathyQt/Farstream/CMakeFiles/telepathy-qt4-farstream.dir/channel.cpp.o
In file included from /nix/store/kjy4n27qjfyrw3ayxh7351hllwvp9g2k-telepathy-glib-0.24.1/include/telepathy-1.0/telepathy-glib/connection.h:33:0,
                 from /nix/store/kjy4n27qjfyrw3ayxh7351hllwvp9g2k-telepathy-glib-0.24.1/include/telepathy-1.0/telepathy-glib/account.h:31,
                 from /nix/store/kjy4n27qjfyrw3ayxh7351hllwvp9g2k-telepathy-glib-0.24.1/include/telepathy-1.0/telepathy-glib/account-channel-request.h:32,
                 from /nix/store/kjy4n27qjfyrw3ayxh7351hllwvp9g2k-telepathy-glib-0.24.1/include/telepathy-1.0/telepathy-glib/telepathy-glib.h:34,
                 from /nix/store/b7s2b8xjvi7gjfx928v7q655a2p3h3as-telepathy-farstream-0.6.2/include/telepathy-1.0/telepathy-farstream/channel.h:6,
                 from /nix/store/b7s2b8xjvi7gjfx928v7q655a2p3h3as-telepathy-farstream-0.6.2/include/telepathy-1.0/telepathy-farstream/telepathy-farstream.h:23,
                 from /tmp/nix-build-telepathy-qt-0.9.7.drv-0/telepathy-qt-0.9.7/TelepathyQt/Farstream/channel.cpp:31:
/nix/store/kjy4n27qjfyrw3ayxh7351hllwvp9g2k-telepathy-glib-0.24.1/include/telepathy-1.0/telepathy-glib/proxy.h:29:28: fatal error: dbus/dbus-glib.h: No such file or directory
 #include <dbus/dbus-glib.h>
                            ^
compilation terminated.
make[2]: *** [TelepathyQt/Farstream/CMakeFiles/telepathy-qt4-farstream.dir/build.make:68: TelepathyQt/Farstream/CMakeFiles/telepathy-qt4-farstream.dir/channel.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:8856: TelepathyQt/Farstream/CMakeFiles/telepathy-qt4-farstream.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

Nix stores each library in a separate directory in the Nix store. If I add the output of pkg-config --cflags dbus-glib-1 to build flags, it builds fine, it probably needs to be listed somewhere in the CMakeLists.

Telepathy-1.0 release

We need to decide if it will be better to add features and polish them (in spec 0.28 and TelepathyQt-0.10) before 1.0 release, or easy the development by dropping all the deprecated stuff and moving to 1.0.

Pros:

• it would be easier to merge 1.0 branch(es) now, than later.

Cons:

• We can not just bring TelepathyQt with 1.0 specification: we need telepathy-glib counterparts and we will have to support it. Namely, we need mission-control at the very least. Personally (@Kaffeine) I'm not familiar with glib and would prefer to rewrite everything in Qt, rather than develop glib-based code. About the other components: we also need telepathy-logger and I would like to rewrite it too to support multimedia content of messages. Maybe we can refactor Message class to let a client to operate with messages in a bit more abstract manner (logged/sent/received) with a possibility to subclass? This worth a yet another discussion thread (issue).

Links:
https://github.com/davidedmundson/telepathy-qt/tree/next (190 commits ahead)

Port to Python3

We use Python 2.7 for code generation. Port the scripts to python3.

See also: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal

Implement Channel.Interface.Subject

PropertiesChanged signal is missing in Client::DBus::PropertiesInterface

The modern approach to use the org.freedesktop.DBus.Properties.PropertiesChanged signal for property changed notification is not supported on the client side.

• Channel.Interface.RoomConfig1
• Channel.Interface.Subject2
• Channel.Interface.CaptchaAuthentication1

See also: TelepathyIM/telepathy-glib@5894586

Deprecate InspectHandles

InspectHandles removed in Telepathy 1.0 by commit

Remove InspectHandles
Identifiers are always given together with handles, so it must never be needed to inspect an handle.

This makes sense, so we need to:

1. Mark the method as deprecated in 0.27.x spec
2. Ensure that the method is deprecated at https://telepathy.freedesktop.org/spec/Connection.html
3. Deprecate the method in client-side bindings
4. Deprecate the method in service-side bindings
5. Maybe even provide default implementation via GetContactAttributes().

fatal error: gst/gstconfig.h: No such file or directory. Compilation terminated

Recently when I tried installing telepathy-qt for Debian without the apt sources packages, I encountered this error. I had to configure telepathy-qt from apt sources in the end. The exact ending of the error log was :

Makefile:141: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/athena/telepathy-qt-stuff/telepathy-qt-0.9.6.1/obj-x86_64-linux-gnu'
dh_auto_build: make -j13 returned exit code 2
debian/rules:20: recipe for target 'override_dh_auto_build-arch' failed
make[1]: *** [override_dh_auto_build-arch] Error 2
make[1]: Leaving directory '/home/athena/telepathy-qt-stuff/telepathy-qt-0.9.6.1'
debian/rules:12: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

The entire log for building the code is really long and given here

BaseConnection::(Adaptee::)disconnect should close channels.

The Disconnect() method of Connection should close all channel with Channel::Closed() and Connection.Interface.Requests ChannelClosed() signals emission.

Fix tests

Required #9 to be done first

Add support for One-Time Password authentication

Add Channel.Interface.OTPAuthentication

The interface is inspired by Channel.Interface.SASLAuthentication.

The description is outdated (written for Channel.Interface.PhoneVerification, which would be generalised to One-time password Authentication).

Use case

The interface would be exposed by telepathy-morse (telegram connection manager). Sign in process would be follow:

• User setups an account. The only required parameter is phone number.
• User sets presence to online.
• Morse creates an OTP channel:
  • VerificationStatus (Not_Started)
  • AvailableMethods("sms")
  • CanTryAgain (true)
  • DefaultPhoneNumber (the user phone number)
• ktp-auth-handler handles the channel:
  • Calls UseMethod("sms", "") and informs user, that verification code would be sent via sms (because it is the only available method)
    or
  • Show a button box with sms and call actions with the last one disabled.
  • Connects via DBus to KDEConnect signal about incoming sms
• Morse:
  • Makes request for sms.
  • Changes VerificationStatus to In_Progress
  • On server respond, Morse emits PasswordSent signal with details:
    • PasswordRegexp is a five digits after a space
    • SenderRegexp is "Telegram" or "TeleVerify"
    • CallTimeout (received from server. Something like 30 sec)
• ktp-auth-handler:
  • shows countdown if password details have "Expiration" property.
  • waits for KDEConnect incoming sms signal
  • on KDEConnect signal, ktp-auth-handler match sender with SenderRegexp and then match the message for PasswordRegexp. If both check succeed, then either automatically call Respond with the password, or, at least, insert it to the input line and waits for user action.
• Morse (optionally):
  • adds "call" method to the available method list.
• ktp-auth-handler:
  • shows buttons for all available methods ("Request an SMS", "Request a call")
• Morse (if two-factor authentication is enabled (which the most popular case)):
  • creates a SASLAuthentication channel...

Properties

VerificationStatus - Verification_Status.

Read only.

AvailableMethods - as (array of strings).

Read only, can be changed.

Method list depends on protocol and server. Well-known values would be:

• "sms" (the server would send a text message with a code to the "phone number")
• "call" (there would be a voice call to the "phone number" and someone (probably robot) would tell the code)
• Telegram also have "app" method, which means that the code would be send as a message in application. You can read it, if you have an already authenticated client.

---

CanTryAgain - b (bool)

Since v2

DefaultPhoneNumber - s (string)

Since v2

Read only, can be empty.
Predefined phone number, which will receive the message or the call.

---

Signals

VerificationStatusChanged(Verification_Status newStatus)

AvailableMethodsChanged(as newAvailableMethods)

Sometimes you can get a call only if you already tried to get sms and not received it yet (Telegram case).

PasswordSent(a{sv} details)

Possible optional keys:

• PasswordRegexp
• SenderRegexp
• Expiration
• CallTimeout
• ResendTimeout

---

Methods

UseMethod(string method, string phone) -> void

Activate the "method" to get a code on passed phone number.
The phone argument can be not associated with the account, or can be not permanent for some protocol/server/etc.

Probably this argument would be needed by Telegram CM to perform change of the user phone number.
Artificial use case can be phone verification to connect to some room in jabber, or (as we have "Account balance" interface), it is pretty possible to use phone verification to add some money to the balance. You send phone number, server replies you with a code, you send it back and ooop - you just confirmed a transfer of 5$ from the phone number balance.

Respond(string code) -> void

Try to complete verification with the "code".

Types

Verification_Status - u (uint)

• Not_Started
• In_Progress
• Succeeded
• Failed

Add immutable properties to BaseChannelConferenceInterface

https://telepathy.freedesktop.org/spec/Channel_Interface_Conference.html

Update client to 0.23.4.

It seems that the project is not ported to 0.23.4.

• ChannelGroupInterface::SelfContactChanged
• ChannelGroupInterface::HandleOwnersChangedDetailed

See:
http://telepathy.freedesktop.org/spec/Channel_Interface_Group.html#Signal:HandleOwnersChanged

XEP-0412: XMPP Compliance Suites 2019

Please add support of https://xmpp.org/extensions/xep-0412.html

Which replaces:

• XEP-0387: XMPP Compliance Suites 2018: https://xmpp.org/extensions/xep-0387.html
• XEP-0375: XMPP Compliance Suites 2016: https://xmpp.org/extensions/xep-0375.html
• XEP-0302: XMPP Compliance Suites 2012: https://xmpp.org/extensions/xep-0302.html
• XEP-0270: XMPP Compliance Suites 2010: https://xmpp.org/extensions/xep-0270.html
• XEP-0242: XMPP Compliance Suites 2009: https://xmpp.org/extensions/xep-0242.html