[RFC] Multi-IM support

[Neamar]

RFC: Request For Comment. This is something I have in mind, I'm interested in feedback :)

Problem statement

Back when I started KISS in 2012, things were simple: all of my friends were using SMS. A few of us, how fancy, were playing with the GTalk widget but its use on battery was terrible.

At this time, KISS support for contact was amazing. It made for a very fast app launcher, and contact launcher.

As time passed, more and more people started moving to new apps: Whatsapp, Hangouts, Viber...

As some point, we considered changing the default messaging provider on KISS -- the PR is still open, as it didn't feel like a good experience. If I change the setting to Whatsapp, I still need to remember which one of my contacts are not there. Cognitive load is still there, and that's the sign KISS isn't doing its job properly.

There were some suggestions, back then, to support multiple providers. I shut them down as I felt they'd be too hard to maintain, implement, and were too edge-casey. This situation got progressively worse and worse, and now it's time to admit I was wrong. Things will not get simpler, and picking an IM with someone feels like negotiating a SSL protocol: "I use Signal, Telegram, Whatsapp, Viber and messaging, in that order of priority, what about you?".

The dream of a unifying provider is still alive (heard about Matrix?) but let's face it, it won't happen any time soon.

Proposed solution

Let's make KISS multi IM-compatible, so that when you search for a contact, KISS remembers which app you like to use with this person, and shows a nice "message" button.

To do that:

• [ ] long pressing on a "message" icon on a contact will trigger a "Choose IM" popup (fast access)
• [ ] a new menu button, when long pressing on a contact, will also trigger a "Choose IM" popup (easier for discoverability)
• [ ] The "Choose IM" popup will list all supported messaging providers (see below) that are currently installed on the device
• [ ] Picking an app will associate this phone number with this app
• [ ] From now on, pressing the "message" button will open the app.

This means KISS can now be used to start any app, or start any conversation. Back to the good old times, where one didn't have to search for an app, look at its splash screen, search for a given conversation and finally start typing.

Supported messaging providers

One of my main reason for not wanting this feature previously is that I believe KISS should be agnostic to the current popular apps. SMS is good, and agnostic, but most people prefer other apps.

KISS is not going to support every single messaging app on the Play Store or fdroid.

To be considered for inclusion, an app will need to meet those criteria:

• More than 50M users reported on the Play Store. This means Whatsapp, Viber, Telegram, Signal qualifies. I'm probably missing some, but those are the ones popular where I live (Europe).
• Supports launching the app to a given contact from a phone number. This is a requirement to integrate nicely with the current architecture. I know this means Facebook Messenger won't work out of the box (they only seem to support Facebook ID). Maybe someone can come up with a nice way of reading the Android contact information to use this data, but I don't use Messenger and it won't be included in the initial release.

For the initial release, I'm planning to integrate SMS, Whatsapp, Telegram and Signal.

If you have any feedback or comment, I'm interested :)

[Fbald]

Great news, I hope it will arrive in an update soon so as to become much faster the Launcher

[Fbald]

I can't understand how Kiss Launcher history works. In the settings I have 9 apps in the history but I don't see them inside the app. How can I see them?

[daffydock]

I think this is a great idea. I like the implementation. I for one, think that Signal is a great inclusion. Since in the end, Signal (as well as many others) can also be used as SMS clients as well. Albeit not all of them can.

I mean, as of right now, since Signal is my main messaging app, thus pressing on the conversation button just opens Signal.

[Fbald]

So the idea would be to just implement Signal?

[marunjar]

hi @Neamar , i hope it's ok if i give my 2 cents here but this is something i was thinking about for a long time now. I also have some contacts that do no use my preferred IM app and for these default sms app simply doesn't work. It's a little different approach from your proposed solution but please take it as another option for discussion. Also this already goes a little further so one may add other contact options too, like e.g. email.

Also if any help is needed for implementation or testing i can give it a shot.

Proposed solution:

My idea heavily depends on how android's contact provider work You can have a look here https://developer.android.com/guide/topics/providers/contacts-provider

1. there is a always a contact with some basic infos for contact, name, photo, ...
2. then there are raw contacts: these may be used to determine different accounts of IM which are in use. Every messaging app i can tell (signal, telegrag, whatsapp, ...) already adds raw contacts here.
3. then there is data, this is where phone number, mail address, whatsapp data, etc. is saved. So there can be lots of entries that just needs to be loaded and shown in KISS like other contacts. This also has a mimetype, so we can find IM rows easy in this table. With this information we can tell if any contact uses phone, signal, whatsapp, ... and we also have everything to show additional contacts for different mime types.

