Highly recommand to move S3_PUBLIC_DOMAIN sharing function to server side

[Lostsite]

My suggestion: request the file to a temp storage location on server, than ask the llm provider to download it directly from the server:

The problem for "S3_PUBLIC_DOMAIN" is many cheap "S3" storage providers are only "S3 compatible", many of them would NOT support "S3_PUBLIC_DOMAIN" on the basket level. Request to use "S3_PUBLIC_DOMAIN" would cause us can't use them.

(Also it is a pretty bad idea to keep a basket level sharing link alive all the time. If it leaks, it could cause trolls evilly pulling everything down again and again just to bill you, since usually "S3" storage are charged by downloads).

My suggestion is: 1st request the file to a temp storage location on server, than ask the llm provider to download it directly from the server:

Old method:
(llm provider) <----- ( File in S3 basket (permanent storage) )

New method:
(llm provider) <----- (File on server (request from S3, save for 1 -2h)) <-------- ( File in S3 basket (permanent storage) )

This would also benefits us if people wish to use the file multiple times, like download it during middle of one conversation, we can save some S3 download fee.

[arvinxx]

• (File on server (request from S3, save for 1 -2h))

I don't think it's a good idea. It's unavailable on serverless deployment in Vercel. If you want to protect the s3, maybe it's better to have a signed url from S3 to for view.

[Lostsite]

If just build this function only for Docker? Most Docker deployments are typically hosted on a server... I just wondering how much effort it would take to maintain a separate set of code... My idea is as follows:

1. If it's in a Docker environment, AND if the APP_URL has been set, and if SELF_SHARE is set to 1 (to ask if people want to share from their own server)
2. If yes, point S3_PUBLIC_DOMAIN towards the APP_URL + /fileShare/
3. When the code needs to share the file with LLM, find the database entry for the file (for it's S3 location and if it is already on the server). If NOT on server, pass request to S3 function.
4. The S3 function part gets the file and stores it in a temporary location. Pass the location to the server. And edit the database entry for the file for +file is on server + path of file on server + Timestamp.
5. The server gets the file location, publishes it to localhost:port/fileShare/***.
6. Tell the function manager which shares the file with the LLM server that the file is ready. It will give the LLM server APP_URL/fileShare/** *. (Since we pointed the S3_PUBLIC_DOMAIN towards the APP_URL + /fileShare/, this part of the code doesn't even need to change)
7. When time = marked time + 2h, delete the file and database entry about file on server.
8. If Someone trying the get the same file once again, Database entry would tell the file is on server, refresh the timestamp.

I assume the biggest challenge would be changing the function that locates the file location and shares the download URL with the LLM server. It needs to add the ability to call the function which edit the database and make extra judgements. It also need to change from real-time (semi-real-time?) to wait and act (AMI?)...

The database change should be minimum since if it does NOT have (file is on server) entry, code would assume the file is NOT on server, which means we do NOT need to edit the existing database data. We can make database return 0, or null (not exist) become (No file on server).

I wish I had the ability to change the code... But I don't have the ability to read a project of this size... Maybe someday I'll have enough time...

[arvinxx]

If just build this function only for Docker

I think it's not a good idea. I don't have efforts to maintain this part code . I will consider the coder to organize in serverless runtime, than docker.

as for the 4~8, it will take lots of efforts to make the cache correctly and it's not right way. I think it will mass the core biz logic, which I always want to avoid.