I built such bumblebee houses a few years ago with the kids. The flap is essential against a kind of flies that lay their eggs in the bumblebee nest and their caterpillars eats the nest.
Either the Queen or the others learn the usage quite fast. Sometimes next generation queens remember it in the next year
No, the next generation queens grow in that swarm and learn it there. All swarm members learn it. To the queen (or the first few workers) you teach it. The rest learns from the others. But the workers are short living (few weeks). The queens live for about a year and can take knowledge in the next year.
Yeah I suppose that's true, too. You've got to do the conversion at some point. I don't know that you get any benefit of doing storing the text, doing the transformation to support whatever ops (deconflicting, etc.) and then transforming back to text again vs just storing it in the intermediate format. Ideally, this would all be transparent to the user anyway.
For one merge, yes. The fun starts when you have a sequence of merges.
CRDTs put ids on tokens, so things are a bit more deterministic.
Imagine a variable rename or a whitespace change; it messes text diffing completely.
Only if the attacker has a valid certificate for the domain to complete the handshake with.
Relying on HTTPS and SVCB records will probably allow a downgrade for some attackers, but if browsers roll out something akin to the HSTS preload list, then downgrade attacks become pretty difficult.
DNSSEC can also protect against malicious SVCB/HTTPS records and the spec recommends DoT/DoH against local MitM attacks to prevent this.
DNSSEC can't protect against an ECH downgrade. ECH attackers are all on-path, and selectively blocking lookups is damaging even if you can't forge them. DoH is the answer here, not record integrity.
DNSSEC alone is obviously useless because any attacker interested in SNI hostnames can just as easily monitor DNS traffic.
However, DoH/DoT without record integrity is about as useful as self-signed HTTPS certificates. You need both for the system to work right in every case.
To quote the spec:
> Clearly, DNSSEC (if the client validates and hard fails) is a defense against this form of attack, but encrypted DNS transport is also a defense against DNS attacks by attackers on the local network, which is a common case where ClientHello and SNI encryption are desired. Moreover, as noted in the introduction, SNI encryption is less useful without encryption of DNS queries in transit.
I don't think this is true; I think this misunderstands the ECH threat model. You don't need record integrity to make ECH a strong defense against on-path ISP attackers; you just need to trust the resolver you're DoH'ing to.
This actually reminds me of the "God of the gaps" problem. A gradual retreat in the face of inconvenient facts.
Many years ago when I was a student the argument was that integrity isn't a big deal so plaintext telnet is just fine. If you're paranoid you use an "enhanced" telnet where the authentication step is protected but not everything else [Yes I'm an old man]
By the turn of the century everybody agreed telnet is stupid, use SSH but integrity still wasn't a big deal when it comes to ordinary web sites. Only your bank needs SSL fool.
And I suppose that 8-10 years ago that changed too and it's now recognised that plaintext HTTP really isn't good enough, you need HTTPS. But still I see that you say integrity isn't important when it comes to DNS records.
Integrity is the hardest thing to get ordinary users to care about. Given how freely even young kids lie we should probably take it more seriously but it remains hard to get ordinary people to care, however ultimately this does matter.
Sir, this is a Wendy's. We're talking about ECH. Can you maybe rephrase all this to be specifically about how DNS record integrity practically impacts the threat model for ECH? The threat actor for Encrypted Client Hello is ISPs.
This same thing happened with DNS cache corruption; which went unaddressed from the mid-1990s to 2008 despite the known fix of port/ID randomization because the DNS operator community was fixated on the "real" fix of... DNS record integrity.
> you just need to trust the resolver you're DoH'ing to
I don't trust the public DoH resolvers that much, actually, and neither do I trust my own ISP. I know for a fact that they mess with DNS records because of court orders, and I want to know when that happens.
DoH and DoT are not the modern DNSSEC alternatives we need. They naively assume that the DNS resolver always speaks the truth.
If browsers remember which domains do ECH and refuse to downgrade to non-ECH connections after, the way the HSTS cache forces browsers to connect over HTTPS despite direct attempts to load over HTTP, then you only need an entry in the browser database to make downgrade attacks to accomplish SNI-snooping impossible.
For HSTS, browsers come with a preloaded list of known-HTTPS domains that requests are matched against. That means they will never connect over HTTP, rather than connect over HTTP and upgrade+maintain a cache when the HSTS header is present. If ECH comes with a preload list, then browsers connecting to ECH domains will simply fail to connect rather than permit the network to downgrade their connection to non-ECH TLS.
Well, there's iSH and a-Shell but they don't have GUI capability and are somewhat limited in other ways. There's also UTM, but without weird hacks you can only get SE version which is very slow.
If you do proper software development (planing, spec, task breakdown, test case spec, implementation, unit test, acceptance test, ...) implementation is just a single step and the generated artifact is the source code. And that's what needs to be checked in. All the other artifacts are usually stored elsewhere.
If you do spec and planing with AI, you should also commit the outcome and maybe also the prompt and session (like a meeting note on a spec meeting). But it's a different artifact then.
But if you skip all the steps and put your idea directly to an coding agent in the hope that the result is a final, tested and production ready software, you should absolutely commit the whole chat session (or at least make the AI create a summary of it).
LLMs frequently hallucinate and go off on wild goose chases. It's admittedly gotten a lot better, but it still happens.
From that perspective alone the session would be important meta information that could be used to determine the rationale of a commit - right from the intent (prompt) to what the harness (Claude code etc) made of it. So there is more value in keeping it even in your second scenario
I try to use AI incremental and verify each result. If it goes mad, I just revert and start over. It's a bit slower but ensures consistency and correctness and it's still a huge improvement over doing everything manually.
I'm deeply impressed, especially with the "replace window by mirror". It did not only do the window thing right, it also changed the illumination of the whole room while keeping all the other details unchanged.
Right? That part kind of blew my mind too - the multimodal model actually altered the overall lighting in the room by eliminating all the reflections and specular highlights when the natural light was taken away WITHOUT being asked in the prompt.
reply