@Rairii But neither could web stuff, until it could. Like, that's kind of the problem with this rationale - people remember Gopher fondly because it's essentially frozen in time from before mass exploitative really took off on the web, as it'd already lost popularity prior to that.

Had Gopher become the canonical protocol for the web, then by now it would have grown the exact same junk as HTTP-based web stuff has, because the people doing the exploiting are also the ones with control over standards and adoption processes.

@joepie91 true

@joepie91 @Rairii In theory there's just not the same places to add things (no HTTP headers, nesting HTML tags in Gopher e.g.), but in practice people find other places. Often they give up cohesiveness; someone figured out how to stick info to upload in the pathname, but this entails multiple requests for transactions with longer uploads (due to pathname length limits), although ostensibly multiple requests for a transaction shouldn't happen.

Adding other protocols isn't uncommon, e.g. another one to let you upload things, and just sweeps the complexity around. That example is especially silly when uploading is more-or-less just backwards downloading*; it'd be less effort to spec out the interaction with client/server reversed, rather than make a new spec.

*ignoring authentication and integrity, which is par for the course

@hayley @joepie91 @Rairii The only way to avoid implementing junk in your protocols over and over is to have a specification for a meta-medium that allows you to create not just an unlimited amount of junk, but unimagined junk.