Dagonfly

You were asking about reachable, not routable. Of course, an address behind a firewall might be adressable and theoretically routable, but it certainly isn't reachable.

The default config of a SoHo router has both: (a) NAT44 separating public vs. private IPv4, (b) and also a firewall that blocks any unknown ingress traffic on IPv4 and IPv6.

From a security standpoint, it doesn't matter if the IP get translated inbetween. Only the ingress firewall counts: If the firewall is in-place both IPv4 and IPv6 traffic will be blocked. If you open up the firewall (via hole punching or port forwarding on IPv4, or via IP allows for IPv6), I can send packets to your public IPv4 + port and they will arrive at you private server, or I send them to your servers GUA IPv6 and it arrives. There is no security difference.

To be clear: There is no permanently frozen guarantee. Tether can and has unfrozen (called removeBlackList)addresses before. All of this is just a public database fully controlled by Tether Limited.

I would not consider USDT to be an example for transparency or free flow of information. The selling point of USDT is that it's pegged to the US doller. Users put at lot of trust in both that 1:1 ratio and therefore indirectly in the US FED.

But: Are you sure that Tether is actually backed by USD? It certainly isn't free information.

It's only really a learning curve if you're an expert at IPv4, and try to apply your IPv4 mental model directly to IPv6.

Why would it be reachable? It might be name-able but that doesn't imply reachable.

You're conflating the two parts of NAT: address translation and inbound filtering. A router can block any inbound traffic coming from WAN, even if the IPv6s on the LAN side are public.

In fact, hole punching for IPv4 shows this distinction. By default inbound traffic is blocked, but as soon as private host has opened up a connection, it is (indirectly) reachable and nameable (via the routers public IP + port).

BTW, static IPv4 NAT with public addresses on both sides exists as well.

TBH, the more you know about the technical aspects the less fascinating it gets.

Smart contracts and stablecoins by extention sound technologically interesting, but at the end you always rely on trusting people.

The core of the financial system is about managing trust and therefore a social issue, not a tech issue. It'd be nice if more tech nerds would internalize that tech can't solve social issues on it's own

The lession learned is: Tether now exists as a casino chip central bank. They can just freeze and print more and provide a backstop to the major CEXs.

Of course, Tether runs completely counter to any of the idealistic claims about crypto.

TVs and monitors have this naming strategy because of retail stores. You can't price compare between different stores if every one has their own exclusive model with a different set of RNG numbers in the name.

Same for appliances or most products that are bought through a middleman rather than directly from the manufacturer.

