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.

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

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

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?

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

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?