immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-25 14:00:45 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

Stop spreading misinformation #8256

New Issue
Closed
opened 2026-02-05 13:37:30 +03:00 by OVERLORD · 8 comments
OVERLORD commented 2026-02-05 13:37:30 +03:00
Owner
Copy Link

Originally created by @szmarczak on GitHub (Jan 15, 2026).

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

  • Yes

Misinformation 1: TOTP is hard

The TOTP reference implementation in Java is ~100 lines of code (comments stripped, code formatted). Furthermore, passkeys are also very easy to implement. MDN documentation also available. Relying on other auth providers is just another step into vendor lock-in, which is exactly what immich users want to avoid.

Misinformation 2: lack of folders in S3 is a blocker

Lack of folders by itself is not a blocker. You need to store a virtual filesystem with files mapped to S3 endpoints. This is as easy as storing an object with folder/file names as keys and S3 identifiers as values. As long as you store metadata locally, S3 is cheap.

Misinformation 3: Apple proprietary format makes rotation harder

https://www.iso.org/standard/89035.html

Misinformation 4: race conditions during rotation

Race conditions are not a problem if you're using a nonce.

Misinformation 5: Apple blocks custom chunk uploading

Their guidelines do not require you to use Resumable Uploads HTTP spec draft. Unless you post proof your app was rejected due to not implementing their solution, this is utterly bullshit.

Misinformation 6: chunking means out-of-order

As long as you're not using plain UDP, they come exactly in the same order you send them in. Validation is a separate issue and is not strictly bound to chunking. You don't need validation to implement chunking.

Why come with this?

Top comments blaming Apple for inventing their own image format.

Image Image Image

A public apology would be in order.

Don't blame Apple for things they didn't do. You have already shown your incompetence twice: https://github.com/immich-app/immich/issues/12702 https://github.com/immich-app/immich/issues/12706 and potentially caused hundred-dollar bills.

Originally created by @szmarczak on GitHub (Jan 15, 2026). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ## [Misinformation 1: TOTP is hard](https://youtu.be/SPZhLHW-uQk?t=175) [The TOTP reference implementation in Java](https://datatracker.ietf.org/doc/html/rfc6238#appendix-A) is ~100 lines of code (comments stripped, code formatted). Furthermore, [passkeys](https://passkeys.dev/) are also [very easy to implement](https://web.dev/articles/passkey-registration). [MDN documentation](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API) also available. Relying on other auth providers is just another step into vendor lock-in, which is exactly what immich users want to avoid. ## [Misinformation 2: lack of folders in S3 is a blocker](https://youtu.be/SPZhLHW-uQk?t=428) Lack of folders by itself is not a blocker. You need to store a virtual filesystem with files mapped to S3 endpoints. This is as easy as storing an object with folder/file names as keys and S3 identifiers as values. As long as you store metadata locally, S3 is cheap. ## [Misinformation 3: Apple proprietary format makes rotation harder](https://youtu.be/SPZhLHW-uQk?t=544) https://www.iso.org/standard/89035.html ## [Misinformation 4: race conditions during rotation](https://youtu.be/SPZhLHW-uQk?t=654) Race conditions are not a problem if you're using a nonce. ## [Misinformation 5: Apple blocks custom chunk uploading](https://youtu.be/SPZhLHW-uQk?t=672) Their guidelines do not require you to use [Resumable Uploads HTTP spec draft](https://datatracker.ietf.org/doc/draft-ietf-httpbis-resumable-upload/). Unless you post proof your app was rejected due to not implementing their solution, this is utterly bullshit. ## [Misinformation 6: chunking means out-of-order](https://youtu.be/SPZhLHW-uQk?t=764) As long as you're not using plain UDP, they come exactly in the same order you send them in. Validation is a separate issue and is not strictly bound to chunking. You don't need validation to implement chunking. ## Why come with this? Top comments blaming Apple for inventing their own image format. <img width="673" height="93" alt="Image" src="https://github.com/user-attachments/assets/d9023457-aaaa-46d6-8923-bbf5ec7876cc" /> <img width="696" height="126" alt="Image" src="https://github.com/user-attachments/assets/b4a17f82-f9da-4ae7-90e7-c40f7c7ea6cc" /> <img width="441" height="82" alt="Image" src="https://github.com/user-attachments/assets/bedfbe1a-e854-4e4e-86e0-105983ef5c82" /> ## A public apology would be in order. Don't blame Apple for things they didn't do. You have already shown your incompetence twice: https://github.com/immich-app/immich/issues/12702 https://github.com/immich-app/immich/issues/12706 and potentially caused hundred-dollar bills.
OVERLORD commented 2026-02-05 13:37:33 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Jan 15, 2026):

