Skip to content
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

[improvement] create separate usecase for icons #64

Open
dyumin opened this issue Feb 7, 2025 · 1 comment
Open

[improvement] create separate usecase for icons #64

dyumin opened this issue Feb 7, 2025 · 1 comment

Comments

@dyumin
Copy link

dyumin commented Feb 7, 2025

Currently each identity keeps it's icon embedded in CallIdentity proto message.

Thus we need to add it's own icon copy to each identity even if it is the same icon (some generic business logo for example).

Our 33 GB identity DB grew to 904 GB after adding 1000000 copies of the same 63 KiB icon, which is not practical. Instead it could have been only 63 KiB + HE overhead.

Better solution may be the following: add image_id field to CallIdentity message which will be set to the corresponding row's keyword in icons usecase DB (net.example.lookup.icon for example).

This would enable backend to keep only one copy of the same image. Current solution simply not feasible for any large dataset (904 GB of RAM is just too many).

@karulont
Copy link
Contributor

There is a subtle security issue with using the result of the identity lookup (the image_id field) as a keyword for another lookup.
If one were to do this, the system would be insecure, because the server can alter the calculation of the "image_id" field and getting back a signal how that field was decrypted ( or not) leaks information back to the server.

However, we might look into other ways how to address the case of repeated images.

fboemer pushed a commit that referenced this issue Feb 26, 2025
Configuring sharding function is not backwards compatible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants