Notices by Alex Schroeder 🐝 (kensanata@octodon.social), page 20

@hugh Right! My wiki also doesn't have user accounts. There are passwords which you might need to know, but knowing the password is enough; no username required. Users are free to provide a name when editing pages in order to facilitate peer review and foster a sense of community, but it's not verified by anything.

@solderpunk I'm currently writing up a blog post, as a way of thinking it through again. Learning by writing, in a way. 😃
@gcupc

@linkskywalker @infinite_mao @PresGas @TeethTeethTeeth @taweret @sandrockcstm @cosine
Hi all! 👋 My RPG account is over on tabletop.social, in other words: @kensanata.

@solderpunk I think that's because I want humans to not be redirected automatically and I'd like machines to be redirected automatically. Since we can't distinguish between the two, I'd prefer the option that benefits humans.
In the past, for example, my private blog was hosted on http://emacswiki.org/alex – and the redirect still works. That makes it hard for me to agree to a "automatic local redirects only" proposal.
@gcupc

@solderpunk Hm. I see where you are coming from. I'll think about this some more. I'm not sure I agree, but it's an interesting perspective.
@gcupc

@solderpunk Perhaps. Cookies were invented for online shops. But they also enable people to build games. It seems to me that we should keep the protocol simple but extensible and provide simple clients that don't automatically do things that can be abused (follow redirects automatically, store all the cookies, send all the cookies). I guess I'm just not convinced that we need to prevent such things at the protocol level.
@gcupc

@solderpunk Regarding redirection, I think I'd prefer it if we didn't have a machine readable redirection. Let's have a human readable response with a link to the new location so that people just click through. At first glance there seems to be no advantage to have the client follow redirects automatically: not socially (users want to know), and not technically (just a few bytes of text). Should moku-pona automatically follow such links? I'm not sure. Is this a feature only for machines?
@gcupc

@solderpunk I guess I'm writing about this because I care, obviously. So, things I like: status codes, mime types, content-length (required for uploads because the server can't tell when you're done sending in my experience: it just hangs and waits, not sure what I'm doing wrong in my socket code), so essentially I'm thinking of keeping headers flexible and mail/news/http seems as good as any a format. My favourite application:
https://alexschroeder.ch/wiki/2018-12-01_Thinking_about_the_real_RSS_3.0 😃
But also ASCII control codes…
@gcupc

@solderpunk I'm also in favour of reusing the well known HTTP codes, now that I think about it. Using 2 for OK instead of 200 is a gimmick; using 200 saves mental bandwidth. Let's just list the codes that MUST be handled by conforming implementations: 200 OK, 400 BAD REQUEST, 303 SEE OTHER, 500 SERVER ERROR, 429 TOO MANY REQUESTS, for example.
@gcupc

@solderpunk One thought I had when reading about response headers was why not use ASCII control codes such as the record-separator \x1e. Or start headers with start-of-heading \x01 and switch to the actual text with start-of-text \x02? If we have multiple headers it would be nice if some people could add more meta information. And why not key value pairs like HTTP? I think they're sort of cool, like mail and news headers. The problem was not headers but the complexity added later.
@gcupc

@deshipu True, that. We should up the fines for all the orgs that store unencrypted passwords, encrypted passwords without salts, don't encrypt data at rest, and so on. And we should have extended liabilities such that companies are liable for their subcontractors with regulations on due diligence.

@dredmorbius That sounds like an interesting line of work!