-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Pluggable" sources #13
Comments
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 ? |
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 😆 ) |
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). The previous link shows a reference to "sia" (ShouldIAnswer) which is then referred in YACBHolder as a "community database": 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). |
On inspection of https://gitlab.com/xynngh/LibPhoneNumberInfo With this, it should be possible to have the entire feature set of YACB. |
Wow, what an investigation ! 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 ). |
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) 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 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 see your point and it is a very clever idea.
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 !
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.
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. |
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). |
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.
The text was updated successfully, but these errors were encountered: