I know this post is about Noodle, but I want to talk about Immich.
I believe I've spent, perhaps, the most time of anyone on earth on digital photo management (hard to quantify, but since 2005 - 2 startups, one acquisition, and an ongoing open source project used by thousands).
I say that because I've refused to settle for most solutions in this space. Even when I adopted using Google Photos, it was as a read only viewer of my canonical photo library (I wasn't about to let Google take that responsibility). I have such high demands of whatever software I use for managing my photos and videos - they're really the only digital files I actually care about.
Immich is absolutely wonderful. It may have some shortcomings ... like partner sharing and sharing facial recognition between users. But man is it remarkable that an open source project can rival something from Google in terms of quality and experience.
And a soft fork like Noodle is precisely the way to handle it. I am perfectly happy with Immich so am not a user of Noodle. But it's open source flexing its strength.
I have great things to say as well. I left Google Photos about 1 year ago or two, used Takeout to export my ~terabyte of Google Photos, imported to Immich on my mac mini, along with more personal archives of photos. I store the images on an external SSD array (https://paulstamatiou.com/gear/owc-express-4m2-nvme-ssd-encl...) that I have backed up with Restic+Backrest to some cloud providers.
My mac mini hosts it behind tailscale to all my devices and it's been working great.
As someone looking to exfiltrate my photos from Google, I'm about to trial Immich, and I really appreciate you sharing your experience. Sounds like it's a good next step for me.
There's plenty of tutorials but you can request a Google Takeout of your photos and then point immich-go at it. I can confirm that this works really well.
Agree - it's annoying. rclone to the rescue. Requires choosing Google Drive as the destination and then downloading with rclone to your computer. It's the closest to sane I've found.
Claude made a PHP script for me that did API to Google Photos and pulls them all to my archive location.
I struggled with Immich, I didn't like the rclone option. I'm intending to go back to Immich but my first priority was to get the stuff out of Google. That's done, so with all my free time (ha!) I can get the family Immich going.
Not sure if it's still the same but years ago when you get your own photos from Google photos via it's APIs you could only get large thumbnails so a great quality reduction. So make sure yours are the original quality. Takeout was the only way out your photos in original quality.
I was planning on having Immich read from my archive. Then Immich on the phones sends right there (VPN?) and skips G all together. But maybe I'll end up with Amdroid->Google->PHP->Immich
Not sure if what I said made sense. I mean inject titles, descriptions, etc from the Google Takeout into the photos EXIF. Then when you import them into Immich, it'll extract those into its own database.
Since we're on Immich, please let me vent out my frustrations after having looked at it recently.
Why the love affair with forcing absolutely everything into strict temporal constraints? Is there a single view in Immich that isn't peppered with date headings?
And I genuinely do not understand what the sharing feature is even for. What are you sharing? It can't be albums because an album would be a series of photos you yourself arranged, independent of when the photos were taken, and this seems a completely foreign concept in Immich land.
My photos and videos are the most important files I have in my self-hosted storage system. Being end-to-end encrypted buys some peace of mind knowing that it's not end of world if my homelab is compromised. And I can backup the data to whatever public clouds without worrying too much about leaking data.
>But man is it remarkable that an open source project can rival something from Google in terms of quality and experience.
I'd argue Google is always way worse than the open source alternative in both quality and ux. Their products are terrible. From Gmail to Youtube, the product itself comes second (or Nth), while in open source the product is always first.
In my experience, most open source photo apps lacked basic features like facial recognition, mobile apps, etc. And where they do exist, the UX isn't the best. Are there ones I'm unaware of?
Kano predicted that users' perceptions of satisfaction with a feature will shift from delight to expectation over time. This is either because they have got used to it or because competitors have started to include it in their offerings. In the case of the touchscreen, for instance, the newness that came with the iPhone is no longer a novelty; the touchscreen has become the norm. It's no big deal anymore, but taking it away would be a big deal!
The submitted title’s framing “alternative to Google Photos and Immich” is dodgy because this is a soft fork of Immich, adding certain features, described in https://opennoodle.de/noodle-gallery-vs-immich/.
So it is Immich but they pointed Claude at it and let it go wild?
The entire landing page screams AI generated, all the typical front-end tells of Fable and Opus are there (the colours, the flashing status indicator, the fonts, the rounded tiles with the coloured left border, the claudisms, I could go on).
I don't know if I'm getting more sensitive to Claudisms because I've been reading them everywhere (and I use Claude a fair bit myself), but I feel like the comparison page is full of them.
> The shortcoming. Immich's face recognition is account-scoped. One real person becomes a separate entry in your library, in your partner's library, and in every shared album you both touch. Search for them and you get a third of their photos. Name them in one account and the name stays there. The People page tracks containers, not people.
This definitely reeks of LLM (I’m not even going to attempt to understand it). I’ve seen similar false contrasts and awkwardly worded sentences before in other LLMs, but GPT would probably say “rather than people” instead. Claude does have a distinct style (that, to be fair, is copied by many others, recently noticed it in GLM 5.3 Flash).
Thank you for that -- the workaround for multiple users sharing a set of photos plus their own stuff is the one thing that's kept my family away from adopting it.
Was there a reason these features were not accepted to upstream Immich and needed to be in a fork?
Looking at the latest commits, Noodle Galery has many signed with Claude, but Immich doesn't. Is LLM policy a reason for fork? (Just speculating, I don't know.)
UPD: Immich has this in CONTRIBUTING.md, seems like its LLM policy is more strict:
> We ask you not to open PRs generated with an LLM.
vs. Noodle Galery:
> We actively encourage the use of LLMs and AI coding tools.
My only issue with Immich is the partner sharing and face recognition overhead per account. It is a massive oversight. Looks like Noodle Gallery explicitly solves this (and more). I'm sold.
EDIT: hmm after reviewing the repo, I'm going to wait a bit to see how this works out. There's a difference between LLM-assisted software development and blindly vibe-coding things without review and this seems a bit like the latter. I see no contributors and hundreds of commits in a very short amount of time. That's a red flag for now.
Hey, I'm the main contributor to this repo. I do review the code - the reason why all of the commits are shown in a short time is just because of the way that I rebase on upstream Immich.
I have been working on this project for 6 months, and (contrary to what the Immich team posts every single time my project is mentioned) I do not blindly vibe code - or are folks saying that blindly vibe coding 40+ working features while staying in sync with upstream over 6 months is possible?
I really enjoy working on this project and have been building everything that I felt missing in my setup. If you try it out and aren't happy with it, every release ships with a script that reverts your db to Immich, so you're never locked in.
Thank you for releasing this to the world! The features appear genuinely valuable.
Your response clears up a little about why this fork was necessary, as I had been wondering along with many others. It might make sense to be clearer about this to get ahead of the skepticism.
Would you say the code is acceptable for upstreaming into Immich but you just wanted to move faster? Your claim about there suggests the situation to be a little emotionally charged from their side, so I appreciate you highlighting the “friendly fork” and compatibility aspects.
Seems to be a fork of Immich. They claim performance is a goal but it's still written in Node.JS? Curious.
I tried to do something very similar a while back (https://github.com/denysvitali/immich-go-backend) but didn't fully follow through. Immich sucks, sadly, performance wise and in terms of storage (they don't support S3, WTF).
I'll eventually get back go it and complete my port.
I read their "why use our fork" page, and it's very obviously AI-written, which causes me to distrust it.
As a happy Immich self-hoster, I'm not excited by the idea of switching to a fork written by folks who can't even be bothered to write their "why this fork exists" explanation themselves. It inspires very low confidence both in the quality of the many additions (because of the vibecoding) and the long-term sustainability of the project (because of the lack of any effort, and because vibe-coded one-offs tend to die faster than labors of love).
Buried at the very bottom of the wall of slop text on their "why our fork" page is this very last "FAQ" question:
>Why fork at all instead of upstreaming features?
>Several Gallery-exclusive features (Shared Spaces, Pet Detection, contextual filters) were either declined upstream, considered out of scope, or required architectural changes that wouldn't have fit Immich's roadmap. Forking lets us experiment without slowing down the upstream team — and rebasing means we never lose touch with their progress.
There's no mention there of "our vibe-coded implementations of these features were declined by upstream because we vibecoded them"; instead, they frame it as "upstream doesn't want these features for their users", with a dash of "upstream has made bad design decisions" (particularly the note about how upstream Immich "required architectural changes").
That's more than a little disingenuous on "Noodle Gallery's" part.
You’re reading that into it. That is not what it says.
So far the Noodle communications feel considered, professional and friendly (that’s what a Claude sub buys you), while the Immich communication is just “vibe coded”.
Okay - is the code bad? Are you collaborating to improve it? The answer appears to be no, for reasons hopefully better considered than “vibe coded”.
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.
Please consider communicating it more like that rather than putting the focus on the process of the creation. This saves you some irritation by people like me who find it weird and unproductive to do the latter.
Additionally, the author claims to not have vibe coded the features, so some of your credibility is on the line here in claiming they did.
Sometimes, certain processes strongly predict bad outcomes, though.
If someone told me to choose between two barbecue restaurants, where one used an wood-fired smoker and the other used a microwave, my reaction wouldn't be "you really shouldn't judge based on just the process." The microwave is a sufficient indicator of low quality.
Vibecoding (as distinct from using AI as a resource while writing better code yourself) is the microwave: fast, hands-off, low-effort, low-quality.
S3 storage is the killer addition here for me. I have been wanting to use Immich for a while, but wanted to use all the spare s3 quota i have lying around rather than pay for storage..
Is it possible to integrate Noodle into iOS, i.e. upload new photos into noodle automatically, browse them on the iPhone and if I delete them on my iPhone sync this deletion to the server? AFAIK iOS discriminates against non-Apple apps and does not let them run background jobs.
Immich has an app that just needs to connect to an Immich server, which this would effectively be. It does the background sync, though I don't think it does the delete part.
The one caveat here is that, because Apple only really allows certain apps the privilege of running in the background without being interrupted or killed, I could never get the iOS version of Immich to reliably sync photos without having to manually open it and leave the app open until sync finished.
This was a few years ago, and was one of several "iOS breaks our crucial workflows" problems that motivated switching our last device over to Android, so the situation might be better now...but I've never had that problem with the Android client, so I know it's not an Immich problem.
You don’t need to run your app in the background. You can register your app as some extension to handle photo backups/cloud storage and you just setup a request to upload to a particular url when a new photo is added, iOS will background those requests and retry them and what not.
Why would you want this? What's the point of the server if you mirror deletes?
I have the opposite problem, well, my partner does. Her phone regularly fills up completely with pictures so I want to copy them to a server and then delete them from the phone, but for some reason this doesn't seem to be supported. My theory is Apple wants you to keep buying newer phones with exorbitantly priced storage upgrades.
>Why would you want this? What's the point of the server if you mirror deletes?
Sharing and backups, with the phone serving as the "source of truth" and the server as a replica that is more accessible to a partner/friend/etc than the contents of your phone's filesystem.
Please no AI slop. I don't want another app that spams my server megabytes per second because my proxy failed and the programmer didn't acknowledge the server can ever go down (talking about Immich - their retry mechanism used to be a while true loop with no back off nor retry limit) or the app resets the upload whenever I bring the app to foreground (also talking about Immich).
I know this post is about Noodle, but I want to talk about Immich.
I believe I've spent, perhaps, the most time of anyone on earth on digital photo management (hard to quantify, but since 2005 - 2 startups, one acquisition, and an ongoing open source project used by thousands).
I say that because I've refused to settle for most solutions in this space. Even when I adopted using Google Photos, it was as a read only viewer of my canonical photo library (I wasn't about to let Google take that responsibility). I have such high demands of whatever software I use for managing my photos and videos - they're really the only digital files I actually care about.
Immich is absolutely wonderful. It may have some shortcomings ... like partner sharing and sharing facial recognition between users. But man is it remarkable that an open source project can rival something from Google in terms of quality and experience.
And a soft fork like Noodle is precisely the way to handle it. I am perfectly happy with Immich so am not a user of Noodle. But it's open source flexing its strength.
I have great things to say as well. I left Google Photos about 1 year ago or two, used Takeout to export my ~terabyte of Google Photos, imported to Immich on my mac mini, along with more personal archives of photos. I store the images on an external SSD array (https://paulstamatiou.com/gear/owc-express-4m2-nvme-ssd-encl...) that I have backed up with Restic+Backrest to some cloud providers.
My mac mini hosts it behind tailscale to all my devices and it's been working great.
A tweet of yours a decade ago convinced me to add Google Photos into my workflow (thanks).
https://medium.com/swlh/my-automated-photo-workflow-using-go...
I removed it from my workflow when its integration with Drive was sunset.
I was without a great UI for a couple years, paying attention to Immich in my periphery. I decided to add Immich this year on a Mac Mini as well.
https://jaisenmathai.com/articles/my-ridiculously-robust-pho...
As someone looking to exfiltrate my photos from Google, I'm about to trial Immich, and I really appreciate you sharing your experience. Sounds like it's a good next step for me.
There's plenty of tutorials but you can request a Google Takeout of your photos and then point immich-go at it. I can confirm that this works really well.
https://takeout.google.com/?pli=1 https://github.com/simulot/immich-go
The problem with google takeout is that it generates hundred of files to download as ZIP. I tried it in my own collection (800GB).
Agree - it's annoying. rclone to the rescue. Requires choosing Google Drive as the destination and then downloading with rclone to your computer. It's the closest to sane I've found.
https://metadatafixer.com/learn/how-to-download-google-takeo...
Claude made a PHP script for me that did API to Google Photos and pulls them all to my archive location.
I struggled with Immich, I didn't like the rclone option. I'm intending to go back to Immich but my first priority was to get the stuff out of Google. That's done, so with all my free time (ha!) I can get the family Immich going.
Not sure if it's still the same but years ago when you get your own photos from Google photos via it's APIs you could only get large thumbnails so a great quality reduction. So make sure yours are the original quality. Takeout was the only way out your photos in original quality.
Nice. The PHP script could also write metadata back into the photo so it gets extracted by Immich on import. Just an additional prompt :)
I was planning on having Immich read from my archive. Then Immich on the phones sends right there (VPN?) and skips G all together. But maybe I'll end up with Amdroid->Google->PHP->Immich
Not sure if what I said made sense. I mean inject titles, descriptions, etc from the Google Takeout into the photos EXIF. Then when you import them into Immich, it'll extract those into its own database.
Since we're on Immich, please let me vent out my frustrations after having looked at it recently.
Why the love affair with forcing absolutely everything into strict temporal constraints? Is there a single view in Immich that isn't peppered with date headings?
And I genuinely do not understand what the sharing feature is even for. What are you sharing? It can't be albums because an album would be a series of photos you yourself arranged, independent of when the photos were taken, and this seems a completely foreign concept in Immich land.
Did you also look at https://ente.com/ ?
This looks really good. Thanks for reco.
Gonna add it to the moose store for self hosters
I was going to recommend ente as well.
My photos and videos are the most important files I have in my self-hosted storage system. Being end-to-end encrypted buys some peace of mind knowing that it's not end of world if my homelab is compromised. And I can backup the data to whatever public clouds without worrying too much about leaking data.
>But man is it remarkable that an open source project can rival something from Google in terms of quality and experience.
I'd argue Google is always way worse than the open source alternative in both quality and ux. Their products are terrible. From Gmail to Youtube, the product itself comes second (or Nth), while in open source the product is always first.
In my experience, most open source photo apps lacked basic features like facial recognition, mobile apps, etc. And where they do exist, the UX isn't the best. Are there ones I'm unaware of?
I say this as someone whose last startup (circa 2012) was an open source photo app (https://github.com/photo/frontend).
I think it's a testament to how far computers have come that identifying the individuals in a photograph is now considered a basic feature.
The Kano Model customer satisfaction theory:
https://ixdf.org/literature/article/the-kano-model-a-tool-to...Immich is great. I love it
Better link: https://opennoodle.de/
The submitted title’s framing “alternative to Google Photos and Immich” is dodgy because this is a soft fork of Immich, adding certain features, described in https://opennoodle.de/noodle-gallery-vs-immich/.
So it is Immich but they pointed Claude at it and let it go wild?
The entire landing page screams AI generated, all the typical front-end tells of Fable and Opus are there (the colours, the flashing status indicator, the fonts, the rounded tiles with the coloured left border, the claudisms, I could go on).
I don't know if I'm getting more sensitive to Claudisms because I've been reading them everywhere (and I use Claude a fair bit myself), but I feel like the comparison page is full of them.
Is "Claudism" Claude-specific signs that other models don't produce? Or would you describe any LLM signs as "Claudisms"?
> The shortcoming. Immich's face recognition is account-scoped. One real person becomes a separate entry in your library, in your partner's library, and in every shared album you both touch. Search for them and you get a third of their photos. Name them in one account and the name stays there. The People page tracks containers, not people.
This definitely reeks of LLM (I’m not even going to attempt to understand it). I’ve seen similar false contrasts and awkwardly worded sentences before in other LLMs, but GPT would probably say “rather than people” instead. Claude does have a distinct style (that, to be fair, is copied by many others, recently noticed it in GLM 5.3 Flash).
Claude definitely has it's own flavour.
It often talks about negatives and things that stuff doesn't do.
Thank you for that -- the workaround for multiple users sharing a set of photos plus their own stuff is the one thing that's kept my family away from adopting it.
Was there a reason these features were not accepted to upstream Immich and needed to be in a fork?
Looking at the latest commits, Noodle Galery has many signed with Claude, but Immich doesn't. Is LLM policy a reason for fork? (Just speculating, I don't know.)
UPD: Immich has this in CONTRIBUTING.md, seems like its LLM policy is more strict:
> We ask you not to open PRs generated with an LLM.
vs. Noodle Galery:
> We actively encourage the use of LLMs and AI coding tools.
My only issue with Immich is the partner sharing and face recognition overhead per account. It is a massive oversight. Looks like Noodle Gallery explicitly solves this (and more). I'm sold.
EDIT: hmm after reviewing the repo, I'm going to wait a bit to see how this works out. There's a difference between LLM-assisted software development and blindly vibe-coding things without review and this seems a bit like the latter. I see no contributors and hundreds of commits in a very short amount of time. That's a red flag for now.
Hey, I'm the main contributor to this repo. I do review the code - the reason why all of the commits are shown in a short time is just because of the way that I rebase on upstream Immich.
I have been working on this project for 6 months, and (contrary to what the Immich team posts every single time my project is mentioned) I do not blindly vibe code - or are folks saying that blindly vibe coding 40+ working features while staying in sync with upstream over 6 months is possible?
I really enjoy working on this project and have been building everything that I felt missing in my setup. If you try it out and aren't happy with it, every release ships with a script that reverts your db to Immich, so you're never locked in.
Cheers! Pierre
Thank you for releasing this to the world! The features appear genuinely valuable.
Your response clears up a little about why this fork was necessary, as I had been wondering along with many others. It might make sense to be clearer about this to get ahead of the skepticism.
Would you say the code is acceptable for upstreaming into Immich but you just wanted to move faster? Your claim about there suggests the situation to be a little emotionally charged from their side, so I appreciate you highlighting the “friendly fork” and compatibility aspects.
A better link: https://github.com/open-noodle/gallery
Seems to be a fork of Immich. They claim performance is a goal but it's still written in Node.JS? Curious.
I tried to do something very similar a while back (https://github.com/denysvitali/immich-go-backend) but didn't fully follow through. Immich sucks, sadly, performance wise and in terms of storage (they don't support S3, WTF).
I'll eventually get back go it and complete my port.
For more context: https://news.ycombinator.com/item?id=46171726
It's a soft fork not a rewrite, they regularly rebase off immich
Why is the link to a (seemingly) AI summary?
Their page: https://opennoodle.de
Their GitHub: https://github.com/open-noodle/gallery
It's not really an alternative to Immich as the title says, it's a fork that's continuously rebased with each release.
And quite a few of the features seem like common sense additions that should be pulled into Immich itself.
It's not entirely clear to me what warranted a forked release, are the immich devs not open to accepting some of these new features?
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)
I read their "why use our fork" page, and it's very obviously AI-written, which causes me to distrust it.
As a happy Immich self-hoster, I'm not excited by the idea of switching to a fork written by folks who can't even be bothered to write their "why this fork exists" explanation themselves. It inspires very low confidence both in the quality of the many additions (because of the vibecoding) and the long-term sustainability of the project (because of the lack of any effort, and because vibe-coded one-offs tend to die faster than labors of love).
Buried at the very bottom of the wall of slop text on their "why our fork" page is this very last "FAQ" question:
>Why fork at all instead of upstreaming features?
>Several Gallery-exclusive features (Shared Spaces, Pet Detection, contextual filters) were either declined upstream, considered out of scope, or required architectural changes that wouldn't have fit Immich's roadmap. Forking lets us experiment without slowing down the upstream team — and rebasing means we never lose touch with their progress.
There's no mention there of "our vibe-coded implementations of these features were declined by upstream because we vibecoded them"; instead, they frame it as "upstream doesn't want these features for their users", with a dash of "upstream has made bad design decisions" (particularly the note about how upstream Immich "required architectural changes").
That's more than a little disingenuous on "Noodle Gallery's" part.
You’re reading that into it. That is not what it says.
So far the Noodle communications feel considered, professional and friendly (that’s what a Claude sub buys you), while the Immich communication is just “vibe coded”.
Okay - is the code bad? Are you collaborating to improve it? The answer appears to be no, for reasons hopefully better considered than “vibe coded”.
Are you planning on hand-implementing any of the features he's vibe-coded? The search functionality in particular seems like a basic consideration.
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
Are you working with them to get the features into mergeable shapes? If not, are they refusing this or are you?
Is “heavily vibe coded” supposed to signal bad code quality or is it simply how it was created?
Thanks for chiming in. Is the issue that they are vibecoded, or specific issues with the changes themselves?
It'd be specific issues with the changes themselves, originating in them being vibecoded ;)
Please consider communicating it more like that rather than putting the focus on the process of the creation. This saves you some irritation by people like me who find it weird and unproductive to do the latter.
Additionally, the author claims to not have vibe coded the features, so some of your credibility is on the line here in claiming they did.
Sometimes, certain processes strongly predict bad outcomes, though.
If someone told me to choose between two barbecue restaurants, where one used an wood-fired smoker and the other used a microwave, my reaction wouldn't be "you really shouldn't judge based on just the process." The microwave is a sufficient indicator of low quality.
Vibecoding (as distinct from using AI as a resource while writing better code yourself) is the microwave: fast, hands-off, low-effort, low-quality.
Thank you
S3 storage is the killer addition here for me. I have been wanting to use Immich for a while, but wanted to use all the spare s3 quota i have lying around rather than pay for storage..
Is it possible to integrate Noodle into iOS, i.e. upload new photos into noodle automatically, browse them on the iPhone and if I delete them on my iPhone sync this deletion to the server? AFAIK iOS discriminates against non-Apple apps and does not let them run background jobs.
Immich has an app that just needs to connect to an Immich server, which this would effectively be. It does the background sync, though I don't think it does the delete part.
The one caveat here is that, because Apple only really allows certain apps the privilege of running in the background without being interrupted or killed, I could never get the iOS version of Immich to reliably sync photos without having to manually open it and leave the app open until sync finished.
This was a few years ago, and was one of several "iOS breaks our crucial workflows" problems that motivated switching our last device over to Android, so the situation might be better now...but I've never had that problem with the Android client, so I know it's not an Immich problem.
It works fine! The cost is a notification that the sync is running.
You don’t need to run your app in the background. You can register your app as some extension to handle photo backups/cloud storage and you just setup a request to upload to a particular url when a new photo is added, iOS will background those requests and retry them and what not.
Why would you want this? What's the point of the server if you mirror deletes?
I have the opposite problem, well, my partner does. Her phone regularly fills up completely with pictures so I want to copy them to a server and then delete them from the phone, but for some reason this doesn't seem to be supported. My theory is Apple wants you to keep buying newer phones with exorbitantly priced storage upgrades.
>Why would you want this? What's the point of the server if you mirror deletes?
Sharing and backups, with the phone serving as the "source of truth" and the server as a replica that is more accessible to a partner/friend/etc than the contents of your phone's filesystem.
Please no AI slop. I don't want another app that spams my server megabytes per second because my proxy failed and the programmer didn't acknowledge the server can ever go down (talking about Immich - their retry mechanism used to be a while true loop with no back off nor retry limit) or the app resets the upload whenever I bring the app to foreground (also talking about Immich).
> Please no AI slop
Does anything suggest that it is?
> I don't want another app that spams my server megabytes per second ...
Clearly this is independent of the use of AI, as elaborated by yourself.
> Does anything suggest that it is?
Read the website.
[dead]
[flagged]
[flagged]