Comment by mft_ | Hacker News Reader

Comment by mft_ | Hacker News Reader

Parent Full thread

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?

Being able to push prints and use the printer with direct local connection, while simultaneously having remote monitoring and remote printing when cloud/internet works and is available.

This is not the case of "wanting to have their cake and eat it too", as there is nothing mutually exclusive about these things. It requires no "emulation" or hacks - having a local API open to query state and push print jobs to the queue, while the printer connects to the cloud to publish state and pull the next job, presents no conflict.

Ultimaker has a similar feature set and had full local/cloud simultaneous integration. The only thing you "lost" by pushing a job locally was that when viewed in the cloud portal, the mini 3D model preview in the queue was missing, and only because they never bothered making the cloud solution pull it from the printer for local jobs.

But then they also did like Bambu and killed local printing entirely because they are all enterprise-only now want to sell you their higher Digital Factory subscriptions.

Thanks for confirming.

> Being able to push prints and use the printer with direct local connection, while simultaneously having remote monitoring and remote printing when cloud/internet works and is available.

So isn't an obvious approach to just cut Bambu out altogether and just create a FOSS cloud alternative, supporting the remote aspects that the users want to retain?

> This is not the case of "wanting to have their cake and eat it too", as there is nothing mutually exclusive about these things.

Nothing technically mutually exclusive, but isn't this exactly the choice that Bambu is enforcing? Which is crappy corporate enshittification behaviour, but something they can do if they so choose? (I'm not arguing in their favour - just trying to fully clarify the situation.)

I used the spaghetti-detective plugin/add-on for OctoPi when I got my printer, they also hit bandwidth of video streaming over web(part of the "monitoring" area) they seemingly have been absorbed into "obico"(the github remains github.com/TheSpaghettiDetective) Every 3DPrinter software has options to replace these Bambu Cloud features, the process involves a fair bit of deep dive understanding, flashing firmwares, troubleshooting bugs, and then you could in theory use the same machines with all the Bambu Cloud features, in a local environment.

My only gripe with the community approach is, why not replace them rather than attempt to use ANY servers they have? Jeff cleverly highlighted that all the slicers originate from Slic3r, there is always a point before Bambu.

> So isn't an obvious approach to just cut Bambu out altogether and just create a FOSS cloud alternative, supporting the remote aspects that the users want to retain?

Yes, you can do this with HomeAssistant and other tools.

> Nothing technically mutually exclusive, but isn't this exactly the choice that Bambu is enforcing? Which is crappy corporate enshittification behaviour, but something they can do if they so choose? (I'm not arguing in their favour - just trying to fully clarify the situation.)

Yep. There's an argument that the method they chose (attempted takedown of a repo derived from their plugin) is an AGPL license issue. My guess is that they will switch to a more advanced authentication strategy than "a User-Agent in open source code" and the enshittification on that side will just deepen.

I think people are right to be upset that Bambu initially offered both sides (local MQTT and their cloud) and subsequently made customers choose one or the other, but I've used Bambu printers offline plenty (to the point that I had to do the research to figure out why people were annoyed in the first place) and they still work really well; they didn't really hamstring the Developer mode (for example, you can still use all of the fancy Bambu-y features, like reading filament spool status, accessing the video stream over RTSP, etc.)

Reply on news.ycombinator.com