Tenor Gif API support

[CupofDalek]

Pitch

Hello!

I have been running a small instance with a few users and we love to use gifs for reacting/replying or sharing a mood. This is a behavior familiar to my users, emotes are good, but gifs can be very expressive and visual.

We found that we can use gifs by inserting them as attachments, but as time goes on this is going to become an issue given that these take up storage.

I am proposing support of a gif button next to the others in the compose section That will allow searching of gifs. - Instance admins will have to provide their own API credentials. (Similar to DeepL Integrations for language translation)

I am also proposing embedding via url for Tenor gifs, currently even if we did the searching and pasting the share url ourselves, it shares as text

---

It would be great if loading of the gif happened at the browser level so that this also means reduced processing for the servers themselves to store and cache gifs. But if it must be done by the server, we can treat gifs as "remote media" by this method.

---

Motivation

By using this method of search and sharing using a URL. This will allow users to have better expression using gifs with an easier way to search rather than having to rely on third party solutions that attach the gifs as files, and this will reduce the overhead of storing multiple gifs (sometimes multiple copies of the same gif ) on servers for instance admins.

This will overall help with lowering storage costs and also can help reduce processing if loading of gifs happens at the browser level and not on the servers.

Thank you for your consideration!

[ghost]

I personally don't really want them, but if others do 🤷

However, the suggestion not to load them through the media proxy is something I am strongly against.
It raises many privacy concerns for me. Considering that Mastodon is loading everything non-local through the cache/proxy at the moment, I don't understand why we should change that practice now for tenor gifs.

Still, I wish you good luck with the pitch
Just don't give that bit of privacy away we fought so hard for 🙂

[CupofDalek]

I personally don't really want them, but if others do 🤷

However, the suggestion not to load them through the media proxy is something I am strongly against. It raises many privacy concerns for me. Considering that Mastodon is loading everything non-local through the cache/proxy at the moment, I don't understand why we should change that practice now for tenor gifs.

Still, I wish you good luck with the pitch Just don't give that bit of privacy away we fought so hard for 🙂

My thought process on that specifically was reduction of server overhead, but I was not married to it.

I would definitely be perfectly ok with this implementation meaning that servers utilizing this feature still download the gifs locally, but my intent is for this download to be temporary somehow.

I love security and privacy myself as well. But as an avid gif user as well, I think we do need to consider ways to be efficient and not unnecessarily permanently store images like this that are very useful at first, but become meaningless over time. Ya know?

I would certainly never advocate for this kind of thing if we were talking of images (or gifs) that were memories we want to keep. But I can honestly say after about a week, I really would rather having it so any gifs used with tenor API (or similar services) poof than be permanently stored

[ghost]

Definitely, storing them as normal user content might be not really useful and will cause many duplicates.

That is why I was referring to the caching system for remote content.
This stores remote content just temporarily and you even can define yourself how long you want to be cached.

The only difference from the traditional usage would be that in this case, the remote content would be posted by local users too.

[CupofDalek]

Definitely, storing them as normal user content might be not really useful and will cause many duplicates.

That is why I was referring to the caching system for remote content. This stores remote content just temporarily and you even can define yourself how long you want to be cached.

The only difference from the traditional usage would be that in this case, the remote content would be posted by local users too.

Agree, would love this :)

[nightpool]