Appreciate the feedback, please move to GitHub discussion

@alextran1502 commented on GitHub (Jan 15, 2026): Appreciate the feedback, please move to GitHub discussion
OVERLORD commented 2026-02-05 13:37:34 +03:00
Author
Owner
Copy Link

@szmarczak commented on GitHub (Jan 15, 2026):

@alextran1502 Do you care to at least mention your huge inaccuracies on YouTube in comments & the description?

@szmarczak commented on GitHub (Jan 15, 2026): @alextran1502 Do you care to at least mention your huge inaccuracies on YouTube in comments & the description?
OVERLORD commented 2026-02-05 13:37:35 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Jan 15, 2026):

Hello, I think there might be a misunderstanding between the information discussed and how it is being interpreted.

For example, point 2, in the video, Zack said that "S3 doesn't support moving file" not "lack of folder".

So I won't be spending more time on this, as it has honestly come in with a very hostile position. I'd rather spend time fixing bugs that you refer to in your post

@alextran1502 commented on GitHub (Jan 15, 2026): Hello, I think there might be a misunderstanding between the information discussed and how it is being interpreted. For example, point 2, in the video, Zack said that "S3 doesn't support moving file" not "lack of folder". So I won't be spending more time on this, as it has honestly come in with a very hostile position. I'd rather spend time fixing bugs that you refer to in your post
OVERLORD commented 2026-02-05 13:37:36 +03:00
Author
Owner
Copy Link

@szmarczak commented on GitHub (Jan 15, 2026):

There is no misunderstanding, having my experience I know exactly the information discussed.

For example, point 2, in the video, Zack said that "S3 doesn't support moving file" not "lack of folder".

Hmm, I think you cannot move a file without another folder location, no? You were discussing "storage template" which are essentially files put in a specific folder structure.

@szmarczak commented on GitHub (Jan 15, 2026): There is no misunderstanding, having my experience I know exactly the information discussed. > For example, point 2, in the video, Zack said that "S3 doesn't support moving file" not "lack of folder". Hmm, I think you cannot move a file without another folder location, no? You were discussing ["storage template"](https://docs.immich.app/administration/storage-template/) which are essentially files put in a specific folder structure.
OVERLORD commented 2026-02-05 13:37:36 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Jan 15, 2026):

I think it would have turned out better if you had opened a GitHub discussion with

"Hey, I hear you guys saying X in this video. I have experience in this area, such as A/B/C, I think you can do that by reading this article X or document Y to understand better. I wonder what your thoughts are on my position and how it is different from what you are saying."

Then perhaps we can present our viewpoint and experiences based on the work we are doing day to day to reach that conclusion.

But coming in and accusing us of spreading misinformation just leaves a bad taste in everybody's mouth, and automatically makes it harder to have a proper conversation with you.

@alextran1502 commented on GitHub (Jan 15, 2026): I think it would have turned out better if you had opened a GitHub discussion with "Hey, I hear you guys saying X in this video. I have experience in this area, such as A/B/C, I think you can do that by reading this article X or document Y to understand better. I wonder what your thoughts are on my position and how it is different from what you are saying." Then perhaps we can present our viewpoint and experiences based on the work we are doing day to day to reach that conclusion. But coming in and accusing us of spreading misinformation just leaves a bad taste in everybody's mouth, and automatically makes it harder to have a proper conversation with you.
OVERLORD commented 2026-02-05 13:37:37 +03:00
Author
Owner
Copy Link

@szmarczak commented on GitHub (Jan 15, 2026):

I think it would have turned out better if you had opened a GitHub discussion with

This is unnecessary. I directly addressed your points, I know how different the actual thing is from what you are saying.

accusing us of spreading misinformation just leaves a bad taste

I am not saying you do all this intentionally, but these jarring inaccuracies need to be addressed, especially if you state those as facts on YouTube. More importantly, if you (this time intentionally) accuse Apple of things they didn't do (doesn't that put a bad taste in everybody's mouth?).

I'd like to stress that negative feedback is good. It means people care. However if you decide to ignore this, don't expect people to be nicer and take some responsibility. Especially after you (or @bo0tzz) decide to close a legitimate bug report.

I don't believe you have a bad intention and want yall to succeed, never mind how negative this feedback may be.