So in detail, for IM there will always be data entries with mime type CommonDataKinds.Im.CONTENT_ITEM_TYPE, similar to phone numbers. For starting the appropriate app there are also values in data columns: Im.PROTOCOL_CUSTOM and Im.PROTOCOL. These should be enough to create an intent to start messaging when clicking on entry as it's also done in aosp contacts app (https://android.googlesource.com/platform/packages/apps/Contacts/+/refs/heads/master)

So if we load phone contacts, im contacts and maybe sometimes also other contacts (i think there were already request for mail) these are shown in KISS as they are. Maybe instead of phone number under name we can show some other info provided for contact, e.g. the label of IM data row (Im.LABEL) or mail address for mail contacts. Name itself should be fetched from topmost contact, other infos (like nick) can be fetched from other raw contacts or data as needed, this shouldn't be changed.

For KISS itself this means that more contacts are shown, not only the ones with phone numbers:

If it's a phone contact, it is shown as is. If it's an IM contact it is shown with matching icon from app (raw contact) instead of message/phone icon. If there are multiple IM apps they all add their contacts, we just show it. If there are different contacts (IM, Phone, ...) for same person, relevance will do it's magic and most used contact will be prioritized like we know and love it from KISS.

Supported messaging providers:

All of them will be supported :) For KISS it shouldn't matter any more which IM apps are installed as simply data from contacts is used. I also think we can trust in all apps that they add contacts in a proper and functional way because this is needed for contact app too. So if the protocol changes for a specific app this will be handle by the app itself by changing contact data. If there are contacts that doesn't use preferred IM any more, the contact will be removed by the app itself and therefore is not available in KISS any more.

If this is thought a little further it should be easy to add additional contacts if necessary, e.g. also mail contacts can be fetched and shown.

The only additional thing i can think of is some filter setting to exclude all contacts of one app/type if one doesn't want to find any contacts from e.g. WhatsApp or just doesn't want to see any mail addresses or maybe even phone numbers? Who knows?

I hope my idea is somehow clear, if there are any other questions just ask, i'll try to clarify these as good as i can.

[lokogan]

Please consider adding support for Zalo—over 100M downloads and popular in Asia. It's also phone-number-based. Thank you. https://play.google.com/store/apps/details?id=com.zing.zalo

[Neamar]

@marunjar thanks a lot for your feedback, I actually thought about that too because it felt like the best option.

I remember trying something similar last year with Whatsapp https://github.com/Neamar/KISS/pull/1408.

I don't think I understood the protocol well enough, and I had too many issues with this to keep it as a reliable solution, but this might be my implementation only.

Now, about your proposed implementation. You mentioned that you'd be able to help, that could be a good boost because I don't feel competent enough to do this. I only do Android for side-projects, and the Android contact provider has always been a nightmare for me.

So if you can help and have time to work on this, then I'd be happy to talk some more and flesh out the solution before we start, I like your proposal but I think a couple things could be improved too.

If you don't have time, that's perfectly understandable! I'll see if I can make use of the custom Im.PROTOCOL and come up with something less advanced but that still solve the main issue.

[Neamar]

