Restore full BambuNetwork support for Bambu Lab printers (opens in new tab)

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.

> 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).

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.

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.

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

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.

> 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 sounds really unpleasant to use. Maybe users just want a better UX for the local mode?

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.

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.

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 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?

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've always been told it's called business. But I fully agree with you. Just wanted to note that this is the current business model both with hardware and software

Fundamentally, what Bambu are saying is that they have a right to restrict what software accesses their network. The C&D was allegedly sent to stop distribution of software that was written to access their network in an unauthorized fashion (Allegedly according to their ToS).

AGPL covers source code. It does not cover who can access what network with AGPL'ed software.

Thus Bambu - like it or not - have a right to limit what software accesses their cloud. You are still free to do whatever you want with Bambu's AGPL'ed software. But they don't have to let you on their network if they don't want to.

With that out of the way, sending a C&D is a pretty regarded way to accomplish this. The correct way would be to sniff out which clients are using 'real' Bambu Studio and which aren't. However according to Bambu, Pawel specifically modified BambuStudio (ya know, because they haven't violated the AGPL, because he is free to do that) to make it look like Studio.

I can only assume that actually locking down their network for real would require every Bambu printer to have a firmware update that would add some sort of signed encryption to access the cloud features. The C&D appears to be a shitty action prior to a huge undertaking.

I do wonder exactly how secure their super spendy "Enterprise" X1E printer could possibly be given how easily Pawel was able to make a fork work on their cloud.

As to your second paragraph about functionality and theft, 1) I can still print from Bambu's cloud with my Bambu printer so I don't think they've changed any functionality, and I can still use Orca in LAN mode. and 2) designed obsolescence exists.

I disagree with your assertion that because forks were able to access cloud functionality previously, that Bambu must maintain that functionality ad infinitum. My opinion would change if anyone showed me where previously they were promoting how any third party apps could access their cloud.

I haven’t read each of the hundreds of comments, but I haven’t seen anyone defending Bambu really.

What I have seen is a lot of comments trying to correct all of the bad information, which might look like defending Bambu labs to those who came into this thread not understanding what the problem was. Many of the angry comments think that this is a fork to enable LAN mode or remove a cloud requirement, but this is actually the opposite. It’s code to splice the Bambu cloud code from official Linux slicer into OrcaSlicer, which is a fork of the Bambu slicer.

This is allowed and should be defended. Bambu was wrong to try to threaten it because, as I understand it, this was a matter of merging some of their AGPL code into a fork of their AGPL code. Fair game.

I do think the angry mob of people who don’t own Bambu printers who have jumped on this issue is starting to become their own worst enemy, though. There are a lot of confused Bambu printer owners in this thread trying to understand what’s going on and getting the wrong explanations delivered by people who I would guess have no understanding of the situation other than being brought here by some YouTube videos that didn’t really explain the matter well either. There’s also apparent a foundation getting involved which has a vibecode AI slop website that doesn’t explain anything but it getting shared as an explanation, and this GitHub repo was also uploaded by someone who doesn’t understand git or GitHub because they uploaded a copy of the forked code as a single commit instead of keeping git history or introducing it as a real fork.

I suggest that this repo not be used by anyone because it’s not good practice to run a fork without verifying the provenance and checking the changes, which cannot be done when the repo is nothing more than an upload of a copy of some source with no link to the base repo and no history of changes. There are several other actual copies of the fork on GitHub and linked throughout this thread that would be better sources.

Factually, it is not. Maybe you think it should be prohibited -- as I also do.

But the proper legalese here is likely a consumer protection regulation.

It could be argued that it is not theft by various devious uses of legalise¹.

Personally I'd go with calling it, at best, deceptive sales practices (on the assumption that they knew they'd be moving this way long before they did), or possibly outright fraud if I'm in a less generous mood.

