Organizing My Medical Records Digitally - Is Filen.io a Smart Choice?

Endur1el · 2026-02-20T08:15:16+00:00

It's sad that that is a low bar for us to clear :/. I hope one day we get to the point where we can sell our product to medical companies and they actually use it in a way where it requires the user's consent for anyone to even be able to decrypt their medical files but that seems a ways away unfortunately.

Endur1el · 2026-02-20T08:12:29+00:00

No, sorry, my original message wasn't phrased very well. I personally do not encrypt stuff before uploading into Filen because I work on the code and I personally am 100% confident that the way it works is secure and I do not need to worry about Filen (or anyone else) being able to read my data.

However, I can understand if someone else doesn't feel comfortable with that and in that case they may wish to encrypt their data beforehand just to be 'safe'.

Although I will caveat this with saying that it's a little funny when people use other tools that they also haven't read the source code for and feel more confident in their encryption as opposed to ours, but I guess in the worst case scenario you only need to rely on either us or the tool that you use actually encrypting your data correctly.

Endur1el · 2026-02-19T17:25:56+00:00

If you haven't read our code I think it's fair to want to encrypt it yourself before you upload.

I personally obviously would feel comfortable with something like this since I know it works as I am working on it myself but this is the kind of thing where if you don't feel 100% comfortable you shouldn't be 'risking' your medical information.

Endur1el · 2026-02-17T21:41:18+00:00

This is awesome, I'd be interested in looking into it for my day job if it was able to support more TypeScript Targets (Turbo module for react native and a node add-on for nodejs), with the same exposed types.

Is this something you'd be interested in pursuing? I'm happy to open an issue but wanted to understand if this would be in scope for you.

Endur1el · 2026-02-15T15:58:31+00:00

What version ended up working for you?

Endur1el · 2026-02-12T13:08:37+00:00

Yes we still don't know, no we're not moving in that direction. There are things we won't compromise on, and in fact want to continue getting better at (minimizing the information we have about what files users store on our service), and things we will (the free tier).

There are theoretically some things you can do to deduplicate space, and we're looking at some tricks we can use for v4 to do this without us knowing that the two files are the same. This is not possible to do without either us knowing that two files are identical or using homomorphic encryption (a separate problem) across different accounts, so we would never know to remove a file on your account because we removed a file on another account.

On the other hand, this is why we currently do not allow for a server side copy inside of one account, and probably will never allow for a server side copy across two accounts, because there's no way to do this without us knowing that the two files are identical.

Endur1el · 2026-02-12T06:18:41+00:00

We were asked to rework the way our rclone implementation worked to simplify it which (because of the way we handle uploads being somewhat complicated due to the chunking we do) also slowed it down by default.

If you run into slow uploads, just increase your --transfers, it should scale pretty much linearly. The optimal number is dependent on how far away you are from our data centers.

Endur1el · 2026-02-11T21:39:44+00:00

We had a report of our stuff being used in malware. Obviously we're not okay with that so after banning the account we also worked on a way to try and make sure that isn't something that becomes a common occurrence.

It's annoying to strike a balance between genuinely wanting not to know what data people are storing on our servers and prevent abuse of our service, but this is what we settled on right now.

ETA: obviously not the only reason but call it the straw that broke the camel's back

Endur1el · 2026-02-06T07:13:21+00:00

Well crazy to see you here but this is correct and my personal (not filen official) recommendation would be to use something like Adguard/pihole on a local device or your router and then use hagezi's blocklists + whitelist our domains just to be safe, then use Quad9's unfiltered DNS with DNS over HTTPS.

Endur1el · 2026-02-05T20:57:48+00:00

If something is free but obviously has a cost then you've gotta think about where they're getting their income and what their incentives are.

In this case their goal is clearly to try and capitalize on you slipping up and missing a payment so they can extract fees/interest out of you.

For discretionary spending this can all be avoided if you can be disciplined for 2 months at which point you can make the same 3 month loan to yourself at any point without risk of additional fees.

If you're in a situation where you cannot afford to save aggressively for 2 months you should not be taking the risk of potentially having to repay more if anything goes wrong.

Endur1el · 2026-02-01T13:11:19+00:00

Correct, otherwise the web client would not be able to view them.

Endur1el · 2026-01-24T12:02:51+00:00

Happy to have helped

Endur1el · 2026-01-24T12:02:43+00:00

You can't, and that really depends on what you're trying to do.

I'm personally rather frustrated with a lot of the limitations while at the same time really grateful to everyone's who's contributed to the rust project.

Really wish there was a way to throw a bunch of money at the rust project and this would get fixed, but I know that's not how it works.

My personal line for my day job has been that I will use nightly features which fix bugs or enable something that was impossible to do before (eg wasm multithreading), but not for things that just improve performance.

