SMS app integration

[vertigo220]

The feature

QUIK (https://github.com/quik-sms/quik/) and Messages (https://github.com/PVOT-OSS/Messages), both forks of QK SMS, have a rudimentary blocking capability built in, with the option to select a different blocking manager. Unfortunately, none of the options are very good, and it would be amazing to have the ability to use SpamBlocker with them in this fashion, as requested in issues on their repos (quik-sms/quik#287 & PVOT-OSS/Messages#150).

Unfortunately, the issue on QUIK's repo has been open for 15 months, with several thumbs up, without so much as a comment from the dev, so it seems unlikely this will happen anytime soon, if ever. So I'm hopeful that maybe it can be done from your end, possibly by designing a bridge to interface with it, perhaps by adding it to those projects via a PR, or maybe by reaching out to them to see if they would be willing to work with you (and maybe each other, since the projects are forks and therefore very similar and would both benefit) to get this done. True message blocking done within an SMS app is something sorely needed.

[aj3423]

Interesting. This seems to be a non-standard interface defined by QKSMS, the two forks inherited from it:

• BlockingClient interface
• ShouldIAnswerBlockingClient implementation

There is a critical limitation, the interface only supports checking the number, the SMS content is completely ignored. While adding support for a new app is easy, changing the interface would require way more work on their side, and it would affect all existing blocking managers, they all need to change. They haven't replied for 15 months, I doubt they would make such an update.

[aj3423]

And I don't know whether those apps support features like QuickCopy, multi SIM handling, custom notification icons, sounds, etc.
It would solve one issue that currently it's a bit weird as messages and notifications are handled by different apps, but that's all it solves, the benefit is quite limited compared to the trouble.
My guess is that most users will definitely try the "Blocking Manager", but will eventually find SB more powerful and switch back.

[vertigo220]

Thanks for the quick response and looking into it. I'm probably way off, but I wonder if the interface could be manipulated. For example, set the SMS app to block 555-555-5555, then configure SB to work with the interface and feed it that number for anything that matches as spam. Main issue with that would be if that's the number the SMS app actually ties the message to, they would all get grouped together and you wouldn't know the real number (could be worked around) or be able to reply (much harder to deal with). But if that number would only be used for determining whether to block it or not and it would still be saved (in the spam folder) under the real number, then maybe it could work.

I'm hoping either the dev of the PVOT fork will give it more priority (nobody had opened an issue for it there before) or the QUIK dev will be more inclined with seeing your input. One can dream. I'd just like to be able to use SMS more, as I all but quit using it due to spam.

It would solve one issue that currently it's a bit weird as messages and notifications are handled by different apps, but that's all it solves

Maybe I'm missing something, but if it would let those apps know spam vs legit messages, it would allow them to be cleaned up. The problem with SB, as amazing as it is, is that it only prevents spam notifications (which is huge on its own). But the SMS app is still cluttered with garbage.

My guess is that most users will definitely try the "Blocking Manager", but will eventually find SB more powerful and switch back.

More likely they'll either realize right away those aren't very good and won't bother, knowing the power of SB, or they won't be aware of SB and will just suffer with those. Either way, it's only a partial solution to the problem of spam texts.

[aj3423]

I wonder if the interface could be manipulated. For example, set the SMS app to block 555-555-5555, then configure SB to work with the interface and feed it that number for anything that matches as spam

I don't follow this, could you explain this in more detail?

You're focusing on the number, but I don't think the number is important for SMS screening at all. In most cases, screening should be based on the SMS content. Currently we have regex, and with local AI coming soon, blocking by number will become completely obsolete.
So in my opinion, if their interface doesn't support SMS content, such integration will be completely pointless.

but if it would let those apps know spam vs legit messages, it would allow them to be cleaned up.

Good point, another reason to integrate this.

[vertigo220]

I'm focusing on the number because of what you said earlier ("There is a critical limitation, the interface only supports checking the number, the SMS content is completely ignored"). As I said, I'm probably completely misunderstanding, but I took that to mean the only thing QUIK/Messages gets from the external apps is the number, in which case they could be fed a specific number for any message processed externally (e.g. by SB) as spam. But now I realize that doesn't make sense, because if they just fed the messaging apps a number, they wouldn't be doing anything, so clearly I wasn't understanding your comment. Correct me if I'm wrong, but if I'm understanding correctly, the apps receive a message then send the number to the selected external app, which responds saying if it's spam or not based solely on that. So if they received a message and queried SB, SB wouldn't have much to go off of, just the number, no message content. However, if that's correct, there may again be a workaround. Since SB can see the messages (that's how it currently works), it would have access to the content that way. So it could just process the message on its own, as it currently does, and when queries by the messaging app, it would give its response of spam or not based on its own process, not just the number provided by the SMS app. That number could be used, if needed, simply to match a query with a message processed by SB.

[aj3423]

but if I'm understanding correctly, the apps receive a message then send the number to the selected external app, which responds saying if it's spam or not based solely on that. So if they received a message and queried SB, SB wouldn't have much to go off of, just the number, no message content.

Yes, exactly.

However, if that's correct, there may again be a workaround.

No, not going to work around that obsolete design, that protocol should be discarded for two reasons:

1. Essentials are missing

   • SMS content
     The SMS app has access to the message content and should provide it to the screening app.
   • SIM slot
     Some might want to block everything on SIM 2 if it's only used for data.

   BTW, I previously mentioned that all providers must update their apps, that was incorrect, changes are only required on the QKSMS side.

2. Provider names are hardcoded, making it hard to integrate new screening apps.
   Currently, when you tap a provider, if it's not installed, it redirects you to the play store. But what if the app isn't published on play store, SB is on FDroid only.

A better design would be:

• Define a protocol that both the SMS app and screening provider must implement
• In the SMS app, users should be able to list all installed apps that support this protocol and select the preferred one.

So if you find a better screening app, you can switch to it immediately without waiting for the devs to support it. AI just confirmed that this it is possible. Goole only provides call screening, there's no system level SMS screening, we should implement it ourselves, this is getting interesting, I'll run some tests later, maybe no SMS apps will implement this but I'll try it anyway.

[vertigo220]

Thanks. That all makes sense, and I agree with most of it, especially not limiting to hardcoded screening apps. Only thing I question is the part about requiring those apps to implement things on their end. I suspect the reason the current setup works at all is because it doesn't rely on the other apps to do anything special. Unfortunately, in my experience, if you design something that relies on others to do something for it to work, the results will be disappointing, as the odds of that work actually being done are not good.

So I'd say having a base implementation that at least works somewhat without any special requirements on the end of the screening app, while also having a more extensive implementation that has specific requirements that are standardized and fairly simple to do, would be best.

The other thought with all of this, and I'm not even sure if this is possible or something you'd want to do, would be to interate SB into those apps (or at least one of them), so instead of relying on an external connection protocol and counting on that being done, taking SB's code and merging it into theirs, so there would be a whole blocking options screen that would effectively be SB's options, and it would work from within. IOW, replacing the meager built-in blocking feature with SB. Though I imagine that wouldn't be even remotely a simple plug-and-play procedure and would be more work than you'd want to do, which would be very understandable.

[vertigo220]

I'd also like to say that even just using the numbers and not the message content is far better than nothing if, at least, the rules governing the numbers can be set up well. I use SB to block all message notifications, regardless of content, if they don't get passed by higher priority rules, and it works well. So even that base functionality is still worthwhile, and even that is lacking in these apps.

[aj3423]

interate SB into those apps

That's way more work for both sides, not worth the effort.

On second thought, the old and new protocols can actually work together, no big changes needed. They should be able to query by number only, and if they want, they can provide the message content and SIM slot to get more accurate results.

[aj3423]

It works, here's a demo project that contains both an fake sms app and a screening provider app:
https://github.com/aj3423/sms_screening_demo/releases/tag/test

The sms app:

The provider app:

Later I'll fork QUIK and try to integrate this.

[aj3423]

done, modified QUIK to support SB:
https://github.com/aj3423/quik/releases

It should work with this SB action apk:
https://github.com/aj3423/SpamBlocker/actions/runs/25855521718

The new protocol is fully compatible with the existing code and is actually very similar to the current version(almost the same). The only difference is that the new protocol allows any compatible app to connect, but the old one was restricted to those 4 hardcoded apps.
It is unlikely the QKSMS developer overlooked this, choosing to hardcode it must have been intentional. Anyway, my part is done, now it's up to them to integrate or not.

[aj3423]

Added to wiki:
https://github.com/aj3423/SpamBlocker/wiki/SMS-Screening-protocol

[vertigo220]

Thanks so much for this. It was already deserved, but I'll definitely be sending a donation your way. For the first time in years, I actually have hope of reclaiming my SMS app, which I've all but abandoned due to the ridiculous amount of spam texts. Especially since the QUIK dev has responded so positively. I'm glad you took this and ran with it, looks promising that it's going to pay off.

[aj3423]

That would be awesome, thanks~