API and other considerations for a blob storage system

[adamcrossland]

I would like to work on adding a blob-storage system as described in the CONTRIUBTING file, and I'd like to make sure that my thinking is aligned with the project overall.

1. There will be a REST API for performing the standard CRUD operations on BLOBs.
2. It should be possible to access a BLOB anonymously (for embedding in emails or web pages), but they should also be able to be marked as authenticated access only, yes?
3. Some metadata should be associated with each BLOB:
   1. Friendly name
   2. MIME type
   3. Created date
   4. Updated date
   5. Scope (global, function)
   6. what else that I'm not thinking of?
4. There will be a Lua API for working with BLOBs that should support the following operations:
   1. Read and write, including metadata
   2. Delete, list
   3. Return the URL for a BLOB
   4. what else that I'm not thinking of?
5. There will be a UI component, allowing the user to manage and interact with BLOBs through the UI, like the KV Store tab.
6. Should there be globally-scoped and function-scoped BLOB stores?
7. Will there be a need for other, named buckets in which BLOBs can be organized?

[dimiro1]

Hello @adamcrossland.

1. Yes.
2. I think we can mark blobs as public or private. If public, the blob can be served by the Lunar Go runtime; if private, it must be served using a Lua API send_file.
3. Yes, we can try to follow the basic metadata from S3, but no need to overdo it.
4. Yes, CRUD operations and serve_file as well.
5. Yes, this can be useful.
6. Yes, I think we can namespace by the function and have a global namespace as well.
7. Not sure, probably not.