Or is the argument that even though this is worse it's so useful we might really want to do it anyway?

If there's anything I said that made you think otherwise, let me know: I would like to amend that so no-one else thinks I could possibly mean that. The initially recommended (unless you can do otherwise) approach in the blog post is clearly "tag at the end" and every other approach also validates first. If you're referring to ObjectHash: like I said, it's a very niche application, I don't expect people to use it, and yeah, it enables new use cases.

(I expect you'd still really be authenticating the ObjectHash somehow -- e.g. by sending it over TLS -- but that's out of scope for ObjectHash itself.)

"I don't expect people to use it" just seems like the sort of awful excuse you'd usually be jumping on people for. It's like someone built a github project with a bunch of crypto red flags to check whether their new "Search github for projects with crypto red flags" idea works.

Don't get me wrong, it's clever, and I like clever. But I have learned in cryptography to only accept clever when it is clearly in the service of a specific pre-identified goal, and not just for its own sake. Isn't that normally a philosophy you'd subscribe to? What's the _pre-identified goal_ for this thing?

While we're here, another red flag. Mentioning Certificate Transparency as a model for some other X Transparency. Certificate Transparency isn't a model for anything. People have been saying to themselves almost from the dawn of CT "Oooh, this is clever, I should do the same for X" and it's always a bad idea. Someone might need a Merkle Tree. I'd argue they shouldn't use ObjectHash anyway. But the chance they need all the other paraphernalia from CT? Basically non-existent.

I think it was pretty clear, by calling it a specific niche that ObjectHash does a good job of exploring, that I am not making a recommendation.