[FYI: Bambu A1 user for nearly two years, also have a Snapmaker U1, if I buy anything else it won't be Bambu unless their attitudes change. The A1/A1mini are still two of the best budget beginner printers IMO, though some clones come close, and I do recommend them if asked but with caveats around potential lock-in later and not believing promises due to a history of changed online posts, deliberately excluded from the WayBackMachine, and what to my understanding is an AGPL breach]

--------

[1] “There is a way to use the feature, so it isn't an attempt to permanently deprive”, or “you agreed to the possibility of such changes in the EULA”, and so on.

From Louis Rossmann himself.

When it's companies based in the U.S. or EU, like Chamberlain / LiftMaster garage door openers, it's pretty obvious they plan to monetize some cloud services subscription for upgraded features beyond the free basic tier as well as probably selling consumer data.

However, the China-based companies like Bambu Lab (and many others) are more puzzling because meaningful ongoing subscription revenue seems unlikely. Especially in the case of lower-end consumer tech peripherals where the companies usually invest as little as possible in their websites, ongoing feature updates or direct end-user support. Which makes no sense if they really aspire to build long-term subscription revenue. Here's my theory: the Chinese government is quietly compelling them to require cloud connections to China-based data centers as a long-term strategy.

I'm not even saying the companies are some direct arm of the Chinese government or planting nefarious firmware. I think that's too likely to be caught if done at mass scale and it's not even necessary. As long as the cloud servers are in Chinese data centers, the Chinese government can get consumer IP addresses and usage data just from passive packet sniffing and if things turn icy with some foreign countries, they can cause a lot of turmoil simply by selectively blocking packets at the firewall to brick millions of consumer devices.

I know it maybe sounds paranoid and, to be clear, I'm not claiming Bambu Labs specifically is doing this. I actually came up with this theory before I ever heard of Bambu Labs because I have a lot of inexpensive Chinese home automation devices and was surprised by their bizarre insistence on forcing cloud connectivity despite there being no apparent business model incentive and these smaller-scale Shenzen hardware companies showing zero enthusiasm for making a real business out of cloud services. Their cloud implementations are almost invariably the bare minimum possible and seem woefully underfunded. After all, for a low-margin hardware peripheral, every dollar spent running a no-revenue cloud after the sale is pure overhead in a business that live or dies by pennies. It's almost like requiring a cloud connection is an export tax the company is paying just to be left alone to sell their hardware overseas.

For home automation gear, cloud-connectivity is a non-starter in my book. In some cases, it's literally built into our walls, so I only buy devices which will work on a local-only subnet or on which I can install open source firmware like Tasmota or ESPHome.

People just ignored it because, shiny!

But for example I had some problems with my linear rods, talked to support for just a few minutes and 2 days later I had replacement parts at my door. This was a few years back though.

Also they give firmware updates, and even hardware upgrade for years! This IS really nice and I'm not sure any other printer manufacturer that sells to private people does this.

Yes, your upfront price is a bit higher. I say it's worth it.

It was absurdly cheap for its spec (£260 is what I paid, delivered) and can be run entirely without internet access with no issues. People were a bit miffed when they announced a v2 with multi-filament support, but they just announced an addon to upgrade the first version to a similar spec and it's again really cheap - £55 delivered here in the UK.

If I was printing more professionally I'd probably go for a Prusa, but the cost/benefit isn't there for someone new to it, unless you have plenty of dosh - in which case go for it. As someone getting into it, the price of the Centauri Carbon is so reasonable that it's hard to argue against it.

I think it depends mostly on how you expect to use it. There may be alternatives that give you perfect prints with minimal fuzz. But for me it was great to have a machine I dare play around with. Like getting a tractor before a race car :)

I don’t mind the sd card thing, also happy with my bottom of the barrel ender 3.

I get it. The convenience of networking - when it works FOR the customer - is great.

But networking controlled by corporations is a path to enshittification.

So when they claim “we never said that” it is less easy to prove that to be an, erm, incorrect statement of truth.

It could be an accident due to over-doing scraper protection, but given the company's general behaviour of late I'm inclined to consider the negative interpretation more likely.

> but you can still see the original post for now: https://blog.bambulab.com/firmware-update-introducing-new-au...

I'd hazard a guess that that is not entirely the original post as it was before things erupted. There have been a couple of instances of materially changed posts.

Because they have a track record of altering their website, gaslighting the community, and then getting caught through archive.org so they simply blocked it, not realizing that other archives exist and then getting caught again.

They tried to alter their warranty terms and got caught. They altered their ToS which would allow them to block prints until the printer firmware was updated. When the community got upset, they not only backpedaled but altered the associated blog post and accused everyone of spreading baseless misinformation because "it's clearly explained in this [edited, backdated] article".

That's precisely the article you linked to. See the original version:

http://archive.today/2025.01.16-173123/https://blog.bambulab...

Think about why they'd make such a request to archive.org.

There’s basically no information there. Is this just a copy of the other GitHub repo that was removed and someone is trying to rebrand it as their own? Or did they do some different work?

There are many reasons one might prefer OrcaSlicer over Bambu Studio. One might be perfectly fine using Bambu's cloud services while preferring OrcaSlicer for different reasons; this is for those people.

Others might not want to use Bambu's cloud services at all; OrcaSlicer as it currently exists is fine for them.

Their business model is a straightforward "sell a good product at a reasonable price" approach, and they seem to be quite successful at it without needing to resort to gimmickry, subscription fees, or other even less savory ways of monetizing other people's activities.

Bambu is not (never has been?) targeting 3D printing hobbyist but everyday people; and for them cost/reliability is more important than running your custom slicer. Until there is a serious competitor that has a polished and cheap printer, Bambu can alienate all of the open source community and still be fine.