lemon on Nostr: GIFs are a form of expression and speech. Thus, should have a place on most (if not ...
GIFs are a form of expression and speech.
Thus, should have a place on most (if not all) communication clients.
The simplest and prevailing integration currently is the GIF button that performs an API call to one of the major GIF databases.
The risk associated with using these services is incredibly low, the library is vast, and implementation is trivial.
The benefits associated with GIFs should really not be underestimated. GIFs convey emotion, tone, transcend language, and are concise (unlike this note).
I believe the benefits of having GIFs integrated significantly outweigh the risks.
With that said, here are the tradeoffs to be considered when using permissioned APIs:
Censorship
- Banned media at the country level (Politically sensitive imagery)
- Banned media at the corporate level (NSFW)
- Rate limiting (1 request per second)
- Terms of conditions (Revoke API key if usage violates Terms)
Accessibility
- New upload/availability (Content rating, moderation, wait times)
- API key applications (API providers want to know their customer)
- Email address (Required for account verification)
Advertising & Surveillance
- Attribution/branding ("Powered by")
- GIF advertising (GIFs may be weighted higher than others to promote shows/programs)
- Privacy policies (Collection of data to sell to 3rd parties or modify search results)
Given this, it seems reasonable to implement a GIF button using API keys from a major GIF provider with the ability to incorporate mitigating features down the line.
Unless, of course, any one of the tradeoffs is intolerable to the app's experience (e.g. usage > rate limit, preserving privacy), which I expect to be uncommon.
I believe the use of NIP-94 fully mitigates all of these risks, but will come with its own set of tradeoffs (e.g. library size, ease of use, event retention over time).
In short:
- The best approach for nearly every client is currently to use a permissioned API and incorporate a GIF button.
- NIP-94 can and will be used as a backstop to ensure uninterrupted service for those that find the risks intolerable.
- GIFs are created by individuals and cannot be owned by anyone.
- Information yearns to be free.
- GIFs are inevitable.
Thus, should have a place on most (if not all) communication clients.
The simplest and prevailing integration currently is the GIF button that performs an API call to one of the major GIF databases.
The risk associated with using these services is incredibly low, the library is vast, and implementation is trivial.
The benefits associated with GIFs should really not be underestimated. GIFs convey emotion, tone, transcend language, and are concise (unlike this note).
I believe the benefits of having GIFs integrated significantly outweigh the risks.
With that said, here are the tradeoffs to be considered when using permissioned APIs:
Censorship
- Banned media at the country level (Politically sensitive imagery)
- Banned media at the corporate level (NSFW)
- Rate limiting (1 request per second)
- Terms of conditions (Revoke API key if usage violates Terms)
Accessibility
- New upload/availability (Content rating, moderation, wait times)
- API key applications (API providers want to know their customer)
- Email address (Required for account verification)
Advertising & Surveillance
- Attribution/branding ("Powered by")
- GIF advertising (GIFs may be weighted higher than others to promote shows/programs)
- Privacy policies (Collection of data to sell to 3rd parties or modify search results)
Given this, it seems reasonable to implement a GIF button using API keys from a major GIF provider with the ability to incorporate mitigating features down the line.
Unless, of course, any one of the tradeoffs is intolerable to the app's experience (e.g. usage > rate limit, preserving privacy), which I expect to be uncommon.
I believe the use of NIP-94 fully mitigates all of these risks, but will come with its own set of tradeoffs (e.g. library size, ease of use, event retention over time).
In short:
- The best approach for nearly every client is currently to use a permissioned API and incorporate a GIF button.
- NIP-94 can and will be used as a backstop to ensure uninterrupted service for those that find the risks intolerable.
- GIFs are created by individuals and cannot be owned by anyone.
- Information yearns to be free.
- GIFs are inevitable.