I mentioned multipart/x-mixed-replace above and I think it can work here instead of CSS. You never reload the chat history page, just put that in an iframe and use a separate iframe with a form that submits your newest reply.

Edit: actually this should work even without mixed replace.

When the form submits its frame refreshes ("navigates").

Right but reloading a static html asset (the reply iframe consisting of just a textbox) is basically free. So long as you separate the chat history window and the reply textbox/form into two separate frames, I don’t see the problem.

Using JavaScript is also “basically free”.

There’s no problem with either listed approach, GP just seems to consider a method without page reloads as adhering to a harder constraint.

Using JS would have broken the threat model of the dark web chatroom. So it is a non starter in that context.

I thought chrome killed x-mixed-replace (except for jpg images)

Mentioned above: https://news.ycombinator.com/item?id=36545326

> the page also never reloads

Well, that's really only technically correct, since the strategy here is to replace the whole page with a new version of it on each virtual keypress, by using CSS to hide the previous HTML and then receiving the new updated version of the web page's content. The only tricks is to use a chunked content-transfer to have this all happen over a single HTTP request, so yes technically the page does noes reload, but it's pretty much the same thing as if it did.

Really cool trick nonetheless! And more importantly fun trick, and fun read :).

I think it'd at least eliminate some of the overhead with establishing new connections on every request with HTTP/1.1 or HTTP/2, but I'm not sure about HTTP/3