Support username-only contacts

[benjaminbhollon]

None of my contacts I know the username of but not the phone number show up in scli. I can receive messages from them but they show up as UNKNOWN CONTACT and I can't send messages.

signal-cli itself supports those contacts, so my guess is that scli identifies contacts by phone number instead of the ACI signal-cli lists?

[exquo]

This is a real problem! It is caused by signal-cli's DBus methods not listing the "UUID-only" contacts (upstream issue). To resolve this, either signal-cli would have to make the necessary modifications to its DBus interface, or scli will need to switch to using another interface, e.g. signal-cli's JSON-RPC (a feature request already exists). The fixes to signal-cli's DBus issues have not been forthcoming for a while now. So scli will likely need to transition to using JSON-RPC instead. I can't put an ETA on it yet, as it'll entail replacing large chunks of existing code; but the current issue, along with the other dbus-caused blockers for scli, will put it high on the list of priorities. In the short term I'll try to make workarounds, at least for sending messages to UNKNOWN CONTACTs.

[benjaminbhollon]

Ah, I wasn't aware there was an upstream component to this. That makes sense.

[ziman]

I've had a brief look into it. It seems that scli calls org.asamk.Signal.listNumbers, which it iterates over and incrementally builds a list of contacts. Uuid-only contacts will not have a number and will be missing from the returned array. An alternative could be changing that to org.asamk.Signal.listIdentities, which seems to contain all contacts, whether or not they have a number. This already exists so there's no need to contact upstream.

Of course, then a lot of the internals of scli will need adjustment because you'd pretty much change the primary key of all contacts. The contacts_dict[phone_num] will have to be transformed into contacts_dict[contact_id] and numbers would have to be retrieved from the dict instead of just using the identifier, which is a pretty extensive change but also feels fairly straightforward.

I expect that the most difficult part of this change would be the UI/UX, as always.

[exquo]

It seems that scli calls org.asamk.Signal.listNumbers
An alternative could be changing that to org.asamk.Signal.listIdentities

Unfortunately, the org.asamk.Signal.listIdentities method returns extraneous IDs; from AsamK/signal-cli#1508 (linked above):

The listIdentities (both the dbus method and the CLI subcommand) return non-contact entries among its output (e.g. members of the groups that I am a member of, but who are not in my contacts and with whom I don't have 1-on-1 chats).

The relevant DBus method is unlikely to be added upstream. So the real solution would be to switch to one of its other interfaces, like JSON-RPC, which does have methods for listing the contacts' UUIDs.

The contacts_dict[phone_num] will have to be transformed into contacts_dict[contact_id] … which is a pretty extensive change but also feels fairly straightforward.

That part is indeed straightforward: the contacts_dict does not really care whether its keys are UUIDs or phone numbers. It might amount to a simple terminology change in the code, from phone_num to contact_id.

On the other hand, the switch from the DBus interface to JSON-RPC would be fundamental to scli's interaction with signal-cli's daemon.