bo0tzz

It'd be specific issues with the changes themselves, originating in them being vibecoded ;)

Of course. We have many big items on our roadmap[0], and just recently in our latest minor[1] we released a new search query API and the first piece of many sharing improvements.

[0]: https://immich.app/roadmap [1]: https://immich.app/blog/v3.2.0-release

They forked because these are all heavily vibecoded changes that we don't want to merge upstream as such. (- I'm on the Immich team)

Yes, they've already murdered people by causing accidents on the highway.

Shotwell is great, but it's a single-machine photo organizer; I don't think you can really compare it to Immich on level ground.

Likely https://github.com/alangrainger/immich-public-proxy

You're suggesting to _reduce_ accessibility?!

It's been available for nearly three years

I specifically want the entire thing to run on workers though; if I'm hosting a separate CMS backend elsewhere, I might as well have that serve the site.

I've been wanting a CMS on top of Cloudflare workers for a while, so I hope this pays off!

2.6 million transactions per day [0], which in ISO 20022 XML format messages works out to (rough guess) 20GB per day for an average of 1.8Mbps...

[0]: https://www.scion.org/ssfn-scion/

duplicate of https://news.ycombinator.com/item?id=47584540

The Universal Declaration of Human Rights, Article 25.1:

> Everyone has the right to a standard of living adequate for the health and well-being of himself and of his family, including food, clothing, housing and medical care and necessary social services, and the right to security in the event of unemployment, sickness, disability, widowhood, old age or other lack of livelihood in circumstances beyond his control.

I'll take the challenge if it gets me Oxide hardware!

That is indeed what I meant.

This is a myth, actual fraud rates on programs like this are tiny - especially if you compare them to the benefits.

The system should undo state drift even if a run hasn't been prompted by changes to the upstream definitions in the repository

I loaded up the hacker news dataset in google bigquery, which turned out https://news.ycombinator.com/item?id=42057647 as the biggest at 9624 comments. Second is https://news.ycombinator.com/item?id=43208973 at 5349.

The post mentions 743 LOC records in the entire database; I'd be very curious to hear what that number's at now?

1. It only works at all for internal PRs, not for forks. That is a limitation we'd like to lift if we could figure out a way to do it safely though.

2. It's running on a pretty big machine, so I haven't seen it approach any limits yet. We also only create an instance when requested (with a PR label).

3. I've of course been inspired by other examples, but I think the current pattern is mostly my own, if largely just one of the core uses of the flux-operator ResourceSet APIs [1]. It's absolutely generalizable - the main 'loop' [2] just templates whatever Kubernetes resources based on the existence of a PR, you could put absolutely anything in there.

[1]: https://fluxcd.control-plane.io/operator/resourcesets/github...

[2]: https://github.com/immich-app/devtools/blob/main/kubernetes/...

Dude, I built it, surely I'd know how it works...

> correctly classified as having user generated active content

No it's not

> PRs can be autodeployed to this domain without passing review or approval.

No they can't

There is no untrusted/user content on these domains.

As I've mentioned in several other comments in this thread by now: The whole preview functionality only works for internal PRs, untrusted ones would never even make it to deployment.

> unless one of the developers in the team published something malicious through that system

If that happened we'd have much bigger problems than Google's flagging.

> Google flagged this domain for legitimate reasons.

No they didn't.

There is no user generated content involved here.

I'm the guy that built the system, lol. Labels can only be added by maintainers, and the whole system only works for PRs from internal branches.

The Immich domains that are hit by this issue are -not- user generated content.

The workflow is fundamentally unable to deploy a PR from a fork, it only works for internal branches, as it relies on the container image being pushed somewhere which needs secrets available in the CI workflow.

Sounds like you're hitting an address that isn't backed by any service, not sure what the issue is.