The list of fake concerns they list are not the real and very valid concerns I have seen. This addresses nothing.
This does in-fact address quite a bit, because they have change their stance with this update. Previously even LAN only mode required to go via their bambu connect system, now you can switch it to developer mode and talk freely via MQTT to the printer.
- Want to introduce x, but we are worried what our userbase thinks.
- Introduce something way more ridiculous y that subsumes x.
- Rollback y but not x because of backlash.
Now they look like a company that listens to their users and they got what they wanted.
Don't get me wrong I'm glad they're responding to feedback but the feedback shouldn't have been required in the first place.
I'm all for better security on products(esp ones that heat up to 300C!) but interoperability with open standards makes it a better product overall and given the direction we've seen in the IoT space I think they've done quite a bit of damage(even if not intentionally) by not taking more care in this area.
For LAN mode yes, but for how the printer works — not exactly. Right now you can print from a 3rd party slicer (Orca Slicer) and at the same time use Bambu Handy mobile app to for example monitor the print. LAN mode disables the cloud connection (always has). Which means that with the revised changes you have to choose either a 3rd party slicer _or_ active cloud connection
If you mean that OrcaSlicer will reimplement Bambu Connect protocols inside — I doubt that will happen, since Bambu Connect is not open source, so this would involve reverse engineering the protocols and potentially including Bambu Connect certificates.
Or you can turn off security and use "developer mode", aka. "how things work today" mode, if you want to do things the old / insecure way.
There's also other limitations of it in features I don't really use, for example IIRC the RFID stuff they do with their print spools stops working.
But yes today there is no need to use their cloud services unless you want to control the printer with their phone app. And the printer works totally fine completely isolated from the internet.
The now aborted proposed update would have required using a binary shim from bambu with an embedded 1 year lifetime SSL cert to speak the the printer at all, even when in lan mode.
Whether or not it’s simply greed or that they didn’t make as much selling the printers as they had thought. The next step to closing an API and killing 3rd party interactions is almost always so they can introduce some form of continuous monetization scheme.
That was always something that rubbed me the wrong way with Bamboo Labs. They threw an absolutely obscene amount of money at influencers. Essentially buying a ringing endorsement from nearly the whole hobbyist community and made their brand a household name.
The time was right to pull the switch.
This whole kerfuffle only sours me to them. I like the printer but the desktop software quality is low and features in LAN mode are not available for what one can only think of as a shity move to Hoover up data for the enshitification
Only the maintainer of an API knows what the future plans are. Not making future plans public is the way to avoid Osbourne incidents and to actually deliver real things, not just vacuous promises.
From my dabbling with MQTT, Tasmota and home built sensors; MQTT has no versioning and limited hierarchy in the pub / sub model. I'm not surprised Bambu didn't want a 3rd Party product to "integrate" with it. (Disclaimer, I don't know what it is used for, I don't have the products)
In my experience, if you need to fix something that has an undesigned API or needs interfaces or communications methods to change, what you do is build a "New Interface" with what you want and temporarily bridge it to the old one. The desired plan is, once everyone moves to the new interface, the old things can be sunset.
Sadly, this is the utopian view. From what I've seen, 3rd Parties often give the middle finger and just keep using the old stuff. The 3rd parties or customers then complain bitterly when the "New Interface" only comes out - the "blame", rightly or wrongly, is usually directed at the software update. Shouldn't 3rd Parties also be held to account and have a duty to maintain their integrations?
Building, supporting and evolving products is challenging - I've rarely see people put the right structure in place for v2.0, v3.0 when frantically working to get v1.0 out. Mistakes will be made and they are very, very expensive to fix (reputation, engineering time, QA) in the future.
From the statement made, I await a response from Panda Touch - will they commit to fixing their product and inform their customers?
That's why any sane software uses a stable public API and an internal one that can be closed off or has breaking changes all the time.
> MQTT has no versioning and limited hierarchy in the pub / sub model
It's currently handled like this: https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md. Would it be a far stretch to add an "api_version":x field and a "internal_" prefix for some commands?
How does it not address the concerns of people?
Hum, the alternative is OrcaSlicer stops working with Bambu printers...
I don't know if the OrcaSlicer maintainers feel this way. But if they feel that Bambu Lab is stabbing them in the back, they don't have to jump when Bambu Lab tells them to (that's pretty much the raison d'être of open source).
The alternative is that users have to manually use bambu connect and that seems inferior to what the PR enables.
Yes. That's where the maintainers need to decide if they are Bambu Lab's lackeys or if they have a say in their beloved project. Part of that is thinking about at what point the project becomes pointless as a meaningful BambuSlicer alternative.
> The alternative is that users have to manually use bambu connect and that seems inferior to what the PR enables.
Everything is going to be inferior to using BambuSlicer. That is Bambu's real intent.
The OrcaSlicer maintainers probably have the most leverage (what little there may be) on Bambu Lab. I think that is why Bambu Lab is keen to offer the PR on GitHub. The maintainers should exercise whatever leverage they have while they still can.
I understand your anger, but I don't think that properly describes the situation. As a maintainer of an open source project your users are who you are about. If your users want support for bambu connect, then you are likely to implement it. Whatever Bambu does is whatever Bambu does, you need to accept it.
> Part of that is thinking about at what point the project becomes pointless as a meaningful BambuSlicer alternative.
Why would OrcaSlicer become pointless if it supports Bambu Connect? It also supports the Bambu network plugin.
> Everything is going to be inferior to using BambuSlicer. That is Bambu's real intent.
What would Bambu's motivation be to do that? I don't think they would have built Bambu Connect if the goal is not to support third party slicers to directly send things to the printer. Note that most 3d printers on the market didn't or still don't have integration into slicers.
> Whatever Bambu does is whatever Bambu does, you need to accept it.
And maybe it is time to take your ball and go home.
> What would Bambu's motivation be to do that?
What is Bambu's motivation for being cloud first when it is not technically necessary? Why can't OrcaSlicer be a first class citizen like BambuSlicer? Instead it has to go through Bambu Connect which is inherently clunky and less featureful. It's simple. Control, and vendor lock-in. Possibly, Bambu sees this as a way to curtail print farm automation software from other vendors.
The raison d'être of Orca Slicer is to slice files for 3D printers. They don't manufacture printers. They have no raison d'être if they don't support one of the major players in the 3D printing space.
It's clear you like your Bambu Lab printer/s. But I think you are letting it cloud your judgement. Bambu Lab is being predatory here.
But, because people don't understand security technology tradeoffs, everything becomes a conspiracy.
Bambu Lab is introducing something else. Most charitably, it could be described as security through obscurity, which is never secure. More realistically, Bambu Lab is introducing vendor lock-in under the pretext of security. Vendor lock-in is what this change actually achieves.
It's about a vendor trying to control an experience for its users balancing its UX and maintenance costs.
There's no real vendor lock-in here beyond the usual conspiracy "Bambu Lab is better therefore they're evil unless they give it all away for free to their competition", that's a pile of nonsense. Orca Slicer and 3rd party slicers will continue to work with the new approach if they can work out the details of the PR that uses Bambu Connect.
Interestingly some banks do use x509 client authentication for corporate accounts or high net worth accounts but they expect you to know how to import the key to your browser. And almost all banking mobile apps use this to call their server APIs to ensure only the Bank's mobile apps (or partners) can call their APIs.
In Bambu Labs' case, they've had many DDOS attacks and other issues with their security and so they're forcing a constraint on the approved software clients that can access their printers and/or cloud service via client authentication. BambuConnect being the catch all proxy software for most.
Bambu is forcing its customers to use its cloud offerings when many users want to use the machine on their LAN without the cloud guff. Many for security reasons. Bambu essentially tells its customers to pound sand, they are forced to use cloud. Now Bambu is claiming it has a cloud DDOS problem and therefore it is going to lock down what users can do further. I'm sorry, that's just silly. Let me connect to the printer locally, and your cloud DDOS problems go away.
The DDOS problem itself doesn't sound particularly compelling as a justification for this action, either. If every user action is authenticated, you know which users are abusing the system - throttle them or kick them out. Adding a TLS certificate for mutual authentication is going to reduce the DDOS overhead by a negligible amount.
> forcing a constraint on the approved software clients
Which will do nothing against a determined DDOSer since they will always be able to extract the certificates from Bambu Connect, or BambuSlicer.
Finally, if the issue is airtight security for the on-prem printer and preventing a hacker external or internal to the LAN from exploiting them. Maybe Bambu can take a page from the Matter smart home specs. if they are out of ideas. These are solved problems. Cloud not necessary. Software lockdown not necessary.
The issue is introducing further measures which don't provide any security benefit to the user (can be spoofed): only allowing critical commands from BambuConnect.
Which is fine, no? Plenty of other good printers available.
Nah, this is influencer-generated bro science sentiment. They do nothing special, and hardly never come out on top in any serious independent print quality tests.
Their primary competitive advantage right now the AMS bundle being very competitively priced.