With Gfycat shutting down on September 1st, I think it would be a very bad strategic decision to rely on a private, centralized company to host user content just to save on a few dollars per month of block storage (and you'd need over 600gb of gifs to hit even 1 dollar of monthly storage savings).

[CupofDalek]

With Gfycat shutting down on September 1st, I think it would be a very bad strategic decision to rely on a private, centralized company to host user content just to save on a few dollars per month of block storage (and you'd need over 600gb of gifs to hit even 1 dollar of monthly storage savings).

I have actually found that some gif keyboards end up inserting not only true gifs, but sometimes mp4s

This is why I think a native solution will certainly make a difference. I first noticed it when using the windows 11 gif search (shortcut: WIN + ; )

And this would not be user content, (unless they are uploading their gifs there too for multi-platform support for other apps that already use this such as discord ///)

the intent is for this to be for users to use this for engagement and expression but I mentioned in a previous reply above that for actual user generated content/memories (things we DO care about even in video or gif form) I definitely do not want to include that into the scope of this request. We want those to store as they currently do

So with my idea:
User uploaded = Store as normal
Uploaded via tenor integration = Treat as "remote media" ?

I just dont think it's worth storing things like this over the years. And cost of storage varies depending on your hosting solution.

[TheEssem]

The koyu.space fork had a Tenor GIF picker implementation before it shut down, could probably look through the source and try to hack it onto base masto: https://github.com/koyuspace/mastodon/blob/main/app/javascript/flavours/glitch/features/ui/components/gif_modal.js

[CupofDalek]

Kicking back to this, looks like threads is implementing a more native gif solution.

I imagine they are doing it properly by referencing the Gifs as opposed to intentionally storing every gif but either way

https://www.threads.net/@threads/post/Cy32ZRHOzuC/?igshid=MzRlODBiNWFlZA%3D%3D

I hope this gets some attention over here.

Please help us treat tenor and or giphy as remote media

Above all, please let us have a dedicated gif button if we connect tenor or gihpy via api for an ease of use

[p37307]

I wished,.at the minimum, gifs were stored in a dedicated cache area that users could search and pull from like is done with emojis. New gifs that are uploaded could be stored there that other users could pull from, like from the proposed gif button..if the gif isn't there, one could be uploaded. Admins could then elect to approve or disallow all user use. This way, you don't end up storing the same gif thousands of times.

[CupofDalek]

I wished,.at the minimum, gifs were stored in a dedicated cache area that users could search and pull from like is done with emojis. New gifs that are uploaded could be stored there that other users could pull from, like from the proposed gif button..if the gif isn't there, one could be uploaded. Admins could then elect to approve or disallow all user use. This way, you don't end up storing the same gif thousands of times.

Someone had floated the idea of some sort of decentralized gif provider

Tbh I would not mind self hosting one as well following your concept idea, as long as its separate from my permanent storage is all haha

But would indeed prefer Tenor for ease of use. Idk

[BorknBandage]

I agree with the idea of having gif support due to having the ability to be way more expressive with the things we post. With gifs it's much easier to convey feeling along with it being very eye catching for any users who also look into the conversation going on.

Also if people don't like it as a integration make it an instance choice on if it will be enabled. That way that instance can decide on if they'd want that to even be a option within it.

In the current state you have to go through a whole process of going through a third party keyboard or website that's not built in which can be a hassle for ease of use. Mastodon currently already has quite the learning curve for new user experience why should gifs be part of that?

[CupofDalek]

I agree with the idea of having gif support due to having the ability to be way more expressive with the things we post. With gifs it's much easier to convey feeling along with it being very eye catching for any users who also look into the conversation going on.

Also if people don't like it as a integration make it an instance choice on if it will be enabled. That way that instance can decide on if they'd want that to even be a option within it.

In the current state you have to go through a whole process of going through a third party keyboard or website that's not built in which can be a hassle for ease of use. Mastodon currently already has quite the learning curve for new user experience why should gifs be part of that?

DEFINITELY 👏

Why make it harder than it has to be because of fears of integration, simply giving us the option to server admins would be simple enough!

[TheEssem]

I do feel like if something like this was added great care would need to be taken to ensure it fits within the goals of the project in terms of security/privacy; note how very few parts of the software rely on centralized services/databases, and especially note how if you go to an instance with uBlock Origin, it won't even show a counter because it doesn't utilize any sort of tracking scripts.

Tenor is owned by Google and Giphy is owned by Meta; both of these companies are ad/tracking companies at their core, and there don't seem to be any viable alternatives to them that don't rely on a centralized database or a large company burning money to keep them running. The only integration I can think of with a centralized service currently in Mastodon would be the DeepL integration, and even then there's an alternative to that (the LibreTranslate integration) and a promise from DeepL that their paid plan won't involve tracking or usage of data for other means. I wouldn't expect Google or Meta to do the same.