Comment by bri3d
14 hours ago
This looks to be a clone of the prior state of the repository that caused all the Bambu drama earlier this week.
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.
> This isn't actually possible
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.
All of their issues are self-inflicted. What benefit is there to their cloud backend except getting around the home NAT? If you want to build your IoT product privacy-friendly, your cloud offering can be reduced to a STUN/rendezvous server and a proxy server as fallback [1]. Ship your devices with individual tokens to rate limit the proxy, have the STUN/rendezvous/proxy server address configurable and publish their source code for users to not be dependent on your continuous operation.
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.
I dont understand what the issue is. Theres not really any benefit in having cloud enabled if local is working fine. I have my bambu printer set to local only, and dont miss the cloud offer one bit.
There abusing the AGPL. At this point, it’s on principle.
I imagine some (many?) people just enjoy accessing their printer over the mobile phone without setting up VPN, even if said mobile phone isn't on the home wifi.
[flagged]
They have no rights to prevent people modifying and using AGPL software however they want.
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!
3 replies →
> many prefer to break their license agreement because They Really Want It
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.
A comment defending abusive software terms on a website called HackerNews. Something amusing about that.
1 reply →
The AGPL covers the line of code that includes the user agent, the only "security" bambu uses.
By attempting to stop users from using their AGPL code they are behaving illegally.
This is HP’s current philosophy towards consumer desktop inkjet and laser printing, and customers universally hate it. No thanks!
It is my right to do with my printer whatever I want.
30 replies →
> it's their right to enact that restriction on their software
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."
4 replies →
Ok, so as a heavy user of Bambu printers:
> 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).
A lot of people don't understand just how bad the 3d printer ecosystem can be. Most people understand how bad HP/Epson/Canon ink printers can get, but they really need to understand that 3d printers can be worse than that.
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.
On our Bambu H2D Pro printers at work, we can print in cloud mode and LAN mode at the same time. Bambu literally has this firmware built but they reserve it for “pro” users. The other thing pro users can do is disable cloud without any developer mode stuff. Of course we do this.
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.
I think the enterprise “LAN Mode” is actually the thing this repo is emulating / replacing, which the consumer printers (might?) also support, where the cloud auth token is still in play but prints are (ostensibly, in a much more difficult to audit way given the client still needs access to the Bambu servers) sent directly to the printer.
Developer mode doesn’t require the proprietary binary.
There's no technical hurdle to achieving both modes or access types (local and cloud) simultaneously. This isn't a technical issue. Selling "Home" and "Pro" devices that are differentiated is also not necessarily a problem, a company is allowed to sell two products with different features and pricing.
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.
Wow I didn’t know about developer mode! I wonder if that will improve things for me…
> This looks to be a clone of the prior state of the repository that caused all the Bambu drama earlier this week.
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.
> attention to their foundation
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 actually possible
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.
This is fair and I should have been more clear that I meant “possible under their current self-imposed constraints;” of course it’s all software so anything is possible (for the record, I also agree that this is a much harder problem than people are giving it credit for).
There is some context missing, which this video [0] explains.
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.
[0]: https://www.youtube.com/watch?v=1jhRqgHxEP8
I'm also trying to get my head around this, as an interested-but-not-directly-involved observer.
> 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?
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.
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.
Thanks for confirming.
> 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.)
1 reply →
Personally I'd be fine with the LAN mode assuming I don't have to use their cloud even once.
You're missing two things from the whole picture: 1. Cloud mode works without local network access, so their server is involved in the transit of the data to the printer. This is pretty minor, but still within their rights to preserve. 2. For printing from the app, they actually run the computationally expensive slicing algorithm on their servers, so this is totally reasonable to protect.
But in this case the users want to use those features locally and are being blocked. Using a resource constraint argument doesn't make sense for it.
It seems more likely they want it as a revenue source at some point.
Pretty sure you can still print locally either via LAN or just SD card. At least I can on my A1.
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.
> But in this case the users want to use those features locally and are being blocked
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.
2 replies →
If you turn on LAN mode, it acts exactly like every other printer. You can print directly to it from any slicer over your LAN, or dump gcode on the SD card directly.
3 replies →
They probably want to establish a commercial-use license. If you have a big print farm, you likely need all of those remote capabilities so you're going to need to pay for the license. The schmucks at home will likely continue to get it for free. Locking them into the cloud API by dangling convenient features just ensures most people won't stray into the local-only mode.
> 2. For printing from the app, they actually run the computationally expensive slicing algorithm on their servers, so this is totally reasonable to protect.
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.
Is it artificial though?
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.
5 replies →
> What users want...
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.
I don't think they baited and switched? I bought my P1S before the whole LAN mode debacle and even then it was all or nothing on the cloud. I just went with the cloud because they were using some IGMP stuff for the local connection, but I had the printer on a separate VLAN and pfsense IGMP proxying was broken.
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.
> I don't think they baited and switched?
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.
For me, I want to use orca for slicing there are many more additions to the local code. As both orca and Bambo are from the same open source, the current limitation in the Bambo version is breaking the licensing of the application, and my rights in that software are broken by this addition. Then, during the print, I'm really happy to use the handy app to monitor the progress. This use case was supported when I got the hardware. Now I have to disable the app to get the slicer. I actually like to use both slicers to compare and see progress. They are also terrible at software licensing, don't understand what open source is, and they found their main software on that. They probably should embrace the orca community and use their research for their own customers. Better slicing helps everyone.
> where the device displays a token and you put it into your app.
This sounds really unpleasant to use. Maybe users just want a better UX for the local mode?
I believe it's a one time pairing code, not each print. FWIW I like the design.
It's more of an API key that whatever client or code you're using needs.
it uses MQTT, FTP, and RTSP. the key and serial are the credentials.
Just to confirm so I don't break anything accidentally, I currently have the app version where Bambu Studio is how I send prints to my Bambu P1S and I can look through its camera and see what filament is where and so on, but I also have the token that Home Assistant uses to watch the printer and its camera etc.
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?
Why should I have to send all my prints to Bambu when the printer is sitting right next to me? Why do I have to choose between being able to stop my printer remotely or Bambu not tracking my every move, when it's trivial to have both?
it's because you're the product and they want the designs i think
I don't think so. They can already track popularity very effectively because they control makerworld, and they could have Bambu studio, the app, and the printer phone home too. I don't think they care enough about the tiny tiny minority of users running orca with a LAN only printer.
More likely, it's technical incompetence. It's just easier (for their cloud) to send everything through their cloud
1 reply →
> clients can send prints locally
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.
No, the binaries aren’t necessary in LAN + Developer mode.
Correct - you can send prints over MQTT
3 replies →
> (...) I don't see the current system as particularly bad and find the appetite to restore "untrustworthy" cloud functionality a bit amusing.
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.
Found the corpo cuck
[flagged]