@szmarczak commented on GitHub (Jan 15, 2026): > I think it would have turned out better if you had opened a GitHub discussion with This is unnecessary. I directly addressed your points, I *know* how different the actual thing is from what you are saying. > accusing us of spreading misinformation just leaves a bad taste I am not saying you do all this intentionally, but these jarring inaccuracies need to be addressed, especially if you state those as facts on YouTube. More importantly, if you (this time *intentionally*) accuse Apple of things they didn't do (doesn't that put a bad taste in everybody's mouth?). --- I'd like to stress that [negative feedback is good](https://davnicwil.com/negative-feedback-is-positive). It means people care. However if you decide to ignore this, don't expect people to be nicer and take some responsibility. Especially after you (or @bo0tzz) decide to [close](https://github.com/immich-app/immich/issues/12704#issuecomment-2352992753) a legitimate bug report. I don't believe you have a bad intention and want yall to succeed, never mind how negative this feedback may be.
OVERLORD commented 2026-02-05 13:37:38 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Jan 16, 2026):

Negative feedback is very welcome; what's not is the hostile tone you use when delivering it - which you've already been warned about before.

@bo0tzz commented on GitHub (Jan 16, 2026): Negative feedback is very welcome; what's not is the hostile tone you use when delivering it - which you've already been warned about before.
OVERLORD commented 2026-02-05 13:37:38 +03:00
Author
Owner
Copy Link

@szmarczak commented on GitHub (Jan 16, 2026):

what's not is the hostile tone you use

What's exactly hostile? The last sentence? But you can be hostile against Apple because of things they didn't do, and that's fine? Are you hearing yourself? Everything else stated in this issue is true. Expecting people to be "nice" after closing their legitimate bug reports is not fine either.

You still haven't learned and take zero responsibility, and yall take money for it. You do not have warned people of possibly wasting bandwidth - cuz, how it would look - eh, put a bad light on immich? I guess you're not going to correct the YouTube video either?

Own up to your mistakes and take responsibility.

Things would've gone entirely differently, if you hadn't:
a) closed my legitimate bug report
b) lied that the OS didn't you allow to fix that
c) insisted that X will fix Y while being a separate feature
d) not warned people of potentially wasting bandwidth
e) now this

you've already been warned about before

And you had been warned of this incompetent behavior as well, because it's exactly what it's called, not matter how you frame it.

Please do think about this. Do you not see that my original issue was 100% neutral and only my tone changed after a) and b)?

You introducing the XY problem only further fueled the fire, not extinguish it. If you fail to clearly see your response was an XY problem, then I'm just speechless and this entire conversation is pointless.

The OS wasn't a limitation because there's nothing blocking you from saving metadata that "this file was successfully backed up" instead of "all backup complete".

@szmarczak commented on GitHub (Jan 16, 2026): > what's not is the hostile tone you use What's exactly hostile? The last sentence? But you can be hostile against Apple because of things they didn't do, and that's fine? Are you hearing yourself? Everything else stated in this issue is true. Expecting people to be "nice" after closing their legitimate bug reports is not fine either. You still haven't learned and take zero responsibility, and yall take money for it. You do not have warned people of possibly wasting bandwidth - cuz, how it would look - eh, put a bad light on immich? I guess you're not going to correct the YouTube video either? Own up to your mistakes and take responsibility. --- Things would've gone entirely differently, if you hadn't: a) [closed my legitimate bug report](https://github.com/immich-app/immich/issues/12704#issuecomment-2352992753) b) [lied that the OS didn't you allow to fix that](https://github.com/immich-app/immich/discussions/12703#discussioncomment-10653131) c) [insisted that X will fix Y while being a separate feature](https://github.com/immich-app/immich/issues/12704#issuecomment-2353009046) d) [not warned people of potentially wasting bandwidth](https://github.com/immich-app/immich/issues/12706) e) now this > you've already been warned about before And you had been warned of this incompetent behavior as well, because it's exactly what it's called, not matter how you frame it. Please do think about this. Do you not see that [my original issue](https://github.com/immich-app/immich/issues/12702) was 100% neutral and only my tone changed after a) and b)? You introducing the [XY problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) only further fueled the fire, not extinguish it. If you fail to clearly see your response was an XY problem, then I'm just speechless and this entire conversation is pointless. The OS wasn't a limitation because there's nothing blocking you from saving metadata that "this file was successfully backed up" instead of "all backup complete".
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#8256
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?