← Back to context

Comment by oliwarner

12 hours ago

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

All of their issues are self-inflicted. What benefit is there to their cloud backend except getting around the home NAT? If you want to build your IoT product privacy-friendly, your cloud offering can be reduced to a STUN/rendezvous server and a proxy server as fallback [1]. Ship your devices with individual tokens to rate limit the proxy, have the STUN/rendezvous/proxy server address configurable and publish their source code for users to not be dependent on your continuous operation.

You can even go so far and have a public sub domain for each devices ( serialnumber.manufacturer.com ) which you only operate as a dumb proxy so that even the TLS certificates are negotiated end-to-end between the IoT device and Let's Encrypt. (The devices connect to your backend via Wireguard and you rate limit with their device individual key, whose public key you read out during the end-of-line production step.)

Hell, with today's browser heavy applications you can even run the whole slicer in the browser. Let the app be distributed via CDN so the code does not need to go through the proxy.

[1] In the case of non-battery operated and always or mostly on devices, like 3d printers at least.

I dont understand what the issue is. Theres not really any benefit in having cloud enabled if local is working fine. I have my bambu printer set to local only, and dont miss the cloud offer one bit.

  • I imagine some (many?) people just enjoy accessing their printer over the mobile phone without setting up VPN, even if said mobile phone isn't on the home wifi.

[flagged]

  • They have no rights to prevent people modifying and using AGPL software however they want.

    They should have no rights to control how people use hardware they bought. ToS for hardware should simply be unenforceable.

    People should have full rights to adversarial interoperability, even if it means modifying proprietary software or hardware.

    It always surprises me when people (on this site particularly) are more interested in the law as it stands than how things could or should be.

    I wonder whether tech has become so exploitative partly because so many of us have lost track of (or never understood) how important civil disobedience has always been in the process of democracy and securing our rights.

    As an individual you really don’t have to follow the terms of service! You certainly don’t have to support the [ab]use of ToS, DRM and related tech to screw you at every opportunity!

    • > They have no rights to prevent people modifying and using AGPL software however they want.

      AGPL software can be used and modified within the limits of what the AGPL permits. People can do that with their Bambu software running on their own hardware.

      That does not extend to using their proprietary BambuNetwork cloud service (somebody else's computer). The AGPL specifically mentions this scenario in section 6. There are open source alternatives to that like the third-party Bambu-Farm and bambuddy that people can self host instead.

      Interestingly, Bambu's own initial approach to the AGPL was more in line with "modifying and using AGPL software however they want" (and potentially violating their section 6 obligations), until customer backlash forced them to adhere to the terms of the licence.

      1 reply →

  • > many prefer to break their license agreement because They Really Want It

    By "many" do you mean Bambu Lab themselves who are violating the AGPL license of Prusa slicer & predecessors with their non-AGPL, proprietary networking plugin?

    They're choosing to violate the license because they don't think anyone will actually dare to sue them, and they're probably right. Ascribing some sort of moral righteousness to Bambu's actions and accusing users of breaking their license is hysterical.

  • A comment defending abusive software terms on a website called HackerNews. Something amusing about that.

    • If we go a little meta, there's a lot of comments doing the same thing, on plethora of submissions. It's amusing and sad at the same time.

  • The AGPL covers the line of code that includes the user agent, the only "security" bambu uses.

    By attempting to stop users from using their AGPL code they are behaving illegally.

  • This is HP’s current philosophy towards consumer desktop inkjet and laser printing, and customers universally hate it. No thanks!

  • It is my right to do with my printer whatever I want.

    • The hardware yes. Bambu's software, not quite. If you want to flash it with 3rd party firmware & use 3rd party slicers, have at it.

      If you want to use Bambu's software against their TOS, OK you wouldn't be alone in that, but there's no moral high ground in it.

      28 replies →

  • > it's their right to enact that restriction on their software

    The issue here is less "they put in a restriction" and more "they are trying to bankrupt/imprison consumers for daring to modify the property they purchased."