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

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

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.

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

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?

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.

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

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?

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

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?

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

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