Most banks integrate Wero into their online banking app, but some (e.g. mine) use the dedicated app for Wero (It's just called wero on google play and iOS). You still sign up with your bank account though.

The critical feature that Wero needs is adding money to your account balance via SEPA instant or credit card. That way users without participating bank accounts can join.

The hypocrisy of the second quote is a bit on the nose. If the internal reasoning is so valueable, why do they increasingly hide it from the user?

It's honestly shocking how terrible copilot is at generating interesting and relevant metrics from excel.

The local optimum still seems to be: Let LLM of your choice generate a polars script that reads the spreadsheet and explores them for you.

My partner recently used that "pattern" at work to find outliers and interesting metrics in years of excel reports. Data they were working hours for. Now available in a single human language query.

I don't think the HN crowd understands how many million jobs are primarily staring at excel reports and copying values between forms, pdfs and spreadsheets.

Skimming through the exchange protocol draft it seems like a pretty standard diffie-hellman. Seems easy enough to write a FOSS script that requests an export and then dumps it to plaintext.

Yeah, I was only talking about differences for backup.

As long as no attestation is used, you only have to store the private key, credentialId and userHandle (basically the server generated ids of the passkey and the user). That's not to different to writing down username and password.

Why would they need to re-generate? Pretty much all websites are using copyable passkeys. The user just needs log in to their password manager on their new device. Which for most people just means logging in to their Apple or Google account. There is virtually no difference to storing generated passwords in a password manager or storing passkeys.

And the sad truth is: Most people have no password manager at all. They are used to re-generate new passwords every time they want to log in! I'd wager that on some websites the vast majority of people are loggin in by pressing "I forgot my password".

Passkeys are just a private key plus some metadata.

Bitwarden lets you export your vault, and the export contains the private key in plain text. There is virtually no difference to writing down a password on a piece of paper. Well, I guess a passkey is a lot longer than the avg password.

This changes if attestation ever becomes widespread. Which will only happen if Apple does a U-turn on their stance.

Tbh, I would have imagined the SHA-256 transition to work differently.

Let's treat git as a SHA1-keyed object storage. The problem is that we currently use SHA1 both as database key and as hash for integrity validation. At first, I would have only changed the latter.

Local: Request object with key x (SHA1). Remote: Here are the bytes for key x (SHA1) with hash SHA-256. Local: Verify the bytes vs SHA-256.

Local: Store the following bytes with key x (SHA1) and hash SHA-256. Remote: Checks bytes SHA-256 AND checks if key x has ever been stored in the database. If so check that SHA-256 under key x matches the new SHA-256. The prevents SHA1 collisions from being stored. The only thing the repo has to keep is a LUT from key (SHA1) to hash (SHA-256). This duplication check the important change. Repos would only accept pushes containing both SHA1 and SHA-256, but they can still handle fetches with SHA1.

The SHA1 key then just becomes a convenient alias for an object. The only restriction is that you can't have two objects with the same SHA1 in a repo. We already kinda do this when we refer to commits with the first few chars of the SHA1. If there is a "collision" git already detects it and asks you for more characters.

Then you can convert the internal representation of the tree to SHA-256. If some legacy client requests aliases via SHA1 you use the LUT, new clients request the SHA256 directly.

Am I missing anything obvious here?

Plenty of high refresh gaming monitors out there that use HDMI 2.1 or DP1.4 with DSC.

DSC is just the "card up the sleeve" for DP1.4, you can push it all the way to 4K 240hz HDR. So there is little incentive to switch to DP2.1 for OEMs.

Oh yeah, I've read about all your blog post on this topic :)

To dump some ideas on you: I think one missing piece might be that FnOnce() -> impl Future should implement IntoFuture. Async runtimes would then use IntoFuture in their APIs agressively.

I call this a "workload blueprint" at work. Its a closure/type that contains all the info to start the workload, but in a minimal form. In Rust terms this would be a buildprint that is ideally Send + Move + Forget + 'static, even if the actual work (and the backing struct of the Future) is !Send (e.g. It holds an Rc across await points).

Runtimes could use this for their advantage: There would be a global pool of "workload blueprint" that can be stolen by any executer thread, but once a !Send workload has started on one thread it can't be migrated to another.

This in combination with matklad's ideas about seperating TaskSend from ThreadSend (https://matklad.github.io/2023/12/10/nsfw.html) would solve most of my async pain points.

Sure, thats one reason why IntoFuture and Future exist. Imo, in hindsight this is also main mistake in aysnc Rust: The whole async system should be build around IntoFuture rather than Future (async fn should return impl IntoFuture).

That way you could pass around IntoFutures without being affected by auto traits leaking. Only when you actually call .await() or .poll() would the immovable Future materialize.

Here is an example of the problem: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Imagine if MyTrait comes from core/std. Adding an opt-out bound like ?Sized (or ?Move) is a breaking change for any generic code that relies on Sized/Move. But you want some traits from std to be open for !Move types.

The compat issue has always been associated types on std traits.

For example, should Iterator::Item be Move or ?Move

If you leave it as Move, you can't create any iterators over !Move types. If you change it to ?Move, then functions using generic iterators can't assume that the elements of an Iterator are always moveable. Which is a breaking change compared to now.

The most critical trait is probably Deref. Using !Move types without `Deref::Target: ?Move` is painful, because calling any method on boxed types relies on Deref.

Passing ownership to another thread is not the same as forgetting/leaking.

The point of !Forget is ensuring that once the owner goes out of scope the destructor must be guaranteed to run. An infinite loop is not a problem, cause the new thread will never leave its scope. Ref-cycles are a problem, cause you can create a ref-cycle. Then the program flow leaves the scope which will run the drop on all RC's but not the drop on the inner type.

> the point of Pin is to wrap types that CAN move.

I would highlight that there are many cases where you CAN move an object safely until a certain operation requires the object to "stay put" in place.

Pin allows for that by tying the object to the place only when required. That's why Pin relates to both the object and the place.

Meanwhile, !Move types can't ever move. The object has to remain in the inital place it was constructed in. !Move requires in-place construction and emplacement to be ergonomic at all.

> some of the dirtiest electricity generation in the entire world

In Europe. Still cleaner than the US, China, India, Japan, and the world avg:

https://ourworldindata.org/grapher/carbon-intensity-electric...

Coal and gas are down 50% compared to 10 years ago despite the shut-down. Nevertheless, shutting down the last few ones was bad.

It's the one thing I miss from Swift when I'm using literally any other language. Interal and external parameter names. I would love for Rust to adopt:

  fn foo(namedParam internalName: bool) { // use internalName here }

  fn foo(unnamedParam: bool)

Just to be clear: There is an official notice of the EU commission making this legal argument:

https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:52...

> Consequently, in the case of portable batteries included in products covered by Regulation (EU) 2023/1670, the removability and replaceability obligations set out in Annex II of that Regulation prevail over those set out in Regulation (EU) 2023/1542.

The ecodesign law (spare part but 1000 cycle exemption) pevails over the batteries law.

You are right that intraday went even more negative than day-ahead. But I disagree about the rest of your comment. A spread between day-ahead and intraday does not imply additional redispatch. Only some of it might have been countertrading by the grid operators.

The redispatch was not extraordinary: https://energy-charts.info/charts/power_redispatch/chart.htm...

So many questionable comments in here.

Negative prices have no effect on grid stability. It just means that the day-ahead market was cleared below 0, i.e. for every consumer (buyer) there is a producer (seller) selling at this price. The market is still balanced with consumption==production.

Now, you can ask the question: Why are so many producers willing to sell below 0? That has to do with misplaced incentives. For older or home-installed renewables there is a feed-in tarrif which guarantees a fixed revenue at all times. So there is an incentive to sell even for negative market prices. Newer installations can't opt for the guaranteed revenue model with revenue during negative prices any more.

Redispatch follows afterwards, if the market result clashes with physics: The physical grid can't transport the power from producer to consumer. There was no unusual amount of redispatch during easter.

Source: I work on this stuff.

Well it relates to this sentence:

> You can use any credential manager you choose.

Which I would be careful with. I can use any authenticator that the RP accepts. I could totally see a future where banks only allow certain authenticators (Apple/Google) and enforce this through AAGUID or even attStmt. Similar to the Google Play Protect situation.

At that point, those banks/services would enforce vendor lock-in on me. The reality would be: I can use iOS or Android, but not a FOSS implementation. This restriction is not possible with old-school passwords.

Quoting your comments on github [0]

>> There is no passkey certification process

> This is currently being defined and is almost complete.

>> no signed stamp of approval from on high

> see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.

Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?

[0] https://github.com/keepassxreboot/keepassxc/issues/10406#iss...