Vinetos / Tranquille

📲🚫 Block unwanted calls effortlessly. Supports regex. wildcard and open-source bans-lists. Fork of YetAnotherCallBlocker.
GNU Affero General Public License v3.0
24 stars 2 forks source link

"Pluggable" sources #13

Open Penaz91 opened 2 months ago

Penaz91 commented 2 months ago

This is a weird idea I've been thinking about. I wonder if it's possible to create a single way to memorize numbers onto the local Database from an online source and eventually have a plugin system of sorts that allows for many different sources to be selected.

This way the efficacy of the app is increased and the user can choose whether they want to use a certain service or not.

This may also open the door to a specific version for FDroid where no "nonfreenet" services are included (if there are any).

Hopefully I managed to explain myself somewhat clearly.

Vinetos commented 2 months ago

I think I see want you mean : a way for the user to selected and subscribe for phone databases (managed by external services) and allows these database to automatically reject some calls based on their stored rating ?

Is there any service that you may know that could be a source as tests for the app ?

Penaz91 commented 2 months ago

Essentially yes.

I'm pretty sure YACB already uses "shouldianswer" as an external service (which I find actually pretty good). Or at least its internal database (the one from gitlab?) sources some of its information from such website.

I've seen a project that (callerpy) that exposes an API that uses the TrueCaller database.

The idea would just be having a hook that would allow other people to contribute eventually. (I won't deny I'm tempted to create a service like that myself, but the moderation would be a nightmare :laughing: )

Penaz91 commented 2 months ago

After further analysis I can confirm that YACB uses "ShouldIAnswer" as a "community database" and already has a kind of a system to "set a community database", but it also refers to some pieces of code that are unavailable in the repository (at least from a quick analysis).

https://github.com/vinetos/Tranquille/blob/main/app/src/main/java/fr/vinetos/tranquille/DbManagementActivity.java#L18

The previous link shows a reference to "sia" (ShouldIAnswer) which is then referred in YACBHolder as a "community database":

https://github.com/Penaz91/Tranquille/blob/main/app/src/main/java/fr/vinetos/tranquille/data/YacbHolder.java#L91

This looks like a great starting point for further future extension. Another service that came to mind is Tellows, but I think their APIs are paid and its source code is non-free (which, like SIA, would bring "nonfreenet" upon us).

Penaz91 commented 2 months ago

On inspection of YacbHolder.java I noticed it refers to something that is not in the repo. Upon further inspection I found out that the original developer of YACB made a different repository for downloading the data from SIA.

https://gitlab.com/xynngh/LibPhoneNumberInfo

With this, it should be possible to have the entire feature set of YACB.

Vinetos commented 2 months ago

Wow, what an investigation !
Yes, the original app use this repository as an external source of data.
I think the next step for us is to extract the feature set.

From https://gitlab.com/xynngh/LibPhoneNumberInfo/-/blob/master/sia/src/main/java/dummydomain/yetanothercallblocker/sia/model/database/CommunityDatabaseItem.java, the current model is something like :

class Item {
    private long number;
    private int positiveRatingsCount;
    private int negativeRatingsCount;
    private int neutralRatingsCount;
    private int unknownData;
    private int category;
}

We can update this feature sets to our needs as the app has to change its database ORM ( #6 ). Something that could be nice is to store more that "positive" or "negative" vote. A "review" can vote positively, negatively, adds optional comment, suggest a category for the phone number etc. This way, the database can contains more information that can be then displayed to the users

Penaz91 commented 2 months ago

I'm not sure it's convenient to save more information into the mobile: the space is limited (even more so on low-end devices) and more information wouldn't help the main use the app has, that is knowing, at a glance:

a) If a number is spam or not (positive vs. negative rating) b) What kind of spam it may be (category) c) Decide upon such information if I should answer the call or not

A little bit like life, the ability to "know where to find information" can be considered more precious than "knowing the information itself". Details change, information gets outdated, etc...

I support the decision behind the current system: you get to know the essentials immediately (is it spam? what kind?) and eventually you can (on demand) delve further into the matter (and eventually see the reviews) by asking for reviews online.

The most extreme (and space-saving, but also unfeasible) approach would be having something like the following:

class Item{
    private long number;
    private int score;
    private int category;
}

The score (which could be something like "each positive pulls the score to 0, each neutral pulls towards 5, each negative pulls towards 10) would need to be calculated externally (cpu time vs space occupation tradeoff), or each update would consume a ton of CPU time (and thus, battery).

I think the current Item structure (minus the unknownData column, if not used) is a good tradeoff between space occupied (it's just 4 integers and 1 long) and CPU time (the score will have to be calculated as needed when a call is received).

Eventually, we need the "external service plugin" to be able to ingest a number, call the external service and return the reviews "on demand", like YACB currently does. I doubt a normal user would need to access the entire database of reviews at once. We are essentially deferring (lazy loading) the gathering of reviews until needed.

Vinetos commented 2 months ago

I see your point and it is a very clever idea.

I'm not sure it's convenient to save more information into the mobile

I agree with you. Storing these data on a external place (eg. a git repository) and making the mobile download a projection of these data with only what is needed for the app to run. The Item you gave seems to be a good start !

A little bit like life, the ability to "know where to find information" can be considered more precious than "knowing the information itself". Details change, information gets outdated, etc...

That exactly what I was thinking : storing the least on the phone, and the phone will dynamically fetching optional data as reviews, exact count positive, negative count etc.

Eventually, we need the "external service plugin" to be able to ingest a number, call the external service and return the reviews "on demand", like YACB currently does. I doubt a normal user would need to access the entire database of reviews at once. We are essentially deferring (lazy loading) the gathering of reviews until needed.

I'm ok with this : it could be very easy to implement and allow anyone to build a plugin to add any internal or external database.

Penaz91 commented 2 months ago

Thinking better about it, it may be wiser to stick with the original Item used in YACB (minus the "unknownData"), both for practicity and in case people want to enable multiple sources in the future (it's easy to calculate a "trust score" given the raw data, but it's really hard to calculate a score based on other scores).