[status-mobile-16457] Fix messages containing Giphy URLs not being sent #3821
Conversation
Jenkins BuildsClick to see older builds (91)
|
ibrkhalil
force-pushed
the
status-mobile-16457
branch
from
7e19552 to
fab8dea
Compare
ibrkhalil
force-pushed
the
status-mobile-16457
branch
from
a84b3fa to
b4790ec
Compare
ibrkhalil
force-pushed
the
status-mobile-16457
branch
from
9896d31 to
9085414
Compare
|
Hey @ibrkhalil, is there anything holding this PR from advancing? I'm already working on changes that will touch the same files, so we'll face conflicts for sure. |
Hey Icaro, I am awaiting a reply from design team on this comment |
I posted it on their Discord server |
|
@ibrkhalil, interesting proposal status-im/status-mobile#16814 (comment) for processing gifs. The feature I'm working on is to add support for static image URLs, which, if we go the route you and @cammellos suggested of taking a snapshot of a single gif frame, means image URLs and gif URLs will share a lot in common code-wise and behavior-wise. The agreed flow with image URLs is that the image will be unfurled once on the sender side in a lower resolution and compressed image, and then on the client side, the user will need to explicitly press on the preview thumbnail to see the full image, a la Discord. Just one question @cammellos @ibrkhalil, why can't we unfurl and persist the full gif (heavily preprocessed of course) and then serve it to clients? Are there technical limitations? Or is it just for simplicity at this stage of the product? The ideal behavior in my head would be:
The benefit, I believe, is that the majority of users will be happy to see only the preprocessed (also interactive) gifs, and they will never pay the privacy cost because they won't bother seeing the full gif in the original website. If we decide to show only a static frame of the gif on clients, it kind of diminishes the value of the gif feature, because I believe a lot of users will still press on the image to the see the interactive gif, but this will cost them on privacy. You see, the static gif snapshot sort of invites users to interact with centralized servers because humans are curious and they want to see more frames 🤷🏼 |
|
@ilmotta If we can keep gifs size lower than 300/400KB I think sending through waku is fine and preferable, @Samyoul has worked on the compression, not sure it supports gifs. |
I sincerely have no idea if average smartphones can quickly process gifs to make them fit this sizing constraint. Some gifs are almost like full short videos, so preprocessing them could take a considerable amount of time on mobile devices. That's why I asked if there's any technical limitation, but I guess we would need to quickly try on status-go and see? Unless status-go isn't equipped now to do this sort of processing on gifs, then it could be too much effort for the MVP (?).
100%. Addtionally, so many users hate autoplay gifs. |
|
Hey @ilmotta / @cammellos sorry for the late reply. Gifs in
|
|
Thank you for the detailed explanation @Samyoul.
Agreed 👍🏼 From what I understood, it seems we have some unknowns that may turn out to be blockers. In this case, the static image approach to gifs is starting to grow on me :)
Since animated wepb can deliver similar quality for lower sizes compared to gif, I wonder if mobile supports animated webp, and if that could be of any help. This link is quite useful https://developers.google.com/speed/webp/faq#why_should_i_use_animated_webp This could be interesting anyway for the desktop app.
I'm impressed, cool! @cammellos, that was all! I guess we can evolve gif previews in later iterations. |
|
@ilmotta do you know if this PR is still needed? |
Good finding @igor-sirotin. We can close the issue because there are too many open points and, at least on Mobile, it's not in our priorities and probably won't be for a long time. |
When trying to calculate an image for a preview using incorrect field names, It resulted in the message not to be sent
Closes #16457 on status-mobile