looks

https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest

Well, it can’t take a stream as input, so it’s not that an output can’t be provided because the input might not be fully known.

And it seems kind of odd if the aim is parallel execution.

pokes around a bit more

I don’t really code in Javascript much, but as I very vaguely recall, at least in browsers, Javascript doesn’t normally have the ability to do concurrent execution…there’s some sort of mechanism that isolates code running in parallel, Web Workers, as I recall.

One of the things that Mozilla’s docs on Promise mentions is this:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

The Promise class offers four static methods to facilitate async task concurrency

Note that JavaScript is single-threaded by nature, so at a given instant, only one task will be executing, although control can shift between different promises, making execution of the promises appear concurrent. Parallel execution in JavaScript can only be achieved through worker threads.

So, one thing that you normally have to do in APIs that have cooperative multithreading going on is, if you want the system to stay responsive, is to make sure that if you’re gonna yield to other threads if you’re gonna be doing some work for an extended period of time. Like, say you’ve got something going on that’s CPU-bound and something that’s network-bound…you don’t want to have one blocking on the other. You want to slice up the tasks and switch back and forth between them to keep the network connection saturated.

I am thinking that it’s possible that the goal here is to do that. Like, you might want to be generating a hash of a big block of data, say a couple gigs. Maybe it takes Javascript a while to do that. So you generate a Promise for that computation, along for the other things you need to do, and then wait for any of them to complete.

If you don’t have anything else going on in your particular codebase, then you can just immediately block until the Promise is fulfilled.

That being said, that’s just my kneejerk reaction based on about a two-minute skim and some familiarity with past systems that have worked in kinda similar ways.

Each node sends its information, like its name, public keys, etc via IPv6 link local multicast packets. I’ll call these packets advertisements. I choose IPv6 link local because no manual IP address configuration is required. The kernel automatically assigns IPv6 link local addresses for each network interface.

When another node (B) receives the multicast packets, it knows that it can receive packets from the former node (A), but what about the other way round? For that, node B then establishes a TCP connection to node A. If node B can connect to node A, we can conclude that a bidirectional communication is possible between node A and node B.

Let’s say that you have 3 nodes, A, B, and C.

What happens if Node C sends Node A an advertisement for Node B’s name with Node C’s public key?

When A tries to talk to to B’s name, it connects to C using C’s key. C connects to B using B’s public key, proxying the connection, and performing a man in the middle attack.

Also, I don’t know for sure about other e-readers, but the Kobos I’ve had are not what one would call high-power-consumption devices; part of why the battery can last so long. I don’t really recall them heating up.

Oh, that’s a fair point, yeah, I suppose that anything where only software avoids some kind of catastrophic physical failure does legitimately have its own risks.

Personally, a 3D printer that has to be connected to a cloud would be a hard no. Even more so when that cloud is located in China without EU or US oversight.

I don’t see why a 3D printer in particular would be a concern, unless you’re prototyping stuff for a business and worried about proprietary commercial stuff getting out.

But I’m amazed that people in general are willing to connect their systems – 3D printer or anything else – to an outside provider’s service. It has a considerable number of drawbacks.

• It punches a hole in what is normally the front line for home computer security, the firewall/NAT device. Most setups default to not allowing inbound connections. Now you’ve got some device that is opening connections outwards and could talk to other systems on your network.

• It permits the manufacturer of the device to change the terms on which I can use the device. Maybe down the line the manufacturer of your smart TV – who is not getting any revenue from you after the initial sale of the device – decides to start inserting ads, say. This sort of thing has been done before. I want the manufacturer’s interests to be aligned with mine. Before the product is sold, they have to convince me to buy the thing. Afterwards, those interests could diverge. I don’t want the manufacturer to be able to alter the terms on which the product I bought may be used if our interests have diverged.

• Even if you want to trust the manufacturer’s intent, can they secure their own system against people with more malicious aims? If someone can break into that, they can affect all of the customers, which may make it a tempting target. Russian intelligence attacked Viasat satellite modems, using an exploit that they’d clearly found earlier, when Russia invaded Ukraine to try to disrupt Ukrainian communications. They pushed a firmware update to brick modems. They didn’t even just impact systems in Ukraine, but also some outside, like a German offshore wind farm’s control system.

• If any functionality depends on that manufacturer staying in business and being willing to keep paying for the operating costs, that seems fragile. Many companies do go out of business or decide that the costs of operating a service aren’t worth it.

• Just being able to track someone’s moves across IP adresses has some value; reselling that information helps deanonymize people. Could happen down the line if a company is acquired by a larger company that data-mines its logs.

• If you lose Internet connectivity for any reason, you lose local functionality. Home automation stuff is a particularly egregious example – you don’t want your light switches or climate control to stop working if you don’t have Internet connectivity to somene’s cloud service. But it’s true for any number of things.

I’m kind of surprised that sticking an airbrush on a robotic arm and doing an airbrushing job electronically hasn’t become a thing in 3d printing. I mean, anyone doing 3D prints is starting from the point of working with a 3D model already.