[NIP-96] Adding optional file_tags to categorize files and listing public files

[quentintaranpino]

Objective

The objective of this proposal is to enhance the current file handling capabilities by introducing optional query parameters for categorizing and listing public files. This enhancement will provide users with more flexibility and control when interacting with files on the server.

Proposed Changes

GET $api_url?page=x&count=y&sort=z&order=w&search=term

1. Adding Optional Query Parameters:

   • sort : Determines the sorting criteria of the listed files. It can take values 'created_at' or 'size'. The default value is 'created_at'.
   • order : Specifies the order of the listing, either 'ASC' for ascending or 'DESC' for descending. The default value is 'DESC'.
   • search : Allows users to search for files based on a search term. The server should search in the alt and file_tags fields.

2. Adding Optional file_tags Field When Uploading Files:

   • The file_tags field will be an optional field during file upload, allowing users to specify tags for their files. Example usage: ["file_tags", "cat, meme, funny, laugh"].

3. Authorization Requirements:

   • AUTH required for pubkey file listing.
   • AUTH NOT required for public file listing.

Benefits

The introduction of these optional fields and parameters will enable more sophisticated file management and search capabilities. Specifically, it will allow clients to:

• Categorize Files: By adding file_tags during file upload, users can categorize their files more effectively, making it easier to organize and retrieve them later.
• Enhanced Search: The search parameter will allow users to search files using specific terms, filtering results based on the alt and file_tags fields. This will make it easier to find specific files, such as gifs of memes, quickly and efficiently.
• Flexible Listing: The sort and order parameters will provide users with the ability to customize the display order of their files, either by creation date or size, in ascending or descending order.

This is inspired by this note from @jb55, where he shares hisconcerns with the GIPHY service. With this small modification, NIP96 will allow media servers to provide this service, easily and with minimal modifications.

https://nostrudel.ninja/#/n/nevent1qy88wumn8ghj7mn0wvhxcmmv9uq35amnwvaz7tms09exzmtfvshxv6tpw34xze3wvdhk6tcpzemhxue69uhhyetvv9ujumt0wd68ytnsw43z7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qg3waehxw309ahx7um5wghxcctwvshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qyghwumn8ghj7mn0wd68ytnhd9hx2tcqyq4c095djx50q4mtz8xhzhmyhgyn3ezd6jclpg2l5hurnvy9j9wky647wzj

What do you think? @arthurfranca @v0l @vitorpamplona

[quentintaranpino]

@fishcakeday @sant0s12

[fishcakeday]

I feel like this is pushing it way beyond what this NIP was designed for. I am all for the ability to search, but not in the listing. I already expressed my concerns with the current listing that I am not planning to implement due to lack of provision for scalability and high volume, and I am certainly not a fan of adding any further complexity to what is already assumes a single RDBMS based implementation.

[jb55]

fwiw I wouldn't use this because it centralizes too much functionality on external providers imo. my idea was just to use a labelling mechanism on the network itself, so that anyone or AI could source and label gifs on the network without any external service. then it would just be a matter of following labeling service(s) that you can query these labels from, since you wouldn't want to trust labels from anyone.

for example, imagine a query such as:

{"kinds": [12345], "#L": ["lol"], "authors": ["label-service-pubkey", "friend-pubkey", "etc..."], "limit": 10 }

which returns notes of gifs related to lol. The only tricky part would be gathering these labels so that you can query them efficiently, aka converting search queries to labels. or maybe clients could gather these labels and present them as possible things to search.

still someone of a half baked idea but I don't see why it couldn't work.

[jb55]

hmm you could even query gifs directly from nip94 via {"#m": ["image/gif]}! if services started labeling those. you could even nip50 search nip-94 contents since those are a description of the file? @vitorpamplona

[vitorpamplona]

you could even query gifs directly from nip94 via {"#m": ["image/gif]}! if services started labeling those

The m tag is required. Virtually all NIP-94 events have it. :)

However, most GIFs are very specific memes and not really re-usable stickers. Filtering by image/gif alone returns too many unusable GIFs.

NIP-50 (e.g. relay.nostr.band and relay.noswhere.com) does index alt texts, which should be how we search for the sticker the user wants.

I still think NIP-95 is better for stickers. But NIP-94 can work as well.