This is only true due to a firmware they pushed last year. It's an artificial limit.
There's no reason at all a local client couldn't just talk to a local printer without any cloud.
Every problem BambuLabs have here is self-inflicted. They could allow simultaneous cloud and local queue management with or without authentication.
Of course, many prefer to break their license agreement because They Really Want It, in effect daring Bambu to get aggressive with license enforcement. They probably won't...
If you want to use Bambu's software against their TOS, OK you wouldn't be alone in that, but there's no moral high ground in it.
In most countries, that would violate consumer rights. There's an ethics argument here.
Feel free to consult Steam, Google, Meta and others, if a software license is enough to ignore consumer rights.
Will this mean that Bambu will withdraw from the Australian market? Possibly maybe probably, but the ACCC takes a very hard stance against bait and switch.
I'd be reasonably happy to lodge a complaint if I could find a version that's reasonably articulated. As a Bambu customer in Australia I switched my printer to local mode and its been great.
Worth pointing out also that the US is the odd one out, here. Europe also enforces consumer rights.
Yes, it's not as simple as that, but it's not that impossible either.
This kind of firmware update to remotely disable feature is also illegal in the EU
Regardless, at least in the US, not only are software-based ToS becoming unenforceable, but there’s a large upswing towards “right to repair” legislation, which, I think, is what you’re arguing against here… and I really think you’re going to be on the wrong side of history with your current line of thinking (despite what Bambu Labs does).
I have no idea why you think copyright violations apply here? You seem to be throwing legal terms around without regard for their actual meaning. It's clear you're here to argue for the sake of argument, but I'd really encourage you to reflect and think about why you're so loyal to a corporate entity instead of your fellow consumers (of which there are many in the parent and sibling comments... hint: you may be on the wrong side).
Just for fun, pretend you bought a propane grill for cooking on Monday. On Tuesday, you cooked some bbq chicken and some corn. Later on Thursday, and without your knowledge or authorization, the grill no longer allowed you to use the propane apparatus for cooking non-meats unless you call a special telephone number and said a magic word whenever the call was answered. As a minimum, I feel, it'd be very confusing because, even though you're doing the exact same thing as Tuesday, the outcome is not the same.
Your freedoms have been restricted by someone else; if you are okay with that, then have fun licking boots. The rest of us will still be here advocating for your freedoms.
When I buy a product, I look at reviews and make my purchasing decision on the features and functionality at the time of sale. If a software update later ruins that, I want the option to get my money back.
At worst, its a fraudulent indefinite rental masquerading as a 'sale'.
And lets discuss 'updates that fuck over your hardware'. In dwcent countries, thats hacking, and a serious criminal charge. But lol, companies are somehow exempt.
There’s a small benefit of anti-circumvention where businesses sell hardware for cheaper with restrictions and a TOS that prevents bypassing them. But even that doesn’t apply here because Bambu changed the software after purchase.
> If you want to use Bambu's software against their TOS
How does the TOS get involved here? I don't use their TOS. Why would or should they be able to enforce it? Note that it also depends on the jurisdiction. For instance, Microsoft's EULA never had any legal bearings in the EU.
https://europa.eu/youreurope/citizens/consumers/unfair-treat...
Nobody is arguing against Bambu's legal right to be arseholes.
If so, then yes, the software too
The issue here is less "they put in a restriction" and more "they are trying to bankrupt/imprison consumers for daring to modify the property they purchased."
I could interpret this three ways:
1. It's a reflexive double-down "nuh uh" denial, with no deeper cause.
2. You jumped in without knowing the risks that people (regular non-rich ones, anyway) face from lawsuits or CFAA charges, and you assumed the OrcaSlicer maintainer abandoned their project just to be polite.
3. You're whining that Bambu lawyers were "forced" to make disproportionate threats with nonsense logic. (Which isn't a huge step up, because it means they're still telling threatening lies for their own benefit.)
Legal representation typically has a cost associated to the individual, unless you have the state put down a lawyer for you. You could assume that bankrupting may not be the primary goal by Bambu Lab, but it most assuredly can be an associated outcome, in particular if your income is comparatively low. I don't think sarcasm is appropriate here.
By attempting to stop users from using their AGPL code they are behaving illegally.
By "many" do you mean Bambu Lab themselves who are violating the AGPL license of Prusa slicer & predecessors with their non-AGPL, proprietary networking plugin?
They're choosing to violate the license because they don't think anyone will actually dare to sue them, and they're probably right. Ascribing some sort of moral righteousness to Bambu's actions and accusing users of breaking their license is hysterical.
They should have no rights to control how people use hardware they bought. ToS for hardware should simply be unenforceable.
People should have full rights to adversarial interoperability, even if it means modifying proprietary software or hardware.
It always surprises me when people (on this site particularly) are more interested in the law as it stands than how things could or should be.
I wonder whether tech has become so exploitative partly because so many of us have lost track of (or never understood) how important civil disobedience has always been in the process of democracy and securing our rights.
As an individual you really don’t have to follow the terms of service! You certainly don’t have to support the [ab]use of ToS, DRM and related tech to screw you at every opportunity!
AGPL software can be used and modified within the limits of what the AGPL permits. People can do that with their Bambu software running on their own hardware.
That does not extend to using their proprietary BambuNetwork cloud service (somebody else's computer). The AGPL specifically mentions this scenario in section 6. There are open source alternatives to that like the third-party Bambu-Farm and bambuddy that people can self host instead.
Interestingly, Bambu's own initial approach to the AGPL was more in line with "modifying and using AGPL software however they want" (and potentially violating their section 6 obligations), until customer backlash forced them to adhere to the terms of the licence.
As I said, I believe people have a right to "adversarial interoperability", so I respectfully disagree
While I agree that the AGPL does not grant users any rights to Bambu's cloud service, sending DCMA nastygrams to people hosting copies on old versions of their software isn't the right (or even legal) way to enforce that. And since Bambu choose to build their products and software stack on pre existing AGPL code, they've backed themselves into a corner a bit with other options. They can add new auth to new versions of the code (which is stringer than just hardcoded useragent-like strings in the code) but they'll then have to release the source code to their new version - exactly like the original authors who chose the AGPL intended.
However, the AGPL comes with no right to such network access to begin with. Permission to access the network would usually come separately from the AGPL; I suppose you could potentially bundle it as an additional permission under section 7, but I don't think Bambu is doing that.
To take it a step further, even if you use the latest official software, installed by the vendor (and not by you), they can still refuse you access to their network. That might violate some other agreements or laws (e.g. contract to provide a service), but it does not violate the AGPL itself.
What they cannot do is prevent you from running your modifications on your hardware.
> [...] they can still refuse you access to their network.
Sure, they can and yes, AGPL doesn't give users right to just access services, I have said before that they may enforce their EULA upon individual users. They are however not doing that, they are harassing repo owners. Let me put it this way: If the network access were the issue, as you seem to think, why go after the dev hosting your code rather than the individual users that you claim improperly access your services.
> What they cannot do is prevent you from running your modifications on your hardware.
They also cannot prevent a developer from rehosting AGPL code, but they are trying to do that. And it's kind of the actual issue.
That's why I was asking specifically regarding what level of code modifications is acceptable for them. Because they made this an issue not about using their servers but hosting code, regardless of how it's used.
I agree. I think the argument they are going for is similar to that from Google against yt-dl, but unlike in that case, Bambu is obligated to allow this codebase.
The C&D presumably wanted him to remove the ID/version string or at least stop distributing it, i.e., they only want real BambuStudio on their cloud and that was the laziest way to achieve that
AGPL does not have a "don't be an asshole" clause
Bambu's issue is with him taking a fork of Orca and spoofing some data (from THEIR FREELY AVAILABLE SOURCE CODE) to appear as Bambustudio to their servers.
A contract that says you can park in my driveway doesn't give you permission to access my garage and use all my tools.
Absolutely a dick move but not really not abuse of a contract.
He redistributed a derived work under the same terms and got hit with the threat of legal action.
I don't know what "access my garage and use all my tools" is supposed to be an analogy for in this situation.
Accessing my garage and using my tools == using Bambu's cloud infrastructure, which they clearly do not want him (or apparently any non-BambuStudio clients) doing any more.
I agree that they might possibly have a case to go after individual users. They don't have a case to go after this guy for distributing a fork of their software with their own publicly available user-agent string unmodified. Threatening to do so is very much against the spirit if not the letter of the license that they're using.
Using their cloud infrastructure without authorization is different from distributing a fork of their software. They may have a legitimate gripe with the former, but they threatened legal action against the latter. If they didn't want people distributing a fork that could connect to their cloud infrastructure by just using their code verbatim, maybe they shouldn't have designed it that way.
It is embarrassing that copying that one little thing made a third party fork able to connect to their cloud because A) that would be embarrassing for smaller IoT devices and we're talking about thousand-dollar printers and B) it's highly regarded to be saying on the one hand that your cloud needs security while on the other hand a simple copy/paste of a single function bypassed the security of said cloud that needs protecting.
I agree he would win in court. I don't think they ever planned to even file a complaint. I disagree that it is against the spirit of the AGPL. Signal does the same thing (here's our source code but only our official app can officially connect to our servers and we can ban your app at any time) as far as I can tell and no one complains about them and their shit is AGPL 3.0 only.
As I already said, I don't think they would have any beef with him if he removed that single function - the one that enables use of their cloud infrastructure. The exact problem they have with him, is his distribution of that. I agree that he can distribute it, and they would lose any lawsuit about that. I also agree that its on them to fix it. But returning to the original point, by making source code that can be so easily copied available for download, they have not violated the AGPL. They are not saying he can't distribute his own Orca fork or even his own BambuStudio fork. They're saying "Stop making it connect to our servers" which again I agree is actually their problem. The C&D is just a lazy stopgap.
Again, abuse is different from violation. I agree that they're not violating the AGPL merely by threatening legal action. They would be if they actually took legal action. The fact that they're threatening to violate the license in order to get what they want but still take advantage of what the license grants them is IMO abuse of that license.
If we sign a contract that says you're allowed to park in my driveway in exchange for $10, then I threaten to sue you for parking in my driveway, technically I'm not violating our contract. It's not an issue until I actually sue. But I'm still abusing our contract by threatening you for doing something I explicitly allowed you to do.
Likewise, Bambu was able to benefit by forking and distributing AGPL software in exchange for giving everyone a license to do the same for their fork. Then they turned around and threatened legal action against someone for doing what they previously said was allowed. This may not technically be a violation but it's definitely abuse.
There's no reason I couldn't access through the cloud on my phone and from Orca locally without any cloud. The spool management is on the physical printer. I don't need Orca to use their cloud; it just needs to chat to the printer.
You can even go so far and have a public sub domain for each devices ( serialnumber.manufacturer.com ) which you only operate as a dumb proxy so that even the TLS certificates are negotiated end-to-end between the IoT device and Let's Encrypt. (The devices connect to your backend via Wireguard and you rate limit with their device individual key, whose public key you read out during the end-of-line production step.)
Hell, with today's browser heavy applications you can even run the whole slicer in the browser. Let the app be distributed via CDN so the code does not need to go through the proxy.
[1] In the case of non-battery operated and always or mostly on devices, like 3d printers at least.
This sounds really unpleasant to use. Maybe users just want a better UX for the local mode?
Using an AGPL violating mystery meat binary plugin that you run on your host, which potentially compromises any airgap you put around your printer (it attempts to connect to bambu servers, or did last time I checked it) and potentially your entire host.
Can you read the filaments installed in the printer over MQTT too?
Here's a good resource: https://github.com/Doridian/OpenBambuAPI
More likely, it's technical incompetence. It's just easier (for their cloud) to send everything through their cloud
It seems more likely they want it as a revenue source at some point.
The current monetization that they are using is that you can charge for a print on their platform and they take a cut of the sale. If you don’t charge for the design, then it is still free hosting and delivery.
I see where the worry is, but at the moment it seems like people are imagining a worse case scenario.
No, we aren’t being blocked. Turn on LAN mode, pair regular Orca slicer, ignore Bambu for the rest of eternity. Plenty of people have done it.
You're just saying that Bambu users feel the need to purposely circumvent Bambu's artificial restrictions to be able to continue to use Bambu hardware they bought and paid for.
No matter how you frame this, this ain't right.
It's a toggle you set in the printer directly, nothing is circumvented. Only the access through their cloud service is impacted, but the printer works locally like any other.
That's an artificial vendor tie-in, and arguably a feature that only involves their client app and their backend. It's understandable if access to their backend is restricted to a subset of their users if that's the business model they wish. Preventing paying customers from using the hardware they bought and paid for by imposing artificial restrictions is not cool.
They've bought a machine that executes gcode and that it does (at least to my understanding) regardless of where that gcode comes from.
If you want special secret sauce gcode from the bambu cloud, you need to use the bambu cloud.
Those are not the same thing, so IMO it is legit what they do there, because it's such a clear-cut split. You own the physical thing but not the ecosystem around it.
___
I would of course personally never buy a bambu lab printer, because they're cloud-tied nonsense that was going to behave exactly like that (the split between hw and ecosystem), but other people knew that too and still bought it, because "what a nice ecosystem".
idk. I just don't think that "right to repair" should mean "right to be saved from the consequences of my own bad actions".
Those bad actions continuing to have no real painful consequences (and with that no real learnings + behavioral correction) after all is why the state of tech has become as bleak as it is right now.
And, honestly, if you can afford a bambu premium machine, there's a 97% chance that you could easily shoulder a total write-off. There's also a 97% chance that your ego can't, but that's the main thing causing all the bad things in the world and should've died a long time ago. Approximately post-highschool.
I wouldn't buy an alternative to a P1S, because only the P1S is the best at being the P1S. (Whatever that might entail)
Instead, I'd look at things from the perspective of "what do I want?" and not "What does the market offer? Okay, I want that thing. But no, I want an alternative to it that is that thing but without downside"
Letting a brand set your frame of reference is the first step into total dependence.
It shouldn't be too complicated and not too expensive. E.g. while the Prusa Core One+ seemed nice (from a superficial look) it costs more than I wanted to spend. P1S came out as the best (barely) adequate printer for what I thought I would need when I looked at it. But it's difficult to say if you are a beginner and basically have no idea...
That's what I meant with "the P1S is the best at being the P1S when measured by the P1S".
I am pretty sure that if you for example do functional PLA parts, there will be many, many more options that tick exactly that box.
I do of course understand that people want to have the mental peace of buying one thing and being told that it can do everything, but, as said, you pay for that emotional labor with lock-in and eventually being rug-pulled.
The only way of not getting rug-pulled is not handing away all of your agency wholesale just for cheap immediate emotional relief.
That's how it works, how it has always worked and how it will always work. Anyone claiming anything else is in the process of actively scamming you.
I feel you on every point, but I'd point out that they sell VERY reasonably priced replacement parts for basically everything on the A1 Mini that I have that is worth repairing.
Take a step back. What users want is to be able to use the machine they bought the way they want. The outrage is because Bambu are doing a bait-and-switch: selling an autonomous 3D printer, but switching to a 3D printing service. Enshittification pure and simple.
A different way of looking at it is that Bambu is saying if you want to use their cloud you have to send everything through their cloud. Stupid? Sure. It's very much a technically solvable problem. But I don't think there was any rug pull (this time; in Jan 2025 they tried...)
I think this is all more out of incompetence than malice. Something bad happens, exposing wildly inadequate programming expertise, they panic and over correct, and the community pushes back. They're great at making 3D printers, terrible at cloud infra.
Technically true, because bait-and-switch refers merely to advertising an attractive product offer in order to lure people into a pitch for a different product.
In this case, they actually sold a product, then decided to maliciously alter the product after it was sold to modify its behavior. That makes this a much more serious offense, equivalent to trespass, vandalism, or possibly even burglary.
It's equivalent to selling someone a house that includes a secret entrance that you retain access to, so you can surreptitiously enter the house to steal the new homeowners' property after they've moved in.
Excellent machines by the way, primarily let down by the proprietary binary Bambu forces users to use for LAN mode which is extremely buggy and slow on Linux, and entirely technically unnecessary.
Developer mode doesn’t require the proprietary binary.
There are two problems here. One is when the manufacturer sells something with some capabilities and later pulls the rug from under the users and decides to arbitrarily take some features away. This should entitle any customer to take an arbitrary amount of money back from the manufacturer. The second problem is that after a customer buys the product they aren't allowed to own it. If I buy a hammer I'm, allowed to cut it open, dissect everything, modify the handle or the head. That's ownership, not some shallow dismissal that user want to "have their cake and eat it too".
If someone sells you a cake then follows you down the street to take the frosting and one of the layers back, and tells you that any attempt to restore the cake is a crime, you'd start questioning whether it's really your cake to begin with, and what exactly are you eating.
It looks like it might be a clone, but the git history is squashed for some reason.
I would recommend against installing this unless/until someone can do an audit to figure out which commit it was forked from and what the changes are.
Or better yet, find one of any of the other copies of the repository that don't have their git history squashed.
This looks like someone's attempt to capitalize on the drama to bring attention to their foundation (?) but losing git history is not a good thing for code provenance or security.
FULU Foundation is a right to repair group, which explains their interest in this. I, for one, support them. https://www.fulu.org/our-story
I agree with your point about git history, though. https://github.com/FULU-Foundation/OrcaSlicer-bambulab/issue...
This isn't the thing you're talking about. There's a mode where I can send prints directly over the network which disables Bambu Studio, I assume?
This is a very dubious opinion to hold. Taking your claim about local mode at face value, there is absolutely no reason to disable monitoring when working on LAN mode. You need to go way out of your way to implement that restriction so that it works differently when the thing phones home or not. You are free to criticize implementation decisions that you feel make it "untrustworthy" but those are trivial to address if you think about it.
I really recommend you to reassess your whole philosophical stance on having corporations prevent you from using what you bought and paid for.
tl;dr: The original developer does not (or cannot) go into legal battle with Bambu Lab, so Louis Rossmann's project picked up the fight and hosts the (allegedly) troublesome code on their organization. As they have more financial resources, they look forward to the C&D letter.
The point he has (and I agree with that): The original developer is using the un-modified AGPL-code to talk to the cloud API. Bambu Lab states that the modified client pretends to be a Bambu lab client. But in fact, the modified client just uses the code as-is, which is perfectly fine from a AGPL perspective. From my non-lawyer point of view: If Bambu Lab would have made the User Agent a configurable variable, which gets set by some configuration files from outside the code, that get bundled with the binary version, but not the source code, they wouldn't have this leverage.
> What users want is to "have their cake and eat it too;" they want the local token authentication _and_ the cloud authentication enabled at the same time. This isn't actually possible, so this plugin approximates it by emulating the interface to the cloud authentication to make the "Bambu Network" cloud RPC calls from a local slicer (one of these calls is a local_print call, so ostensibly this allows you to send prints without running them through the cloud, although with all of the online functionality still enabled and required, this seems like a pretty brave thing to trust).
AIUI Bamba has made cloud access all or nothing: you either use local mode, with local slicing, and no cloud feature access at all, or you use cloud mode, with cloud slicing and access to all of the cloud features.
Can anyone explain what the cloud features that people want to retain are? Is it just app control of the printer, and print monitoring? Or are there other things to miss out on?
This is not the case of "wanting to have their cake and eat it too", as there is nothing mutually exclusive about these things. It requires no "emulation" or hacks - having a local API open to query state and push print jobs to the queue, while the printer connects to the cloud to publish state and pull the next job, presents no conflict.
Ultimaker has a similar feature set and had full local/cloud simultaneous integration. The only thing you "lost" by pushing a job locally was that when viewed in the cloud portal, the mini 3D model preview in the queue was missing, and only because they never bothered making the cloud solution pull it from the printer for local jobs.
But then they also did like Bambu and killed local printing entirely because they are all enterprise-only now want to sell you their higher Digital Factory subscriptions.
> Being able to push prints and use the printer with direct local connection, while simultaneously having remote monitoring and remote printing when cloud/internet works and is available.
So isn't an obvious approach to just cut Bambu out altogether and just create a FOSS cloud alternative, supporting the remote aspects that the users want to retain?
> This is not the case of "wanting to have their cake and eat it too", as there is nothing mutually exclusive about these things.
Nothing technically mutually exclusive, but isn't this exactly the choice that Bambu is enforcing? Which is crappy corporate enshittification behaviour, but something they can do if they so choose? (I'm not arguing in their favour - just trying to fully clarify the situation.)
My only gripe with the community approach is, why not replace them rather than attempt to use ANY servers they have? Jeff cleverly highlighted that all the slicers originate from Slic3r, there is always a point before Bambu.
Yes, you can do this with HomeAssistant and other tools.
> Nothing technically mutually exclusive, but isn't this exactly the choice that Bambu is enforcing? Which is crappy corporate enshittification behaviour, but something they can do if they so choose? (I'm not arguing in their favour - just trying to fully clarify the situation.)
Yep. There's an argument that the method they chose (attempted takedown of a repo derived from their plugin) is an AGPL license issue. My guess is that they will switch to a more advanced authentication strategy than "a User-Agent in open source code" and the enshittification on that side will just deepen.
I think people are right to be upset that Bambu initially offered both sides (local MQTT and their cloud) and subsequently made customers choose one or the other, but I've used Bambu printers offline plenty (to the point that I had to do the research to figure out why people were annoyed in the first place) and they still work really well; they didn't really hamstring the Developer mode (for example, you can still use all of the fancy Bambu-y features, like reading filament spool status, accessing the video stream over RTSP, etc.)
> I didn't understand what people wanted here
Great: very few people care enough to actually try to understand! This is very much appreciated.
> What users want is to "have their cake and eat it too;" they want the local token authentication _and_ the cloud authentication enabled at the same time
No.
What I want is to use any slicer software (specifically OrcaSlicer, which is really good) with Bambu printers without losing functionality.
What most people who do not use 3d printing regularly do not understand is that there is more to 3d printing than just throwing a sliced file over the wall. For example, before I slice, I sync information from the printer so that the list of filaments I have in the slicer reflects what is actually in the printer. This sounds silly to people who imagine a printer with a single spool of filament loaded, but when you have multiple printers, each one with an AMS unit housing 4 spools, this becomes essential.
Please also remember that many people have printers in remote locations (workshop). "LAN mode" is a non-starter unless you set up a VPN.
I also want to monitor my prints using my phone, which is what Bambu Lab sold me: it is part of the functionality of the printer. I do not want to lose that functionality.
In other words, "LAN/Developer Mode" is NOT EQUIVALENT to "Cloud" mode (which used to work well with OrcaSlicer until Bambu killed it).
While I kinda sorta need my 3d printer more than my 2d printer, it's an absolute nightmare in a way that my 2d printer isn't, and it's caused entirely by the dogshit proprietary software I have to use in order to print things.
My A1 still has the old firmware where mqtt is exposed - this totally works for me to tinker with, and I don't understand their motivation to cut us off.
I also don't understand their stance to limit client software - I found a bunch of bugs in their package, filed one in their github project, and never heard anything of it, while they continue to ship features. So they don't care for their software (or linux users?). They should allow the community to fix their shortcomings.
Bambu absolutely could create a system where their printers both communicate with the cloud and local devices, they just don't want to do the difficult software engineering necessary because it is difficult. This is not theoretical either; I work on production devices with hybrid cloud and local functionality. Engineering around a zero-trust threat model (as in you assume the user can and will tamper with the device) is completely doable.
For instance, using a push-only RPC model where only the cloud can initiate a request is one zero-trust strategy that can be used for ensuring a predictable network load on cloud infrastructure, which seems to be their main concern.
The 2nd thing, and the reason the linked repo is now hosted by Louis Rossman (YouTuber / Consumer Rights guy) is that Bambu are abusing the AGPL license of the original slicer code. TL;DR is that Bambu Slicer is a fork of an AGPL lineage of similar tools. The gatekeeper of the cloud features hosted by Bambu was a user agent string embedded in the AGPL code. The original dev of the linked repo just copied and pasted AGPL code, and Bambu sent a cease and Desist. At least Louis Rossman believes that violates the AGPL terms against additional restrictions which is why he is hosting the repo, because the original dev was chilled from wanting to deal with the legal threats.
I did a ton of research because I didn't understand what people wanted here, and this is what's going on:
Right now, Bambu have adjusted their system into two modalities:
* "default" or "Cloud" mode, where you get an app, remote monitoring, but you have to use Bambu Studio or Bambu Connect to send prints. They implemented this by adding cloud auth to their "internal API;" the client application has to get a token from Bambu's servers, even if the request it eventually makes is a "local" one.
* LAN / Developer mode, where the device displays a token and you put it into your app. This disables all of the remote monitoring but in exchange, clients can send prints locally.
What users want is to "have their cake and eat it too;" they want the local token authentication _and_ the cloud authentication enabled at the same time. This isn't actually possible, so this plugin approximates it by emulating the interface to the cloud authentication to make the "Bambu Network" cloud RPC calls from a local slicer (one of these calls is a local_print call, so ostensibly this allows you to send prints without running them through the cloud, although with all of the online functionality still enabled and required, this seems like a pretty brave thing to trust).
Personally, I find the Bambu reaction distasteful, and there's an argument that the offline mode only exists due to similar outrage, but I don't see the current system as particularly bad and find the appetite to restore "untrustworthy" cloud functionality a bit amusing.