HN user

davidkarolyi

91 karma
Posts8
Comments39
View on HN

I'm not sure what do you mean nothing real behind. Can you elaborate? the script is not hosted under script.faqpopup.com thats why you cannot resolve the subdomain. The script url is visible after you purchased. Happy to share it though if you have doubts. Thanks

ut is a little bit smarter than f0. they provide ui components and server-framework bindings for file uploads.

I feel like f0 is a more minimalistic take on file management. More comparable to Vercel blobs than ut. I don't feel these two are comparable though. ut is a nice product if you are looking for those functionalities though.

In the backend you control everything. You can write whichever file you want and you’re authenticated via a secret key thats in your env variables.

In the frontend you need get a file-scoped token from the server.

Server: import { f0 } from ‘file0’; const token= await f0.createToken(‘myfile.png’);

You can send this token to the client. And use it like this: import { f0 } from ‘file0’;

await f0.useToken(token).set(myfileblob);

The docs are in the dashboard only after account creation atm. Public docs on the way.

Note that unlike FILE0, S3 not only charges for storage, but for write requests, read requests, network bandwidth, and some less obvious niche things.

So it's not a 1-1 comparison.

If you don't see the value in this extra convinience you should stay with your current service! The goal of FILE0 is not to replace these big players, but to provide an option to folks who just want to get things up and running quickly and don't want to think about infrastructure.

There are no docs. Once you create an account you will have a setup guide and will have a useful snippets section in your dashboard that contains everything you need to know about file0.

Yes. By default all your files are private and only you can access them. To make a public url you can use f0.publish('filename'); This returns a static url that you can share with anyone, and they can download the file.

This url will stay valid until the file is deleted or unpublished via f0.unpublish('filename');

If you call publish again, it will generate a new public URL.

I will kindly ignore the mental breakdown.

About the rest: For s3 you need to instantiate the client, and the only part you're correct about is that the client credentials can be also auto detected from env vars.

Let's boil the rest down: - For S3 you will need to add 2 env vars: AWS_ACCESS_KEY_ID, AWS_ACCESS_KEY_SECRET. In case you don't have other AWS keys in your env for other services this will be auto detected by the client. (Still needs to be instantiated), so you can cross off the 2 lines for creadentials.

- For FILE0 you need to add 1 env var: F0_SECRET_KEY. Then import the client which is autodetecting your env. ``` import {f0} from 'file0';

f0.set('myshit.png', myFile); ```

I'll let everyone be the judge of which one is simpler for them. And you should also use whichever you like more. I will sleep good at night either way and keep using file0.

FILE0 uses Cloudflare R2, and a thin layer of custom logic on top of that in form of CF workers.

The reasons for using R2 instead of S3: - Pricing: S3 charges for everything you do. R2 is only for requests and storage. This enables FILE0 to only charge for storage-tiers which is much more understandable pricing model.

- Workers: Good fit for large-scale file-streaming. And the two works great together.

1. If you switch the default SDK you still need to understand S3 to some extent. At least creating buckets, bucket policies, IAM, CORS headers and a few more. The complexity of S3 comes from it's architecture, not the SDK. In fact I believe the v3 SDK of AWS does a good job at what it is.

2. Feature extensibility. This way FILE0 is not restricted by S3 API limitations. One example being: the AWS SDK doesn't support advanced filters for files (like ends with .png). This is a feature FILE0 has, but not supported by the s3 api.

3. If the goal is to provide a smooth DX, you cannot start with "Go to your aws account and create a bucket, and add this configuration to your bucket".

A package like this would be interesting but it's not what FILE0 aims to achieve.

I was also reading this the other day, but right now they have the best offering on the market to serve as a base for FILE0. There are also alternatives out there, in case we get slapped with a 120k "offer".

The first step is to get to a scale where you piss off the Cloudflare sales team. FILE0 is far from that. Whenever that will be the case we can think about solutions, but this wouldn't be a good enough reason not to use them, and the free egress until we can.

The webpage is a little bare-bones apologies. The setup instructions and tutorial appears when you create an account.

At the moment the client package is only for js/ts devs. The package is based on HTTP api calls so it shouldn't be a huge issue porting it to other languages, but obv it's challenging without public HTTP specs. If you're into implementing a wrapper I'd be happy to assist and share those details.

About costs. The is no information, because there is no egress fee. FILE0 is built on top of R2. They don't charge for egress, so neither you pay. File size limit is 5GB soft limit. This is set as a sensible default but can be increased on demand.

The main location is in us-east, and it's replicated around the globe. If the file already exists, it is overriden. Yes, all the setup guide and API-specific tutorials are visible in your dashboard after signup.

Cheers. The long-term plan of pricing is to only bill after storage-tiers. The only reason there is no tiers, is because there are no customers with that need yet. But I hear you. I'm also sick of seat-based/bandwidth and a many other metrics providers charge us for.

Public API documentation is something many pointed out, so I consider adding some form of it. Appriciated.

Npm package is meant to be portable. It has 0 dependencies, and only utilizing API's that is widely available in any runtime.

And yes. you nailed it. It's backed by R2 and CF workers.

Yeah you addressed the elephant in the room.

Obviously it's a brand new product, with 0 reputation. As with every new product at the begining I expect bugs and disruptions, but IMO the product is simple enough to get it right quickly. FILE0 a simple layer on top of R2, so for reliability and HA is majorly dependant of their system.

You can trust me as much as any random guy on the internet.

For a big cloud provider you will be just a number, they don't particularly care if you're happy or not, but what I can tell you that for me you're my #1 priority. If you're happy, FILE0 survives. If not all the effort building it goes to the bin.

What's missing from the product is the ability to share apps (aka buckets) with your co-workers. If thats a feature you can live without momentarily, businesses can ask for a custom offer if 100GB is not enough. But they won't be billed after seats or any of that crap. Just for usage.

That all being said, I would love to setup a call and have a personal connection, and I'm here to help with anything you might need. I'll enrich the page with more obvious contact details, because it's a legit concern I'd also have.

Yeah more or less the comments are correct, but let me clarify! FILE0 is looking for an environment variable, that contains your API key. This is how you authenticate yourself from your backend. When you want to use client uploads you can use f0.createToken('myfile.png') and send that token to the frontend, where you can also import f0 and use it like this: f0.useToken(myTokenFromBackend).set(blob) In the dashboard you will find a setup guide and code snippets with all this info.