(seems that telegram doesn't add additional RawContacts)

[marunjar]

These providers are sometimes really crappy 😉 I once tried to implement my own sync adapter for calendars and contacts for Jelly Bean, but i'm no pro either with these. Android development is just a hobby of me too.

Currently i mostly have time on weekends, so i can try to implement this. But some guidance would be necessary then as i don't know whole KISS codebase in deep.

Of course we should talk some more to flesh out the solution, as using mimetypes was just a rough idea. The clearer the requested functionality the easier will be the implementation later on. Or at least it will be a little more straight forward without tinkering around.

Should we discuss it here or do you prefer any other channel for chatting?

(seems that telegram doesn't add additional RawContacts)

I just checked again, i have some raw contacts with account_type = org.telegram.messenger and also data for telegram contacts. Maybe this is dependent on telegrams synchronization settings?

[Neamar]

I guess that's because I only have TelegramX installed on this device. Might be the issue.

Option 1

I wonder if it's worth having multiple line for each contact. The current design in KISS has one line per phone number, but I think it might still make sense to go for the same solution mentioned earlier: replace the "SMS" button with something customisable for each contact, and assume each phone number has one preferred way ot messaging it. So +123456 will be set to telegram, +123457 will be set to Whatsapp and +123458 is still SMS. The list of available IMs will be pulled from RawContacts.

• Pros: simple idea, keeps "one phone number = one line" logic
• Cons: enforce a certain way of doing things (only one IM per phone number, seems reasonable for me but not for everyone). Only supports IMs that use the phone number (byebye facebook messenger)

Option 2

Generate one line per raw contact. Contacts icons would still be shared (I think), and then KISS algorithm will surface the most relevant IM each time.

• Pros: feels more KISS. That's how we deal with app shortcuts already. The same phone number can be reached with different apps.
• Cons: search will be slower, probably at least twice as slow, because we now need to iterate over a longer lists of potential results. It's not uncommon for users to have up to a thousand contacts, so if each of those contacts is on both phone + Whatsapp or Telegram, that's now 2000 results that have to be searched for potential matches. It also potentially adds more noise to standard search results and requires adding more settings to potentially disable some IM providers.

I'm not sure yet which solution has my preference, curious to hear more from others!

[marunjar]

What about implementing all options and make it configurable? If one of these options is implemented, it shouldn't be much effort to add the other one too.

Option 1

Nothing to add here.

Option 2

Search speed indeed may be a thing, this has to be configurable.

In my opinio by default no additional rows should be shown but if one wants to enable additional contact rows why not? In this case it also should be clear to anyone that enabling IMs will slow down search. This will also allow IMs that do not use phone number.

Option 3

If either option 1 or 2 should be chosen is not an exclusive decision. Let users set preferred IM per contact. Also let user select additional IM rows like in option 2. Then simply exlclude the additional IM rows for contacts where IM is already set as default because of option 1.

I alread had a look at sources and i think main work can be done in ContactsPojo, LoadContactsPojo and ContactsResult. Please correct me if i'm wrong, but if ContactPojo is extended by simple IM information all options should be possible as we have then following combinations:

1. phone number is set, IM is not set: this is a contact as it is now, call is possible and message uses SMS
2. phone number is set and IM is set: contact similar as to how it is now, call is possible but instead of SMS the IM of choice is used
3. phone number is not set, IM is set: a new contact line for IM only, call is not possible

[Neamar]

I don't know, not sure how I feel with having multiple ways of doing the same thing--doesn't seem "KISS" to me! Curious how other feels here.

You're right for the files that would impacted, but we'd need to "duplicate" contactpojo (once per im) to be able to return it and rank it accordingly, depending on previous history.

[Neamar]

I think what I question most is if it makes sens to display multiple IMs per contacts. My use case is pretty strict, one IM per contact, sometime two with SMSes, but it's really uncommon. I think most of my friends have the same workflow, so I wonder if there is any point adding hundreds of IM lines when we know a single one will be used anyway.

[marunjar]

Would be really interesting what others think about this and what use cases they have. I think having options here doesn't conflict with KISS principle, this should be up to everyone himself.

I was thinking a lot about my own use case lately and this is how i would use it:

• I don't have that many phone contacts, currently 348

• My default app for sms is signal, this covers sms and all contacts that use signal (getting more lately 😄)

• Then i have 40 telegram contacts, that do not use signal too.

• For these 40 contacts i'm still not sure how IM will fit my workflow best. On the one hand I can set preferred IM by long press, this will not be much effort for about 5 people i contact regularely. But it would be much more to setup for all 40 contacts. So if i decide to use telegram for all of these contacts, i think i'd prefer to just enable showing of all telegram contacts too. As already said i'm not sure which of these options i'd prefer here, maybe i just have to try different options here for a while.

Lastly i have two other things i use pretty often and that can be done by showing multiple lines only, i think.

• i use signal calls whenever possible (depends on wifi condition, foreign county/roaming, ...) Would be really cool if these could be shown too. It's not IM directly, but just another data row of contact that could be shown.

• i use email: pretty old school, i know, but i really use it a lot. This is also just another data row of contact that could be shown. Also this is something that has been requested several times now: https://github.com/Neamar/KISS/issues/647 https://github.com/Neamar/KISS/issues/1045#issuecomment-432712996 https://github.com/Neamar/KISS/issues/1656

Of courcse, if it all doesn't work out as expected, i'm open up to change or remove it entirely 😉 These are some changes that shouldn't be put into production right away. So one may give them some time to develop.