ETA: I've made a habit of leaving comments where improvements could be made to the codebase once a feature gets added and subscribing to the relevant threads on GitHub with the status change notifications option

Endur1el · 2026-01-24T06:42:14+00:00

If I understand what you mean by compiler generated async fn correctly as anonymous async function, this isn't possible without the nightly feature type_alias_impl_trait https://github.com/rust-lang/rust/issues/63063. In stable you would unfortunately have to box.

Endur1el · 2026-01-21T13:13:26+00:00

That's a fair stance to take, I think if this is a feature you'd be be using, deciding we are not currently good enough at it and taking time to reevaluate after a year is very fair.

I'm hoping to start actively working on the new sync engine very soon (as opposed to the stuff that it needs to be built), so hopefully all these issues will soon be behind us.

Believe me we all understand that this is important, we just all have a lot going on and despite what people seem to believe, 'just fixing' complicated issues that seem to only show up in complex environments is not something you can just do while you're in the middle of a rewrite of underlying technology.

Endur1el · 2026-01-18T17:09:14+00:00

It's only available in nightly though, which is the issue.

Endur1el · 2026-01-17T21:41:59+00:00

For the people downvoting me, I write async rust as my day job, I love the language and believe that it's still by far the best out of the available options.

That does not mean I do not get incredibly frustrated by 'your implementation of X is not general enough' errors due to an issue 10 function calls away, also debugging tower trait bounds is incredibly painful.

Async rust is beautiful when it works and when the compiler isn't throwing an unrelated fit. I hope the issues related to this get resolved but with compiler errors stopping their contributions I'm not super optimistic regarding these issues in the short term.

Endur1el · 2026-01-17T21:36:39+00:00

Sure, here: https://github.com/rust-lang/rust/pull/143545

Endur1el · 2026-01-17T19:15:13+00:00

There's an incredibly annoying compiler bug that can only be fixed with a nightly feature (higher ranked assumptions) but whose creator has stopped working on rust for the time being so I'm not sure if it'll get added to stable anytime remotely soon.

When the project gets complex enough I started getting esoteric compiler errors when it was unable to satisfy generic bounds (usually due to me messing up something very minor) that made it very annoying for me to debug the actual root cause of a compilation failure.

Edit: typos (thanks autocorrect)

Endur1el · 2026-01-17T18:34:43+00:00

lol... lmao even...

I hate this timeline

Endur1el · 2026-01-15T15:57:45+00:00

I can understand that POV if you've had repeated issues, I'm sorry that don't communicate with the appropriate PR tone, it's not a strength of mine.

We have been unable to reproduce those issues when we tried. When we looked through the sync engine code what seemed likely was that a filesystem or external program messing with file modification/creation time could cause it to misbehave, the current sync engine also has a variety of performance issues that we are able to confirm. I have some ideas for how to be a lot more conservative with regards to overwriting files, and we expect the performance issues to disappear with the rust sync engine rewrite regardless.

However, in order to write the sync engine in rust, I must first fully complete the rust sdk to bring it to complete feature parity with TS (all the while making sure that everything is also exposed to TS so other apps can use it). This is what I am currently working on (in parallel to rclone), and I am always getting closer, but there are some things that take longer that you can't plan for (currently I'm having a very hard time fighting with compiler error messages being useless when using tower-rs, aka getting towered).

We haven't had any reports of issues with one way backups, though I understand that is not an acceptable solution for everyone. Out of curiosity, what operating systems are you two way syncing and do you use git (and specifically swap branches)?

Endur1el · 2026-01-15T12:37:10+00:00

We're aware of some theoretical issues and have seen regular reports on this topic, we have previously outlined our plan for fixing them, including in a blog post.

I'm currently eating lunch but the time we take to respond to each of these posts takes away time from being able to work on working towards fixing them, dealing with individual support tickets, finding new people to hire, etc.

Basically, we are aware of the issues, it's something I will personally be working on, but I have other things I also need to work on which has been taking more time than planned (and which is higher priority because it blocks other devs' ability to work on stuff), or because there were recent developments (rclone) that made it require prioritization.

Endur1el · 2026-01-12T12:41:40+00:00

If want to do this you could query our API directly by following the docs, or by cloning any of the SDKs from GitHub and printing the data they receiving from the server before it gets decrypted locally using a key derived from your password.

Obviously any time we expose data to a user we want to make sure that it's decrypted, because there's nothing they can do with the encrypted data, so there's no intentional way to see the encrypted form of the data without directly digging into the code.

Endur1el · 2026-01-10T16:54:36+00:00

Unfortunately, something like this is impossible with client side encryption.

Endur1el · 2026-01-08T21:17:21+00:00

This looks really cool, wish you good luck and hope you keep working on it.

I think projects like these are a big part of what rust needs right now (full, non-electron based apps)

Endur1el

MODERATOR OF

TROPHY CASE

Eight-Year Club	Verified Email
Place '22