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.
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.
Proprietary plugins in [A]GPL software are always contentious. It's the old linking argument and it's especially strong here, given how useless Bambu Studio is without the networking plugin.
I disagree. They’re redistributing software under the AGPL while trying to prevent others from using the same freedoms they’ve been granted by the license.
The fact that Pawel was able to copy their source code and paste it into an Orca fork is direct proof from Pawel himself that they are honoring the AGPL.
The C&D presumably wanted him to remove the ID/version string or at least stop distributing it, i.e., they only want real BambuStudio on their cloud and that was the laziest way to achieve that
Pawel still has access to the Bambu-modified software, which is what the AGPL covers. There is no violation there.
Bambu's issue is with him taking a fork of Orca and spoofing some data (from THEIR FREELY AVAILABLE SOURCE CODE) to appear as Bambustudio to their servers.
A contract that says you can park in my driveway doesn't give you permission to access my garage and use all my tools.
Absolutely a dick move but not really not abuse of a contract.
The AGPL does not just say he has to have access to the modified software. It also says he has to be granted permission to redistribute it, or derived works, under the same terms.
He redistributed a derived work under the same terms and got hit with the threat of legal action.
I don't know what "access my garage and use all my tools" is supposed to be an analogy for in this situation.
He is free to remove the part where it spoofs itself as BambuStudio and do whatever the hell he wants with it. He can probably distribute it with the spoof and continue without actually getting sued because they are likely fixing this as I type this. If they do sue him it will be for unauthorized use of their cloud services. I do think they'd have to sue individual users.
Accessing my garage and using my tools == using Bambu's cloud infrastructure, which they clearly do not want him (or apparently any non-BambuStudio clients) doing any more.
The "spoof" as you call it is literally just using their unmodified code. You make it sound like he went in and deliberately changed it so that it would connect. He did not. That part of the code was left unchanged from Bambu's own publicly available source code.
I agree that they might possibly have a case to go after individual users. They don't have a case to go after this guy for distributing a fork of their software with their own publicly available user-agent string unmodified. Threatening to do so is very much against the spirit if not the letter of the license that they're using.
Using their cloud infrastructure without authorization is different from distributing a fork of their software. They may have a legitimate gripe with the former, but they threatened legal action against the latter. If they didn't want people distributing a fork that could connect to their cloud infrastructure by just using their code verbatim, maybe they shouldn't have designed it that way.
He copied the code from BambuStudio into an Orca fork to make it connect to Bambu's cloud. That is A) deliberate and B) easily meets the definition of spoofing.
It is embarrassing that copying that one little thing made a third party fork able to connect to their cloud because A) that would be embarrassing for smaller IoT devices and we're talking about thousand-dollar printers and B) it's highly regarded to be saying on the one hand that your cloud needs security while on the other hand a simple copy/paste of a single function bypassed the security of said cloud that needs protecting.
I agree he would win in court. I don't think they ever planned to even file a complaint. I disagree that it is against the spirit of the AGPL. Signal does the same thing (here's our source code but only our official app can officially connect to our servers and we can ban your app at any time) as far as I can tell and no one complains about them and their shit is AGPL 3.0 only.
As I already said, I don't think they would have any beef with him if he removed that single function - the one that enables use of their cloud infrastructure. The exact problem they have with him, is his distribution of that. I agree that he can distribute it, and they would lose any lawsuit about that. I also agree that its on them to fix it. But returning to the original point, by making source code that can be so easily copied available for download, they have not violated the AGPL. They are not saying he can't distribute his own Orca fork or even his own BambuStudio fork. They're saying "Stop making it connect to our servers" which again I agree is actually their problem. The C&D is just a lazy stopgap.
If we sign a contract that says you're allowed to park in my driveway in exchange for $10, then I threaten to sue you for parking in my driveway, technically I'm not violating our contract. It's not an issue until I actually sue. But I'm still abusing our contract by threatening you for doing something I explicitly allowed you to do.
Likewise, Bambu was able to benefit by forking and distributing AGPL software in exchange for giving everyone a license to do the same for their fork. Then they turned around and threatened legal action against someone for doing what they previously said was allowed. This may not technically be a violation but it's definitely abuse.
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.
There's no reason I couldn't access through the cloud on my phone and from Orca locally without any cloud. The spool management is on the physical printer. I don't need Orca to use their cloud; it just needs to chat to the printer.
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.
Id Louis Rossman's YouTube rant is correct, nobody involved here modified the AGPLK software. They just used a version of the AGPL software from before Bambu Labs changed the auth code.
While I agree that the AGPL does not grant users any rights to Bambu's cloud service, sending DCMA nastygrams to people hosting copies on old versions of their software isn't the right (or even legal) way to enforce that. And since Bambu choose to build their products and software stack on pre existing AGPL code, they've backed themselves into a corner a bit with other options. They can add new auth to new versions of the code (which is stringer than just hardcoded useragent-like strings in the code) but they'll then have to release the source code to their new version - exactly like the original authors who chose the AGPL intended.
If I just build the software from their repo without any modifications, getting an identical result to what I can download via their website, would I be allowed to use the service? If not, why not? If yes, what if I made a modification? How much may I change and where was this ever codified? What about using an unmodified, prior version of the source code to build? Why would that not be ok?
Interesting question. In the first case, where you install your own build from unmodified source code, although AGPLv3.0 still allows discontinuing support, I see no explicit carve-out in the licence to restrict network access.
However, the AGPL comes with no right to such network access to begin with. Permission to access the network would usually come separately from the AGPL; I suppose you could potentially bundle it as an additional permission under section 7, but I don't think Bambu is doing that.
To take it a step further, even if you use the latest official software, installed by the vendor (and not by you), they can still refuse you access to their network. That might violate some other agreements or laws (e.g. contract to provide a service), but it does not violate the AGPL itself.
What they cannot do is prevent you from running your modifications on your hardware.
But they had no access control in the first place. If I built their repo without modifications, I automatically have access. I would need to make modifications not to get that access.
> [...] they can still refuse you access to their network.
Sure, they can and yes, AGPL doesn't give users right to just access services, I have said before that they may enforce their EULA upon individual users. They are however not doing that, they are harassing repo owners. Let me put it this way: If the network access were the issue, as you seem to think, why go after the dev hosting your code rather than the individual users that you claim improperly access your services.
> What they cannot do is prevent you from running your modifications on your hardware.
They also cannot prevent a developer from rehosting AGPL code, but they are trying to do that. And it's kind of the actual issue.
That's why I was asking specifically regarding what level of code modifications is acceptable for them. Because they made this an issue not about using their servers but hosting code, regardless of how it's used.
> 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.
That's a highly creative interpretation of events. The software license agreement usually upfront covers what can or cannot not change. It is pretty rare in most countries to see successful legal action for changed features, but best of luck.
They will just fine them into oblivion; they are known to fine companies AUD10M to AUD50M for this sort of thing, and from 1st April this year they can now fine up to AUD100M.
Will this mean that Bambu will withdraw from the Australian market? Possibly maybe probably, but the ACCC takes a very hard stance against bait and switch.
The largest ACCC fine to date for a company undertaking anti consumer practices is $483m against an educational provider for misleading students.
I'd be reasonably happy to lodge a complaint if I could find a version that's reasonably articulated. As a Bambu customer in Australia I switched my printer to local mode and its been great.
It's a whole lot better than the US, but AUD100M isn't enough to scare a lot of companies. A law with real teeth would go after an increasing percentage of their revenue for each offense.
As a percentage of global revenue, sure, it's not much. But as a percentage of what that company is likely to make in the Australian market, it can be significant.
Taking functionality away from a product after you bought it is a scum move. If the law lets them get away with it, the law should be changed.
When I buy a product, I look at reviews and make my purchasing decision on the features and functionality at the time of sale. If a software update later ruins that, I want the option to get my money back.
No, it’s not creative at all, it’s what happened — I have first hand experience to corroborate this.
Regardless, at least in the US, not only are software-based ToS becoming unenforceable, but there’s a large upswing towards “right to repair” legislation, which, I think, is what you’re arguing against here… and I really think you’re going to be on the wrong side of history with your current line of thinking (despite what Bambu Labs does).
No, it is with you -- the legislators are doing "fine" (and, again, are heading in a fine direction wrt RTR and software ToS).
I have no idea why you think copyright violations apply here? You seem to be throwing legal terms around without regard for their actual meaning. It's clear you're here to argue for the sake of argument, but I'd really encourage you to reflect and think about why you're so loyal to a corporate entity instead of your fellow consumers (of which there are many in the parent and sibling comments... hint: you may be on the wrong side).
Just for fun, pretend you bought a propane grill for cooking on Monday. On Tuesday, you cooked some bbq chicken and some corn. Later on Thursday, and without your knowledge or authorization, the grill no longer allowed you to use the propane apparatus for cooking non-meats unless you call a special telephone number and said a magic word whenever the call was answered. As a minimum, I feel, it'd be very confusing because, even though you're doing the exact same thing as Tuesday, the outcome is not the same.
Your freedoms have been restricted by someone else; if you are okay with that, then have fun licking boots. The rest of us will still be here advocating for your freedoms.
The "agreement" is at best coerced, and under blackmail of hardware you bought and paid for.
At worst, its a fraudulent indefinite rental masquerading as a 'sale'.
And lets discuss 'updates that fuck over your hardware'. In dwcent countries, thats hacking, and a serious criminal charge. But lol, companies are somehow exempt.
Maybe legally, but morally “you have permanent physical access to this but don’t ’own’ it” and anti-circumvention are debatable.
There’s a small benefit of anti-circumvention where businesses sell hardware for cheaper with restrictions and a TOS that prevents bypassing them. But even that doesn’t apply here because Bambu changed the software after purchase.
"Bambu's software" is forked from an AGPL project and is therefore itself AGPL. I have a right to fork, modify, and use it how I wish subject to the terms of the AGPL. Bambu's TOS is irrelevant. Their TOS is superceded by the terms of the AGPL.
This reminds me of RMS and GPLv3. Now I personally don't use GPLv3, but this here is literally a case-in-point, and it is not even only limited to the "cloud-only". Because this now includes a company threatening to sue a developer. If they sue one developer, they, by proxy, sue all of them in principle. So RMS was kind of right.
> If you want to use Bambu's software against their TOS
How does the TOS get involved here? I don't use their TOS. Why would or should they be able to enforce it? Note that it also depends on the jurisdiction. For instance, Microsoft's EULA never had any legal bearings in the EU.
> 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."
> Bambu is trying to bankrupt/imprison their customers? Big if true!
I could interpret this three ways:
1. It's a reflexive double-down "nuh uh" denial, with no deeper cause.
2. You jumped in without knowing the risks that people (regular non-rich ones, anyway) face from lawsuits or CFAA charges, and you assumed the OrcaSlicer maintainer abandoned their project just to be polite.
3. You're whining that Bambu lawyers were "forced" to make disproportionate threats with nonsense logic. (Which isn't a huge step up, because it means they're still telling threatening lies for their own benefit.)
Have they threatened financial pressure? The answer to this question is: yes.
Legal representation typically has a cost associated to the individual,
unless you have the state put down a lawyer for you. You could
assume that bankrupting may not be the primary goal by Bambu Lab, but it
most assuredly can be an associated outcome, in particular if your
income is comparatively low. I don't think sarcasm is appropriate
here.
Great: very few people care enough to actually try to understand! This is very much appreciated.
> 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
No.
What I want is to use any slicer software (specifically OrcaSlicer, which is really good) with Bambu printers without losing functionality.
What most people who do not use 3d printing regularly do not understand is that there is more to 3d printing than just throwing a sliced file over the wall. For example, before I slice, I sync information from the printer so that the list of filaments I have in the slicer reflects what is actually in the printer. This sounds silly to people who imagine a printer with a single spool of filament loaded, but when you have multiple printers, each one with an AMS unit housing 4 spools, this becomes essential.
Please also remember that many people have printers in remote locations (workshop). "LAN mode" is a non-starter unless you set up a VPN.
I also want to monitor my prints using my phone, which is what Bambu Lab sold me: it is part of the functionality of the printer. I do not want to lose that functionality.
In other words, "LAN/Developer Mode" is NOT EQUIVALENT to "Cloud" mode (which used to work well with OrcaSlicer until Bambu killed it).
I run in LAN/Developer Mode on the X1C and P1S and I sync filaments just fine. I don't monitor my prints with my phone but if I wanted to I wouldn't complain about the lack of Bambu support on the DEVELOPER MODE! I think the clear call to action here is to DEVELOP your own software.
A lot of people don't understand just how bad the 3d printer ecosystem can be. Most people understand how bad HP/Epson/Canon ink printers can get, but they really need to understand that 3d printers can be worse than that.
While I kinda sorta need my 3d printer more than my 2d printer, it's an absolute nightmare in a way that my 2d printer isn't, and it's caused entirely by the dogshit proprietary software I have to use in order to print things.
Really? My 3D printer uses filament from any vendor. My slicer has profiles for all of these filaments and printer combinations. Hell, my 3D printer is more reliable than my 2D printer.
well, but it could be. Of course, more complicated to set up, but this connection could be VPN or anything and the printer is (similar to a 2D printer with IPP or similar) just a host with some ports which have to be reachable.
My A1 still has the old firmware where mqtt is exposed - this totally works for me to tinker with, and I don't understand their motivation to cut us off.
I also don't understand their stance to limit client software - I found a bunch of bugs in their package, filed one in their github project, and never heard anything of it, while they continue to ship features. So they don't care for their software (or linux users?). They should allow the community to fix their shortcomings.
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.
I think the enterprise “LAN Mode” is actually the thing this repo is emulating / replacing, which the consumer printers (might?) also support, where the cloud auth token is still in play but prints are (ostensibly, in a much more difficult to audit way given the client still needs access to the Bambu servers) sent directly to the printer.
Developer mode doesn’t require the proprietary binary.
There's no technical hurdle to achieving both modes or access types (local and cloud) simultaneously. This isn't a technical issue. Selling "Home" and "Pro" devices that are differentiated is also not necessarily a problem, a company is allowed to sell two products with different features and pricing.
There are two problems here. One is when the manufacturer sells something with some capabilities and later pulls the rug from under the users and decides to arbitrarily take some features away. This should entitle any customer to take an arbitrary amount of money back from the manufacturer. The second problem is that after a customer buys the product they aren't allowed to own it. If I buy a hammer I'm, allowed to cut it open, dissect everything, modify the handle or the head. That's ownership, not some shallow dismissal that user want to "have their cake and eat it too".
If someone sells you a cake then follows you down the street to take the frosting and one of the layers back, and tells you that any attempt to restore the cake is a crime, you'd start questioning whether it's really your cake to begin with, and what exactly are you eating.
> 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.
There is some context missing, which this video [0] explains.
tl;dr: The original developer does not (or cannot) go into legal battle with Bambu Lab, so Louis Rossmann's project picked up the fight and hosts the (allegedly) troublesome code on their organization. As they have more financial resources, they look forward to the C&D letter.
The point he has (and I agree with that): The original developer is using the un-modified AGPL-code to talk to the cloud API. Bambu Lab states that the modified client pretends to be a Bambu lab client. But in fact, the modified client just uses the code as-is, which is perfectly fine from a AGPL perspective. From my non-lawyer point of view: If Bambu Lab would have made the User Agent a configurable variable, which gets set by some configuration files from outside the code, that get bundled with the binary version, but not the source code, they wouldn't have this leverage.
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.
> No, we aren’t being blocked. Turn on LAN mode, pair regular Orca slicer, ignore Bambu for the rest of eternity. Plenty of people have done it.
You're just saying that Bambu users feel the need to purposely circumvent Bambu's artificial restrictions to be able to continue to use Bambu hardware they bought and paid for.
It's a toggle you set in the printer directly, nothing is circumvented. Only the access through their cloud service is impacted, but the printer works locally like any other.
Pretty sure you can still print locally either via LAN or just SD card. At least I can on my A1.
The current monetization that they are using is that you can charge for a print on their platform and they take a cut of the sale. If you don’t charge for the design, then it is still free hosting and delivery.
I see where the worry is, but at the moment it seems like people are imagining a worse case scenario.
If you turn on LAN mode, it acts exactly like every other printer. You can print directly to it from any slicer over your LAN, or dump gcode on the SD card directly.
People are saying the LAN mode lacks access to the webcam and possibly some other things. That is what this whole controversy is about. It's re-enabling some cloud features as local only and Bambu is calling it privacy or fraud.
They probably want to establish a commercial-use license. If you have a big print farm, you likely need all of those remote capabilities so you're going to need to pay for the license. The schmucks at home will likely continue to get it for free. Locking them into the cloud API by dangling convenient features just ensures most people won't stray into the local-only mode.
> 2. For printing from the app, they actually run the computationally expensive slicing algorithm on their servers, so this is totally reasonable to protect.
That's an artificial vendor tie-in, and arguably a feature that only involves their client app and their backend. It's understandable if access to their backend is restricted to a subset of their users if that's the business model they wish. Preventing paying customers from using the hardware they bought and paid for by imposing artificial restrictions is not cool.
They've bought a machine that executes gcode and that it does (at least to my understanding) regardless of where that gcode comes from.
If you want special secret sauce gcode from the bambu cloud, you need to use the bambu cloud.
Those are not the same thing, so IMO it is legit what they do there, because it's such a clear-cut split.
You own the physical thing but not the ecosystem around it.
___
I would of course personally never buy a bambu lab printer, because they're cloud-tied nonsense that was going to behave exactly like that (the split between hw and ecosystem), but other people knew that too and still bought it, because "what a nice ecosystem".
idk.
I just don't think that "right to repair" should mean "right to be saved from the consequences of my own bad actions".
Those bad actions continuing to have no real painful consequences (and with that no real learnings + behavioral correction) after all is why the state of tech has become as bleak as it is right now.
And, honestly, if you can afford a bambu premium machine, there's a 97% chance that you could easily shoulder a total write-off.
There's also a 97% chance that your ego can't, but that's the main thing causing all the bad things in the world and should've died a long time ago. Approximately post-highschool.
I wouldn't buy an alternative to a P1S, because only the P1S is the best at being the P1S. (Whatever that might entail)
Instead, I'd look at things from the perspective of "what do I want?" and not "What does the market offer? Okay, I want that thing. But no, I want an alternative to it that is that thing but without downside"
Letting a brand set your frame of reference is the first step into total dependence.
Thanks for your reply. Only used PLA so far. But later I'll need "engineering parts", Nylon/PA12 or something like this. Strong, water and UV resistant, outdoor.
It shouldn't be too complicated and not too expensive. E.g. while the Prusa Core One+ seemed nice (from a superficial look) it costs more than I wanted to spend. P1S came out as the best (barely) adequate printer for what I thought I would need when I looked at it. But it's difficult to say if you are a beginner and basically have no idea...
Yes but what does "equally good job of printing" mean, I wonder.
That's what I meant with "the P1S is the best at being the P1S when measured by the P1S".
I am pretty sure that if you for example do functional PLA parts, there will be many, many more options that tick exactly that box.
I do of course understand that people want to have the mental peace of buying one thing and being told that it can do everything, but, as said, you pay for that emotional labor with lock-in and eventually being rug-pulled.
The only way of not getting rug-pulled is not handing away all of your agency wholesale just for cheap immediate emotional relief.
That's how it works, how it has always worked and how it will always work.
Anyone claiming anything else is in the process of actively scamming you.
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.
> 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.)
Bambu absolutely could create a system where their printers both communicate with the cloud and local devices, they just don't want to do the difficult software engineering necessary because it is difficult. This is not theoretical either; I work on production devices with hybrid cloud and local functionality. Engineering around a zero-trust threat model (as in you assume the user can and will tamper with the device) is completely doable.
For instance, using a push-only RPC model where only the cloud can initiate a request is one zero-trust strategy that can be used for ensuring a predictable network load on cloud infrastructure, which seems to be their main concern.
This is fair and I should have been more clear that I meant “possible under their current self-imposed constraints;” of course it’s all software so anything is possible (for the record, I also agree that this is a much harder problem than people are giving it credit for).
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.
I don't think they baited and switched? I bought my P1S before the whole LAN mode debacle and even then it was all or nothing on the cloud. I just went with the cloud because they were using some IGMP stuff for the local connection, but I had the printer on a separate VLAN and pfsense IGMP proxying was broken.
A different way of looking at it is that Bambu is saying if you want to use their cloud you have to send everything through their cloud. Stupid? Sure. It's very much a technically solvable problem. But I don't think there was any rug pull (this time; in Jan 2025 they tried...)
I think this is all more out of incompetence than malice. Something bad happens, exposing wildly inadequate programming expertise, they panic and over correct, and the community pushes back. They're great at making 3D printers, terrible at cloud infra.
For me, I want to use orca for slicing there are many more additions to the local code. As both orca and Bambo are from the same open source, the current limitation in the Bambo version is breaking the licensing of the application, and my rights in that software are broken by this addition.
Then, during the print, I'm really happy to use the handy app to monitor the progress. This use case was supported when I got the hardware. Now I have to disable the app to get the slicer. I actually like to use both slicers to compare and see progress.
They are also terrible at software licensing, don't understand what open source is, and they found their main software on that. They probably should embrace the orca community and use their research for their own customers. Better slicing helps everyone.
Technically true, because bait-and-switch refers merely to advertising an attractive product offer in order to lure people into a pitch for a different product.
In this case, they actually sold a product, then decided to maliciously alter the product after it was sold to modify its behavior. That makes this a much more serious offense, equivalent to trespass, vandalism, or possibly even burglary.
It's equivalent to selling someone a house that includes a secret entrance that you retain access to, so you can surreptitiously enter the house to steal the new homeowners' property after they've moved in.
Just to confirm so I don't break anything accidentally, I currently have the app version where Bambu Studio is how I send prints to my Bambu P1S and I can look through its camera and see what filament is where and so on, but I also have the token that Home Assistant uses to watch the printer and its camera etc.
This isn't the thing you're talking about. There's a mode where I can send prints directly over the network which disables Bambu Studio, I assume?
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?
I don't think so. They can already track popularity very effectively because they control makerworld, and they could have Bambu studio, the app, and the printer phone home too. I don't think they care enough about the tiny tiny minority of users running orca with a LAN only printer.
More likely, it's technical incompetence. It's just easier (for their cloud) to send everything through their cloud
I think OP meant designs which are not on MakerWorld.
And I think technical incompetence is not a reason here otherwise they wouldn't gatekeep the access so much.
There are two reasons to be mad here and you only covered one. The first is that Bambu is trying to remove (for the 2nd time) features from existing printers.
The 2nd thing, and the reason the linked repo is now hosted by Louis Rossman (YouTuber / Consumer Rights guy) is that Bambu are abusing the AGPL license of the original slicer code. TL;DR is that Bambu Slicer is a fork of an AGPL lineage of similar tools. The gatekeeper of the cloud features hosted by Bambu was a user agent string embedded in the AGPL code. The original dev of the linked repo just copied and pasted AGPL code, and Bambu sent a cease and Desist. At least Louis Rossman believes that violates the AGPL terms against additional restrictions which is why he is hosting the repo, because the original dev was chilled from wanting to deal with the legal threats.
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.
> (...) I don't see the current system as particularly bad and find the appetite to restore "untrustworthy" cloud functionality a bit amusing.
This is a very dubious opinion to hold. Taking your claim about local mode at face value, there is absolutely no reason to disable monitoring when working on LAN mode. You need to go way out of your way to implement that restriction so that it works differently when the thing phones home or not. You are free to criticize implementation decisions that you feel make it "untrustworthy" but those are trivial to address if you think about it.
I really recommend you to reassess your whole philosophical stance on having corporations prevent you from using what you bought and paid for.
> OrcaSlicer-bambulab: if the goal of this fork-of-a-fork is to bypass Bambu's cloud servers, why would it still need to "impersonate" the UA and communicate with Bambu's servers (as Bambu claimed)? Wouldn't the whole point be to avoid doing that in the first place?
I finally got to the bottom of this; there is a cloud-based RPC method called `bambu_network_start_local_print` where Bambu's Cloud would authorize a print using (ostensibly) only locally transferred data. The goal of this project was basically to pretend to be the Bambu plugin in order to authorize this method, which is otherwise locked behind Bambu's auth system.
The alternative is to run the printer in LAN mode (which OrcaSlicer has always supported) where the client connects natively over MQTT, but after Bambu added their cloud authentication, this requires putting the printer in Developer mode and severing the Cloud features.
My understanding is that right now, you can run your printer in LAN or USB mode without Bambu's cloud, and this is supported natively by OrcaSlicer (or any slicer using USB), but you lose some of the Cloud monitoring features.
You can also use Bambu's cloud with their Cloud Connect app and gain those monitoring features while using a third-party slicer, but at the expense that you send your prints through their cloud.
Or, you can use Bambu Studio and get the "fully integrated" experience.
My understanding is that this plugin just replicated their Bambu Studio communication with the Cloud, and that it _enabled_ you to send your prints to their cloud, not _disabled_ it. Is there something I'm missing that made this valuable? (ie - did it do some hybrid where it could hack in the Cloud monitoring without sending the prints through the Cloud?) Otherwise, I think what Bambu are doing are distasteful but I don't understand all of the Chinese espionage hand-wringing or "stealing our files" commentary around this.
EDIT: I finally got to the bottom of this; there is a cloud-based RPC method called `bambu_network_start_local_print` where Bambu's Cloud would authorize a print using (ostensibly) only locally transferred data. The goal of this project was basically to pretend to be the Bambu plugin in order to authorize this method, which is otherwise locked behind Bambu's auth system. This makes more sense. I wish the commentary on this subject would actually explain this.
I'm actually really confused about the language used in the recall; I looked at the Cybertruck manual and the brakes look like a "conventional" design where the studs are set into the hub and go through the rotor, so this failure seems somewhat unrelated to the brake rotors, and the "brake rotor stud" is also the wheel stud: https://service.tesla.com/docs/Cybertruck/ServiceManual/en-u...
I'm assuming it's a misphrasing or typo and the issue is that the stud holes in the wheel hub rotor can elongate, leading to the studs coming out. This can and likely would absolutely cascade into a wheel falling off; I've seen it many times in cheapo endurance racing series - once one stud is loose, the adjacent studs gradually loosen and eventually the wheel separates. If the issue is longitudinal (slotting) it's even more likely to lead to a rapid separation event.
Modern gas crate powertrain swaps which include engine management usually have the same restrictions; GM Connect and Cruise, Hellcrate, Ford Performance, etc. What you’re describing with LS swaps is unique to kits that come with no engine management; it would be as though this kit were sold with no inverter and motor controller. Of course, reverse engineered aftermarket tuning is more readily available for gas ECUs, but that’s just a matter of market forces, not the OEMs.
> Haskell gives you tools to encode these incantations in types so they cannot be forgotten. This is, for my money, the single most valuable thing the language offers a production engineering organization.
Haskell is admittedly, probably the most powerful widely (or even somewhat widely) used language for doing this, but this general pattern works really well in Rust and TypeScript too and is one of my very favorite tools for writing better code.
I also really like doing things like User -> LoggedInUser -> AccessControlledLoggedInUser to prevent the kind of really obvious AuthZ bugs people make in web applications time and time again.
I've found this pattern to be massively underutilized in industry.
This isn't specific to Rust or Typescript. You can do this in basically any language.
Imagine you have to distinguish between unescaped and escaped strings for security purposes. Even with a dynamically typed language, you can keep escaped strings as an Escaped class, with escape(str)->Escaped and dangerouslyAssumeEscaped(str)->Escaped functions (or static methods). There's a performance cost to this, so that's a tradeoff you have to weigh, but it is possible.
Another way of doing this is Application Hungarian[1], though that relies on the programmer more than it does on the compiler.
> This isn't specific to Rust or Typescript. You can do this in basically any language.
This just isn't true.
In any dynamic language you would not get these guarantees at compile time. You'd get random failures at runtime. That's not safety of any kind.
Also, part of the goal of languages like Haskell is that they help you think about your code before it runs. All of that is lost.
> Imagine you have to distinguish between unescaped and escaped strings for security purposes
That would be a nightmare in many languages. You'd have to rewrite large parts of the code to be compatible with one or both. And in many languages you'd have to duplicate your code entirely.
In other languages, the result would so ugly, you would never want to touch that code. Imagine doing this with say, templates in C++.
>There's a performance cost to this
There is no performance cost in Haskell! This is entirely undone by the compiler.
Also, because the compiler understands what's going on at a much higher level, you can do things like deriving code. You can say that your classified strings behave like your regular strings in most contexts, like say, they're the same for the purpose of printing but not for the purpose of equality, in one line.
That part is (de facto) required for dynamically typed languages, but not for statically typed ones where the newtype constructor/deconstructor can be elided at compile time. Rust and C++ especially both do the latter by having true value types available for wrappers that evaporate into zero extra machine code.
But then just this moment I wondered: do any major runtimes using models with no static type info manage to do full newtype elision in the JIT and only box on the deopt path? What about for models with some static type info but no value types, like Java? (Java's model would imply trickiness around mutability, but it might be possible to detect the easy cases still.) I don't remember any, but it could've shown up when I wasn't looking.
> [Performance cost] is (de facto) required for dynamically typed languages, but not for statically typed ones where the newtype constructor/deconstructor can be elided at compile time.
For a single value, it should reliably be free in any reasonable statically typed language that meet your other criteria.
For a collection, it may still be de facto required. Unwrapping a set of addresses into a set of strings takes unnecessary cycles, an unsafe coercion, sufficiently sophisticated affordances around coercion that it can be safe, or a smart enough optimiser. At least some static languages have at least one of these; I'm not sure all do, and certainly not all have always had.
Well, java can do escape analysis, so a wrapper with a single field may end up as a local variable of the embedded field.
As for other JVM languages like Kotlin and Scala, they have basically what "newtype" is, but it can only be completely erased in the byte code when they have a single field.
Escape analysis that sinks a local allocation is great in itself, but for newtypes for things like “trusted HTML vs plain text”, I feel like the primary benefits are deeply interprocedural. The type constraint is encoding a promise that can be carried from one end of the code base to the other, and where you can know for sure when you're writing a module whether you're on one side of a barrier or the other. I would tend to expect this to result in patterns that aren't well-handled by escape analysis.
What I'm imagining for my curiosity about the dynamic case would look more like “JS/Lua/whatever engine detects that in frob(x) calls, x is always shaped like { foo: ‹string› } and its object identity is unused, so it replaces the calling convention for frob internally, then propagates that to any further callers”, and it might do the same thing when storing one of those in fields of other objects of known shapes, etc. until eventually it hits a boundary where the constraint isn't known to hold and has to be ready to materialize the wrapper object there.
Kotlin and Scala sound like they're doing the Rust/C++ thing at the bytecode level, if it's being “erased”, so just the static case again but with different concrete levels for machine vs language.
What you cannot do is compile-time safety guarantees, and in languages like Rust type system isn't strong enough to do some advanced compile-time guarantees (via types). So no, you cannot do this in basically any language (unless you turn it into Haskell).
Rust (and Scala) type systems are somewhat stronger and more expressive in some areas than Haskell. Weaker in some other. But it’s not a clear cut that Haskell type system offers more safety guarantees.
> But it’s not a clear cut that Haskell type system offers more safety guarantees.
You can log operands in your implementation of Rust's Add trait, or compute running sum of one of the operands. In Haskell it is not possible unless you use unsafePerformIO from System.IO.Unsafe.
Haskell's type system controls effects available to the code. This can be used to implement programs adhering to specific formulas of Linear Temporal Logic or implementing a protocol specification, where operations on any given phase and side are restricted by type system.
I used Haskell's type system to prevent crossing of clock domains in the hardware description eDSL. Also, it was of great help in the CPU simulator description, fixing available commands and resources for different CPU models.
Even the logic of Rust's borrow checker was expressible in Haskell as early as February 2009 - there was HList, there was ParameterizedMonad and that's about what one needs for implementation of borrow checker.
Caveat emptor, I'm not a Haskeller, just an admirer. But Haskell let's you run functions over the type system itself very elegantly, so you can have a type that is derived from a type that composes three types that are derived from several functions' declared runtime behavior. This kind of type inference can provide arbitrarily rich information about anything in the entire program, letting you encode more than just range-types etc at compile time.
This comes with some design drawbacks. I think Rust's borrow checker would be implementable but unreasonable in Haskell: Haskell already does lazy-evaluation on types to enable its arbitrary depth of type expressivity. But the borrow checker also wouldn't really make sense for Haskell because the default programming model uses a GC. I think Linear Haskell might be a kind of Rust-in-Haskell, though.
I've spent long time writing Haskell and now write Rust professionally, so let me tell you something. The stuff where you really want to "program in types" lives beyond Haskell, in languages like Agda, Idris, some HoTT stuff etc. anyways.
In principle the more developed the type system is – the closer it to not distinct between types and values. Caviat is that its "type inference" gets worse.
So, in those more developed languages, you could have type-level proofs (guarantees) that your calculator produces correct results, as a proof, as theorems. That 2+3 will be 5, not as runtime test assertion, but as a theorem, that no other result is possible no matter what happens. Or that your parser will never fail on valid JSON etc. but nobody guarantees it's going to be a pleasant thing to write, maintain, and debug. And compile times will probably be terrible.
> The rank-2 type (that is, the type s is scoped within the parenthesis and can't escape) of runST ensures that the mutable references created inside the computation cannot escape due to being tagged with the type s. Internally, all sorts of imperative nonsense may occur. Externally, the function is pure. The world outside the boundary gets none of the mutation, only the result.
C does not have parametric polymorphism, nor rank-2 quantifications, so no, this cannot be done in C.
This was not the original claim in the thread I responded to which as "even with a dynamically typed language, you can keep escaped strings as an Escaped class, with escape(str)->Escaped and dangerouslyAssumeEscaped(str)->Escaped functions (or static methods)." so this was about abstract data types and not polymorphism.
Regardless, you can also have some limited parametric polymorphism in C with macros. This is very poor, but parametric polymorphism in Rust is based on monomorphization so it is also quite poor. You can also have higher-order polymorphism in C but then you need to use subtype polymorphism.
And categorically: the issue isn’t what “I’d” do, my habits often match my habits, it’s what other project members will be doing (including future degenerate versions of myself assumed to be some combination of busy, tired, stressed and drunk).
The Confucian philosophy that people act like water coming down a mountain, seeking the path of least resistance comes to play.
Haskell, OCaml, F#, and their ilk can yield beautiful natural domain languages where using the types wrong is cost prohibitive. In languages without those guarantees every developer needs discipline to avoid shortcuts, and review needs increase, and time-pressure discussions rehashed.
You demonstrate well the problem: yes anything that is computable can be than in any computation system. That's not what discussions about tooling are about.
If a tool can help enforce some ways of doing things, or if it doesn't constrain people much, that has consequences for the type of work that gets done with them and the systems you encounter running out there that you might be invited or find the need to work with.
"I can do it" is exactly the wrong answer. "How can I guarantee that others will do it" is the point being made.
Some people, teams and orgs can benefit from it. "I don't need it" is missing the point. "Not everybody needs it" is missing the same point from a different direction.
Tell me you haven't understood what a type system does without...
A type system mathematically proves, at compile time, what a program can and cannot do. No, you can't "do this in basically any language".
It's ironic that "shift left" is generally considered a good thing', but when you point out that you can shift a significant majority of checks left all the way to compile time, they say "no, not like that!"
And of course Rust and TypeScript were heavily influenced by Haskell... they just don't mention it and call things differently, to avoid the "monads are scary, I need to write a tutorial" effect. Though it's less about monads and more about things like type classes.
Rust's influence was OCaml, not Haskell. Its first compiler was written in OCaml. Its syntax directly looks like OCaml and C++ had a baby. It's got ML smells all over it. Haskell is not the sum of Hindley Milner-esque languages.
Personally, never enjoyed Haskell's syntax (or lack of it) and tendency to overthinking. But I did enjoy SML/NJ and OCaml to some extent.
Haskell type classes are not classes (like Java or PHP classes); they are comparable to Rust traits -- which are different from PHP traits which are comparable to Java/C# interfaces (with default impls; if you just want contracts you have... PHP interfaces).
A fundamental difference is that you can instantiate/implement a type class (or Rust trait) for any* type, compared to interfaces where each class declares the interfaces it implements. You can therefore create generic (forall) instances, higher kinded type classes, etc.
> Actually in modern Java you can simulate type classes approach with a mix of interfaces and default methods implementations.
Can you? The beauty of traits/type classes is that you can attach them to any type - in a world where 90% of the functionality of any piece of software is supplied by dependencies - external types which you cannot change - this is a vital feature.
Failing that, there are always Clojure, Kotlin and Scala on the JVM, which expose language features to achieve the same, which you naturally can mix and match with plain old Java.
Why the reference to “modern Java” then? Writing adaptor classes is not “modern Java” nor does it involve using “a mix of interfaces and default methods implementations”.
I was responding to your original claim and I’m well aware of such facilities in both Kotlin and Scala - having used both extensively. I was genuinely curious if the latest Java was in the process of adding support for trait/typeclasses - so I don’t understand why you’d bother to reply with something that completely changes your original claim.
This is more of a question of Affordances than type systems as per se e.g. you can do this quite happily in C# or something it's just that the amount of visual clutter is more than the actual type definition.
I think that's getting better in C# with record types (and primary constructors in general). Real Discriminated Unions should help a lot, and that's finally in Language Preview now.
I'm not convinced it really works well in typescript. the lack of nominal types requires you to remember some pretty hacky incantations if you want something like a newtype wrapping a primitive type
my experience is that ocaml is more powerful than rust for enforcing this sort of type safety, because you have gadts that give you more expressive power, and polymorphic variants and object types (record row types) that give you more convenience. and the module system and functors of course.
you also avoid some abstraction limitations/difficulties that come from the rust borrow checker for places where garbage collection is just fine
It really feels like we’re solving the wrong problem sometimes. If a bad type can crash your application, sure, type safety is one answer but I have to admit I like the erlang approach; if something unexpected happens crash the process (not os process, erlang process) which has a very small blast radius on a well architected system (maybe doesn’t even fail the individual request that caused it). I wish more languages had this let it crash philosophy, it really allows for writing code exclusively for the happy path, safe in the knowledge that a -1 where a “string” should be isn’t going to take down production.
Somehow, it feels like a better solution than these complicated type systems. Does any other language do this outside BEAM?
When working on large, important software, crashing is not the worst thing that can happen; corrupting user data and/or allowing unauthorized access is.
The point of using the type system to do something like distinguish between sanitized and unsanitized strings is specifically to prevent these kinds of security breaches.
Erlang was designed for traditional telecom, where reliability of connections was the biggest factor, not security. I fail to see how Erlang’s approach can deal with the issue of security breaches or corrupted user data.
In a way I agree with you, and I'm not sure that what popular languages embrace or make it easy to follow this philosophy. My sense is that Erlang is still the leader.
But I did want to add something the article also touches on: types can be not only about ensuring safety or correctness at runtime, but also about representing knowledge by encoding the theory of how the code is supposed to work as far as is practical, in a way that is durable as contributors come and go from a codebase.
Admittedly this can come at the cost of making it slower to experiment on or evolve the code, so you have to think about how strongly you want to enforce something to avoid the rigidity being more painful than valuable. But it's generally a win for helping someone new to a codebase understand it before they change it.
Edit: another thought I had is that type mistakes do not always causes crashes. Silent corruption can be much more insidious, e.g. from confusing types which mean something different but are the same at the primitive level (e.g. a string, number or uuid)
For me this has been a life saver being the only back end developer at the company. I don’t have the energy nor time to think about every possible scenario, especially not the mobile client sending random strings to something that should be parsed as an uuid (has happened more than once).
By letting it crash I can have a look at the traces at my own leisure and a lot of them I never fix, because I don’t have to.
The amount of silencing (implementer error, but quite prevalent) of errors I’ve seen in typescript codebases are horrifying. Essentially ”try happy path, catch everything else and return generic error”, the result is is mostly the same for the user, but night and day for me who is trying to fix it.
Or have a static type system and something like BEAM. I'm not sure why this is a one or other approach, both are useful and unfortunately it doesn't seem like any languages include both. Gleam exists but doesn't really integrate with BEAM, it seems to have its own way of doing things that are more akin to Haskell, given its origins.
That's literally the entire point of BEAM lol, that's one of the main reasons it was made, to patch code that breaks after letting it fail. BEAM was designed for as little downtime as possible and if you don't need that then just use another more ergonomic language than Erlang or Elixir.
>if something unexpected happens crash the process
There are some expectations where that's a reasonable response to a violation, but there are many expectations where the violation implies a bug elsewhere and crashing the process will do nothing to address that that wouldn’t have been better accomplished with stronger compile time checking.
EDIT: previously the example in the parent comment was:
type NewType<T> = T & { __brand__ : Symbol }
---
This seems wrong; the type spelled `Symbol` refers to the boxed interface for symbols[0]. I suspect you meant to write `unique symbol` there, but it can't be used in that position.
I'm not sure if `NewType` in your comment is supposed to stand in for a specific newtype (in which case it probably doesn't need to be generic[1]) or if it's supposed to be a general-purpose type constructor for any newtype (in which case it should take a second type parameter to let me distinguish e.g. `EmailAddress` from `Password`[2]). The use of `unique symbol`s is also only really necessary if you want to keep the brand private to force users to go through a validation function or whatnot, otherwise you can just use string literal types.
I agree these incantations aren't big problems (it all falls out naturally from knowledge of TypeScript's type system, and can be abstracted away as per my comment in [2]), but the fact that you goofed in the very comment where you were trying to make that point is causing me to second-guess myself.
Right. Besides getting this incantation right, as gp did only after editing their comment, you also have to cast to create values of NewType. But generally you want to avoid casting in typescript if you care about type safety, so now everybody has to remember the rule that in this particular circumstance it's the right thing to do.
There are helper libraries to ease this (zod supports branded types, I think?), but I guess my general point is that while typescript might give you the ingredients you need to implement type safety in cases like this if you try really hard and remember all your rules everywhere, it doesn't come naturally so it's hard to maintain at scale.
I was on the Tube and wanted to get my reply in before entering a tunnel. I already corrected it whilst I was underground.
I think the point still stands - is this really a big problem? I guess I couldn't recite the syntax from memory, because I usually use a utility type for this
Agreed. Clojure gets this with Mali and Spec. That said, types are such a productivity boost over time that I think they should only be discarded for very good reasons.
I think you csn also goa long way with C++ and templates to represent sny kind of restricted type in the type system. Variants are somewhat clumsy without pattern matching but most tools you can make use of are already there I would say.
In my backend system I represent users with different variant states to avoid a lot of unrepresentable states.
As for underutilization, I think only functional languages, Rust and C++ support variants and that might be one reason: people just make blobs of state and choose which fields to use instead of encoding states and make some combinations unrepresentable. Javascript, Java, C# or Python do not have Variant types to the best of my knowledge.In Ocaml and Haskell and with pattern matching they are very natural. In Rust with enums, same. In C++, they are so so but still usable compared to the others that do not have.
In my load tests I even went, since I launch thousands of clients, with a boos.MSM to drive the test behavior. One state machine per user.
You can't in Haskell either! For example, any function could secretly call `unsafePerformIO` to cause a side effect (and that's not the only example).
I believe `const` functions in Rust are actually be guaranteed to be pure, though I haven't followed that feature closely and there may be nuances.
In most languages purity is a norm rather than enforced by static analysis. I definitely agree that it's much safer to assume that an arbitrary Haskell function is pure than it is to assume that of an arbitrary TypeScript function.
You can compile Haskell code with the -XSafe flag, and this is communicated in the package, so something like backpack can be told to load only safe modules. Still, there's probably plenty of code that's safe but not pure, but that's as good as we're likely to get.
It had hot code editing and a hot code editing debugger. To me, these were the main features that were interesting about VB6 vs. Delphi. Delphi won in basically every other axis (databinding, real OO, visual inheritance, etc.).
Also, while it certainly had some sharp edges, the ActiveX / COM component system (ActiveX Controls) was pretty good; you could make reusable UI blocks as a first-class citizen in the IDE. You'd just pick an ActiveX Control as your product and the thing it produced was an OCX you could just drag onto another project, where it would spring forth as a full first-class item on your form (unless the initialization failed, which in fairness it frequently did). There was a good commercial ecosystem for buying stuff, too; charts, graphs, insanely complicated data tables, it was all there for some moderate price. This culture carried over to .NET to a good extent, but it never really reached the peak it did with Visual Studio 6.
What's funny is that we have all of these capabilities today, still, we haven't "forgotten" about "how to VB6," we've just decided we can't use them because:
* Screen sizes and DPI ratios are highly variable and so there is a high demand for dynamic layout, which is difficult to express in a visual editor.
* Source control is more popular than it was.
* More front-end code is built collaboratively, so not only do artifacts need to be controllable, they need to be diffable. Nobody has really managed a diffing solution that humans like that's not lines-of-code (and trust me, they've tried, I have years worth of Thoughts about this!), so this really means "the UI designer needs to decompose to human readable line oriented statements" - which is where we went from VB6 (and Interface Builder NIBs, and so on and so forth) to newer generation UI technologies or a preference towards layout-in-code like SwiftUI.
* Cross-platform compatibility is more important than it was, and every cross-platform non-web UI framework got extinguished in the early 2000s by a combination of security becoming a real concern and Steve Jobs, to be replaced by web-based frameworks today.
Windows Form Designer in Visual Studio still works in that same way? This was one of the least differentiated things, really; while XCode’s interface building tools have always been clunkier they also offer the same functionality too.
SkySafe (https://skysafe.io) | Wireless Engineer (SDR) | San Diego, CA | REMOTE or HYBRID
At SkySafe we build drone detection and tracking at scale.
I am looking for a Wireless Communications Engineer with SDR expertise to join my team; I'm the hiring manager.
What I'm looking for:
* Background in wireless communications / signal processing theory and math.
* Experience building software-based wireless modems.
* Experience writing and optimizing software-defined radio code in C++ directly.
What you'd do:
* Implement all components of software defined modem systems from specifications and alongside our reverse engineering team (no RE experience necessary!)
* Optimize existing software defined modem systems from both a theory and practice perspective - that is, make both conceptual improvements to algorithmic approaches as well as practical improvements to implemented code.
* Architect and implement high-level improvements to SDR systems (scheduling, compute offload, etc.).
We have a strong system in place for remote SDR work and are open to remote candidates for this role. If you're in San Diego and want access to an office with nice equipment, that's even better. This position requires access to technology which is controlled by US Export laws, so you also need to be an eligible US Person.
What we have to offer: $145-200k. Fun, small team dynamic. Work with experts in adjacent fields. Startup environment with good work-life balance and limited red tape. Rapid iteration and feedback in the wild - make a change, deploy it, and see telemetry come back in the same day. Good equipment at the office.
Apply: brian@ for a direct line, https://jobs.lever.co/skysafe for the formal route (we have some other roles I'm not the HM for listed there, too, if you're interested in the company!)
> limit or disable certain functionality in the vehicle: ... over-the-air updates, which provide new ... safety enhancements ...
I wonder what happens if you disable the e-SIM (in the US) and then a safety recall appears via software update - do dealers have any way to update control modules besides OTA?
This is a huge unresolved issue with EVs IMO; ICE cars are required to provide emissions-relevant updates over software which can operate using a J2534 passthrough device, which effectively means powertrain modules have to allow (potentially signed) updates over CAN using software that can be obtained by an end user (a lot of people don't know this; for almost any ICE car in the US, you can buy a 3-day or 1-week subscription to the dealership level diagnostic software for a somewhat reasonable fee and use it with a J2534 device).
But for EVs, there's no such rule and as far as I can tell it's entirely a gray area in the US now; the NHTSA require a "remedy" for recalls but nobody seems to have pushed back to determine whether OTA is truly a remedy. The traditional autos all offer dealerships as a backup option, but Tesla and Rivian have several recalls with only OTA remedies already. This seems sketchy.
> I wonder what happens if you disable the e-SIM (in the US) and then a safety recall appears via software update - do dealers have any way to update control modules besides OTA?
I would assume so. Even on older cars, service techs can typically manually push firmware updates over the OBD-II / J2534 port. Rivian's OBD-II port actually hides an Ethernet signal inside of it - so the interface is certainly there.
> Rivian's OBD-II port actually hides an Ethernet signal inside of it - so the interface is certainly there.
Nice. This is really normal now, for what it's worth - all of the European makes have moved this direction as well (DoIP over ENET). There's shockingly little documentation about Rivian online, though, probably because emissions regulation doesn't mandate it.
I don't see anything suspicious, but I browse with scripts and ads blocked, so it's possible that you encountered something that never reached me. Thanks for the warning. Unfortunately, it's too late to edit my comment.
Yep! Depending on the vintage, BMWs have "real" DoIP or a BMW-ized version (sort of like how KWP2000 was the predecessor to UDS). For emissions modules, they still also have to support updates over UDS as well as ENET, though, for the above mentioned J2534 reasons (Ethernet wasn't added to J2534 until 2022).
Actually almost any fuel injected vehicle can accept flash updates through the port to at least the ECU and PCM, frequently the BCU is also write enabled.
If there is a BCM. My previous 1995 GMC C1500 had a PCM and the automatic transmission was controlled by mechanical linkage to a hydraulic computer in the transmission along with shift solenoids from the PCM. It also had "throttle-body injection" with two injectors replacing the carburetor. The OBD 1 system would switch to "open loop control" with preprogrammed injection in the event of a malfunction which would make the thing challenging to drive until you fixed the problem. So very simple compared to the multitude of computers and control systems in use today.
A nice feature on that system was that you could put a paperclip between two pins on the diagnostic port and it would blink out the trouble codes on the SES light.
You can adjust the ECU for these 80s and 90s cars and “flash” them like anything else. There’s just a lot less settings! Not sure about the 70s but I’m sure some resto-mods also allow for this.
Even more tangential: Kia declined to cover an engine failure, under warranty that was extended by recall because I change my own oil.
Kia's engines are known to fail predictably even within first 100K miles. They extended their warranty because of it. But then they weasel out of it unless you hire an attorney and go to war.
This doesn't require research. Just reject by default and concede if a lawyer shows up. It doesn't cost any money to have a default denial policy and saves millions.
Yeah, because you allegedly consented to them being able to update your ECUs via the mobile link in the cars when you bought the car.
As if I needed another reason to keep my 2014 skoda.
If i ever have to get a new car, i will disable telemetry, and i will buy it either without telemetry, or with the agreement that i do not consent to telemetry.
(read the fine print before getting a new car. the shit they can do that can go wrong and you have to pay for.. no wonder old cars cost as much as new ones.)
I assure you that “old cars costing as much as new ones” isn’t the result of the market force of people reading contractual fine print and/or freaking out about telemetry. Concentric circles of echo chambers over here.
The main reason is more tangible to people. It is more reliability and simplicity. For instance the Toyota Tundra used to have a V8 that was pretty bomb proof. But over the years, manufacturers put in more efficient but more prone to problems turbocharged smaller engines. The bearing clearances went down, thinner oil then can be used which is also more efficient. But the margin for error when you are putting what used to be a performance engine in a car is much smaller and there have been issues. As car prices have gone up, people value a time tested drivetrain. There have been a lot of problematic CVT transmissions too.
The Chinese government banned Tesla vehicles from entering (Chinese) military bases. This is due to the prolific number of cameras streaming live video to a hostile (to China) organization/government. One can find blogposts by analysts who show that the upload stream from Tesla vehicles includes cabin audio.
I’m not worried even a lick about what cars cost electronics or otherwise. My primary factor in selecting a vehicle is my physical safety; after that it’s electronic surveillance.
> I have never met anyone in real life that's concerned about telemetry on their car
You mean you've never had a conversation about it. You can't know if you've met somebody that has that concern unless you've broached the subject explicitly.
1. get a _real_, unabridged service manual. that takes some darkweb experience nowadays.
2. identify anything that looks like capable of housing a cell modem. that takes some understanding of contemporary car electronics
3. deny RF interface to units identified. that takes some understanding what RF = radio frequency interface is and also getting rid of fear of disassembling significant portions of your car.
That is the least of your troubles. SOS is the telemetry you wanted to get rid of in the first place.
And chances are you would have to get rid of 2/3 or more of oem electronics.
It'll end up a prototype vehicle or something, with custom ECU and stuff. On the bright side it will belong to you and not to the some mckinsey guys running those insurances and whatnot. It has been done too, although I personally prefer to just use vehicles that do not require this level of effort.
The other day there was a thread on unclouded tractors what I missed and I must tell I love my Universal 445 made in Romania in 1989. For all its quirks, it just gets the job done, no connectivity, no nothing, it's an unbreakable 3-cylinder diesel that just works.
It works depending on the manufacturer. Honda places the TPU in the dash behind the head unit. Use some spudgers and you can disconnect and remove the TPU. Takes 15 minutes at most.
Nice, thanks for the reply; this is surprisingly undocumented online. Presumably if they got cornered and the module under repair was updatable via this mechanism they'd have some ability to use that system, then. I wonder how charitable they will be about using it for non-recall updates for customers who have solely chosen to opt out.
Rivian are probably the only major manufacturer I've never had a chance to look at in any RE capacity and I'm getting more curious by the second. The reaction their vehicles had to the infamous bricked-infotainment update actually represented a pretty good adherence to safety guidelines (the drivetrain as well as the speedometer and warning lights on the cluster still worked in a degraded format even when the infotainment was bricked) IMO, so they do seem to apply a reasonable degree of care.
I wonder what happens if you disable the e-SIM (in the US) and then a safety recall appears via software update - do dealers have any way to update control modules besides OTA?
Yes.
You get a letter in the mail asking you to take your car to the dealer so they can install the update.
Interesting, I reviewed every Rivian software update recall letter I could find before I posted this and they all said something like "If you have not already updated to software version 2025.18.30 or later, please do so to remedy this issue at no cost to you," with no mention of the dealership as a remedy - for example, https://static.nhtsa.gov/odi/rcl/2025/RCLRPT-25V585-0759.pdf . This is different from other manufacturers who explicitly mention the dealer, like this Ford EV recall: https://static.nhtsa.gov/odi/rcl/2025/RCAK-25V863-3736.pdf
Of course they don't mention it. They don't want you to bring it in and have to pay a tech to do the update for you. It doesn't mean the dealership can't do it.
I'm sure they are, but I live in rural MN and Teslas are fairly common here, including the (barf!) Cybertruck. I'm seeing an increasing number of Rivian SUV's now.
In the US, a vehicle with an outstanding recall technically isn't roadworthy, though consumer level enforcement of this is non-existent in practice. It's mostly enforced on dealers, who can't sell a vehicle with active recalls. The only way I can imagine it mattering to a consumer is if they sold it.
Doesn't being legally non roadworthy only apply to NHTSA safety recalls while there are other types of recalls for non compliance or manufacturer voluntary recalls?
Having worked (on the vehicle registration system) for a state agency that is a combination "department of motor vehicles" plus "highway department", there could be a case made that since your vehicle does not meet NTSB/DOT standards, that it isn't roadworthy and the best you could get would be a SALVAGE title. Which would require expensive inspections if you try to sell it or register it.
In Europe, car manufacturers have to show that their cars meet safety standards. In the US, car manufacturers only have to say/certify that their cars meet safety standards. This is the huge sticking point for Trump's attempt to force EU countries to accept cars that have not been proved to meet safety standards (it is portrayed as "unfair/uneven trade barriers" in the US media).
Not disagreeing with you in general, but as another datapoint, in MN a vehicle only needs a theft inspection (no charge) to clear a Salvage title. DMV explicitly states that it's not a safety inspection. They really only care that you didn't repair it with stolen parts. IME you show them receipts for parts you bought, and the inspection is over in less than 5 minutes.
...do dealers have any way to update control modules besides OTA?
Of course they do. It would be absolutely silly not to. And in the case of safety recalls, their duty to inform you would entail a more traditional and substantiated disclosure i.e. a letter.
"a lot of people don't know this; for almost any ICE car in the US, you can buy a 3-day or 1-week subscription to the dealership level diagnostic software for a somewhat reasonable fee and use it with a J2534 device"
Whoa, didn't know that. Well the caveat is finding a decent J2534 device, right? There are a lot of cheapo knockoffs. Then actually knowing how to use the software with it.
No, but I'm not a good person to ask. My two cars are on opposite extremes, one is simple and doesn't need anything beyond OBD2, and the other is too scary to mess with digitally.
My experience is J2534 support is sketchy and if you want to do the things you actually want to do you need a manufacturer approved device with an insane markup. Also the subscriptions are insanely expensive, not even close to reasonable and you need to be a company (at least you used to be with Ford last time I checked, but they accept the UK or Dutch royal residence as a valid company location so there is that...)
I agree that J2534 is sketchy. The standard isn't very good to start with, there's usually no matrix (ie x systems * y devices) conformance testing but instead just a brief QA step done at some compliance stage in a release process, and most manufacturers don't really want to support it (preferring their in-house dongles). So, a lot of dealer tools do non-standard stuff and a "conforming" J2534 cable doesn't actually work.
Many subscriptions are painful, yes - VW brands / ODIS for example are awful to try to get as an individual and annoying as an independent shop; I'm sure the fraction of independent shops who pirate it are quite high. It's funny you mention Ford though, as they are incredibly easy to buy from in my experience, although the login/licensing backend is frequently broken.
However, there's a good cottage industry of companies reverse engineering the compatibility issues back out, and for better or worse these companies are cloned almost immediately too. I recently did key programming on a newer Ford (where Forscan can't) using a $125 VXDiag cable which I could have bought cloned for $30 and a short-term FDRS subscription that cost $50.
What about using ForSCAN? It allows anyone with the software and a dongle to monitor and to update modules in the ECU AFAIK. I paid under $100 (can't remember) for a dongle and downloaded the free software and it is extremely handy working on one of my vehicles. The other two Fords I own are both pre-OBDII so there is less bullshit on them to begin with. Ford forums are full of owners who use ForSCAN to modify their vehicle's operation. Lots of hacks available.
Just do as /u/bigfatkitten suggests and get the service manuals when you purchase the vehicle.
ForSCAN is awesome but it's an orthogonal conversation since it's a reverse engineered diagnostic tool rather than a first-party one. If we expand the conversation to that space there are tons of options with varying capabilities depending on manufacturer, including also pirating the OEM tools directly. Also worth noting that ForSCAN also doesn't _quite_ support all common operations, for example Remote Keyless Entry enrollment on newer BCMs with push-to-start needs FDRS still.
Thanks for this explanation. I knew that ForSCAN was a RE tool (Russian guy?) and that there were others out there for multiple purposes on various product lines. I also knew that ForSCAN did not support customizing all OEM functions. I just wasn't bright enough to make the connection between this being a first party versus anybody's tool type of mods that one might make. I do most of my own auto maintenance so I use the tools that best facilitate the process and since I am only mechanically experienced and not an accredited tech I lean towards using third party tools, custom tools I cobble together, OEM manuals, etc. to guide all the work I do here in my driveway or shop.
What ever happened to take it to a dealer or authorized repair place to have it done? While I may be willing to take certain things apart that, the one thing in life I have resisted is any kind of monkeying with my car. There are certain things where I'm willing to accept that I took it apart and it no longer works because I bricked it, shorted something, or otherwise damaged it beyond my skill set to undo. My car is not one of them. However, I also do not want my car to be under the direct control of someone else that can decide I can no longer operate my car. If there's an update, I'll bring it in to have someone trained/responsible for that update.
My car needed another key. The stealership quoted me >$400 for it. I took it as a personal insult and did the research and ordered an OBD device and also discovered you can order replacement keys on aliexpress, and they'll even cut them for you with a good picture of your existing key. It was actually a fun project and very satisfying when I was able to successfully program and link the RFID chip to the ECU to start the engine.
May not be feasible with more locked-down modern cars which I wouldn't touch with a ten-foot pole, but I was able to fix it for about $150, not including my time of course. But I have the OBD device to use next time now as well.
I bought a kit off of amazon "simple key" that included a programmer and a key with rfid chip. I think about $80.
You plugged the standalone dongle in the OBD2 port, did a procedure and it would take a few minutes and you would get an "original" key.
(The programmer said it was then locked to that VIN)
They key blank provided needed to get cut (did it at home depot).
I could then get additional rfid blanks for $7 and cut and program them.
Once you had two original keys, you could do the "DIY programming" method to make keys 3 and up.
The DIY method was something like "insert key 1, wait 3 seconds, remove, insert key 2 wait 3 seconds remove, insert new key, wait for something, remove" and you would get key 3, 4 ...
There were similar but separate ford procedures for programming the buttons on fobs to lock/unlock doors, etc
My plan for the future is a trailbike, a tent and a shotgun.
But with regard to a car, I don't know. I'll just do the best I can when the time comes. I'm hopeful there'll be options available or where I can cut antennas or whatever.
Which I read this a month ago. Mazda dealer charged me $450 for mine. I figures the entire system is propietiary, so they can charge whatever they want.
Some people like messing with cars. They take the time to understand what's happening and learn the process and pitfalls. Hobbyists wiil never be as good as trained professionally but we can still get the job done. I went through the trouble to diagnose and replace a bad alternator on my civic after the battery started dying too fast. I did it cause it was fun.
The other reason i did it is because the dealership and other shops quoted me over 10 times the cost of parts, and I literally did not have the money to take them up should i have wanted to. Car maintenance is expensive, _especially_ at the dealership.
Some how, we've changed the direction of the conversation to something you lost vs a software update to the brains of the car. I'm guessing just to make the obvious point the dealership is not the cheapest place for repair.??? This isn't change the tire or get an oil change. This is something a consumer has deliberately done to prevent the manufacture from making an OTA software update. These are the kinds of changes that I want someone available right then and there to be responsible if the update borked the car.
Sure, but you have to realize that everyone isn't you. Many people are quite comfortable messing with the deep internals of their vehicle, to the point of changing code in the ECU. Others won't even change an air filter. Takes all kinds.
There's really no reason to be scared working on your car. I have no formal training and I have never paid a shop to fix my car in my 20 years of car ownership.
The mechanical parts of a car haven't changed much in the last 25 years, and are easy to understand just by watching a few YouTube videos.
The electronics have certainly gotten more complex, but if you can understand basic computer networking and low voltage electronics it's still quite simple.
If you are interested in learning how to fix your own car, there is a great guy who runs an auto repair business on YouTube and his tagline is: "Remember folks If I can do it, you can do it."
I'm pretty sure that the only diagnostic codes that an ECU is required to output are emissions-related codes. Since EVs have no emissions, I'm gonna guess they can force all diagnostics through the dealer if they really want to.
WiFi is, err, still OTA, although it does answer the eSIM question. I assume the truly concerned/paranoid wouldn't want to connect to WiFi either, since presumably telemetry / tracking metadata could be uploaded at that time too.
Anyone concerned about preventing telemetry from being uploaded would probably also be concerned about taking it to the dealer for an update, though. Because how do you know the dealer won't just do an update by turning the car's e-SIM back on, then turning it off before giving the car back to you? Which would then allow the car to upload all the stored telemetry you're concerned about. (Note: generic "you" meaning "the person concerned about telemetry", not bri3d in particular). Or, as long as they've connected a device to the car that can upload data, how do you know that that device won't also download stored data, which the dealership can then upload over their own WiFi?
I believe the truly concerned/paranoid will not want to take their car to the dealership for updates at all. Which would, IMHO, be a mistake: having known security holes in your car's software is more likely to lead to a privacy invasion (via getting your car hacked at some point) than letting the dealership get their hands on it for a few hours.
(I should note that all of this is theoretical for me: I drive a car that's old enough it doesn't have any software).
EDIT to add this P.S.: Actually, I can think of one category of people who would be concerned enough to turn off the car's ability to connect to the Internet, but feel fine about taking it to a dealer for updates. That would be people who want to turn off the car's Internet connectivity not because of privacy concerns, but because they don't want anyone to be able to disable the car (either via hacking or via "legitimate" means, i.e. the manufacturer does it) while they're driving. Such a person would care a lot about the car's Internet access being completely off while they are driving, but not care about it being turned on while it is at the dealership.
I read an article recently where there was a satellite outage and all porsche cars in the area would not start. They have some satellite based anti-theft system. (wonder what happens if your garage is shielded)
Personally, I wouldn't want this intrusive system (or telemetry).
This is the exact mindset that has amused me for years with computers. People use an OS with which they have a seriously hostile relationship. Why would you continue to pay a lot of money for a product you consider to be your adversary?
I kinda assume the dealer does this as part of any service they do. Either that, or they update some other way. My software notices went away when I had my service done, even though I’ve opted out of everything (and verified again after).
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.
reply