Don’t worry: That the Connect program hasn’t been finished in years, the sarcastic story writes itself. But maybe they’ll do it now. At least that would be a solution! 
I think the plot twist would be for Bambu to pull the network plug-in out of Bambu Studio and force the entire user base to use Bambu Connect to uploaded to printers and then point the finger at the “open source community” forcing them to do this. The user base that doesn’t care about open source is so much bigger than those that do.
In fact, that’s exactly what most open-source folks, and the others - though I won’t list them all here - are calling for: an optional programm, not a plugin that’s always installed and runs in the background… plus a proper implementation of the LAN features. Or, in short: “Local first.”
That wouldn’t be a plot twist, but rather what would actually bring peace to the matter. Important: It has to be optional.
Edit: I didn’t explain myself very clearly in that comment; please see my second comment, where I go into more detail. Thanks.
I will try to give my point of view on why this situation is good both for Bambu and for the consumer. This is merely based on my opinion as a consumer and also on my take as a business choice. I am not always right nor will i be.
They get “called out” once and for all and that means they have 2 choices.
1- They start their own Slicer from scratch, in whatever time it takes, and gain total control of their ecosystem. No more abiding to licenses, specially AGPL (that is why no company wants to fully commit to AGPL). Every Bambu user that is satisfied now will be satisfied in the future too since the system will work in tandem (hardware and software). They slowly regain the consumer trust and can have a chance of having their “walled garden”. After all, what company would not want what Apple has? (coming to this choice later)
2 - They keep the Slicer as it is and comply with AGPL licensing, making all components open source but they instate serial number recognition since all of their machines are properly identified already. It should be simple to implement (i am not a developer and i am “guessing”). That means that any fork that is made from Bambu Studio will be usable, except the connection to their cloud that will only authorize distinctive identifiers such as the serial number. If a machine is bought to them, they have all the data of the buyer already and it should also be possible to be traceable. But that means also that data will be collected (as i am sure it already is anyway).
Going back to point (1), the “Walled garden” approach. It would cause a big uproar and from a business perspective they don’t want to go that path. At least not yet. But eventually they will and that’s not good but it’s also not bad. They already gave all the signs of that happening in a near future but it has to be a slow and careful approach. Apple has a totally closed ecosystem and it works (although i am not much of a fan of Apple i still give merit where merit is due). Millions, if not Billions of Apple users are happy, whatever anyone will say.
Should they be called out? Absolutely! Sometimes the bad brings the good. And after the dust settles, usually everything turns out ok.
Now it’s time for me to go to bed before my wife throws me out the window 
Have a great night everyone
No. I don’t think anyone’s calling for that. Open-source folks will be mad because it’s still proprietary. Security folks will be mad because it’s still obscurity. All users will be mad because of worse UX with no benefits. Bambu will be mad because of controversy and less profit.
Local-first seems like a good idea either way but that isn’t really tied to this AGPL issue.
That’s how it works nowadays. The cloud requires any client (official, forks, …) to login before it can be used, meaning they know you own a printer because you bound it to your account before.
What Bambu is trying to achieve is to distinguish official from unofficial clients, which doesn’t really work in the first place and especially not once everything is open source.
Keep the context in mind. We’re not there yet - as I said, Bambu Connect has been in development for years and isn’t finished yet.
Of course, it would have to offer additional value: security, a better user interface, etc. These are just thoughts, after all; we’re talking about a future that’s still years away. In addition, it would have to be programmed for Linux as well.
In the bigger picture, we mustn’t forget that a middle ground is probably still the best option. If Bambu wants to block access to the cloud, that’s justified. However, they’ll also need to continue expanding the LAN mode.
It should be clear that in a situation like this, there aren’t just winners or losers. Let me give you an example: The Bambu mobile app is currently only usable via cloud; it would be nice if it also had an offline option. On the other hand, if only certain users are allowed to use the cloud, that’s legitimate, but clear rules need to be established and the licenses must be adhered to.
To achieve everything is impossible for any side. Just as Bambu would have every right to create a completely closed system for the next generation of printers if they were actually programming it themselves. The key point is simply this: not retroactive.
Maybe I should have expressed myself better in that comment, but I think this comment gives you an idea. Treating each other fairly. By that I don’t just mean customers, but also companies interacting with one another.
Nope.
client-side security? lol
user interface != user experience. again repeating myself: it wouldn’t be possible to achieve the same seamless workflow that bambu studio has rn without running into these AGPL issues again.
If Bambu wants to block access to the cloud, that’s justified
That’s an overstatement. If they want to implement generic mitigation against malicious cloud usage, that’s justified. If they want to block their own customers with a valid client from accessing the cloud in the intended way without causing harm, for no reason other than vendor lock-in, it’s not justified.
To be honest, I don’t understand what you’re trying to say. Why wouldn’t client-side and server-side security simultaneously be desirable?
Despite all the criticism - and I’ve certainly made a name for myself here as their harshest critic on more than one occasion - I find it hard to believe that Bambu wants to shut out its own customers. But what is true - and I say this myself - is that things are increasingly moving toward closed source.
Now we are back to the fun part of the argument. Last year this very network plugin was at the center of the controversy. That and the fact that the Panda Touch no longer works, But then even BIGTREETECH’s own web site warned people that it would no longer work with future Bambu updates.
There was a code snippet that was bantered around, claiming to be the smoking gun, exposing Bambu’s evil plans. Lots of talking points but no one was able to point out in the code where the nefarious action was to occur. When I read through the code there was code that sent data to and from an encryption routine. Which was in line with the notion that the network plug-in was intended to increase security. Most telling through, was how many of the open source advocates were upset over the use of the term “private” in the code snippet. Many complaining it proved that Bambu was exposing their private data. Apparently many are unaware that in computer coding, private means a variable that is local to a class or command, while public refers to a variable that is accessible throughout the program.
Here you are complaining that “It contains obfuscated code with a tamper resistant initialization sequence.” Seems to me that it is doing its job.
Bambu Studio does not function just fine without a mouse.
2 Likes
Can confirm.
Anyone tried Bambu Studio on the vision pro?
I would but then Apple would have to open source their OS because it works together with Bambu
For heaven’s sake, be glad you didn’t install it on Windows. Microsoft is already breaking out in sweat. Right now at Microsoft headquarters:
Well, not going to lie here… i tried on my Meta Quest 3 so that Meta has to open source their OS. Sadly they didn’t. But hey, it runs great, there’s that 
I’m not convinced a single word said here is genuine. Bambu labs just doesn’t want any competition to their software and wants control over your printer. Seeing this does not make me any less angry about this situation. I have a question for you, Bambu Labs: Is my next 3D printer going to be an X2D, or a K1 Max?
Right… The C++ source code has public, private and protected compile-time protection but that doesn’t extend to the compiled machine code. To state that in the context of a shared library (the plugin) is meaningless.
Oh.. and the tamper resistant initialization means that it can only be successfully initialized by Bambu studio (without a hack). So AGPL still applies since it’s part of the application under license.
Oh, and so you are also implying I can’t use Accessibility settings to move the cursor around with the keyboard… you know… without a mouse?
Anyway, thanks for playing…