With HTTPS alone, I can assure you that HN is, indeed, the recipient/end. If you post something like a PGP-encrypted message on HN, now you've got a situation where HN is no longer a recipient/end.

I think the better point to make is that we all collectively agree to refrain from using the term "end" (as in E2EE) in situations like the former, as it's misleading despite being accurate; please only use it for the latter.

I am aware that I send my messages to HN, they are not forwarded to you but you open the HN page to read my response. HN is more like a message board with message hierarchy. The communication is public, the transmission path is encrypted.

It's more like whispering in your friends ear and she/he writes in down and pins it to a public board. My communication was private, but he/she is a chatterbox and I'm well aware of that.

BTW I didn't receive your reply but had to look it up on HN, so I maybe be your intended recipient but technically I'm not.

Kind of, but as they aren't lying about allowing private conversations not really. More saying https is end to end encrypted, but what one end does with that data isn't necessarily private.

Ideally it would be the human at each end doing the encrypting and decrypting. But humans can't be bothered, so we let some code that we know very little about do it for us. Obviously having that code run on the client device (the one in your hand) is preferable to having it run elsewhere (like some web server), but either way the human (the true end) is delegating the job to an entity that isn't quite at the end, it's ever so slightly toward the center.

Things like PGP help to maximize the endianness, since the human has a better sense that the crypto software is legitimate, and can read the code before executing it, although there's still plenty of points of compromise between that code and the human (compiler, Intel ME, etc.) so unless you're doing crypto with a pencil and paper, you're always putting your trust somewhere that isn't precisely the "end."