Which is one of the reasons why Discovery and Picard at least are problematic (I haven’t seen Academy).

As you say, a lot of the old stories aren’t really that good. What happens when they had a bad story, or maybe less ‘bad’ and just didn’t engage with you? New one next week.

With Discovery and Picard? Well the whole season is the story, so if it doesn’t engage with you, you are pretty much out for the season.

Personally, I never felt there was really enough narrative “meat” in their stories to warrant a season long arc, and so it felt a bit stretched for time for the perceived “a story needs to fill a binge” market.

Strange New Worlds primary win was returning to episodic, to give a story a chance to shine or fail in a digestable amount of time and move on. Was at its weakest when Season 3 kind of devolved to a weird arc.

Pretty much. And maybe in the off-screen bragging about it, at least say first main character or first crew member (someone argued about Dax, but I’d say that character was gendered, just fluid over the long term), not ‘first character ever’, since you had a number of instances, and pretty much dead-on a whole species dedicated to exploring gendered versus non-binary in TNG. That’s one habit of Discovery was leaving people wondering if they even watched the shows that preceeded them…

There should have been no good reason for Adira to only tell Gray despite their clear desire to be recognized as non-binary.

Or, alternatively, they could have established that 32nd century Earth cut off from the federation had backslid to MAGA-sensibilities to explain why far future human feels the need to tiptoe around their identity until they come to terms with the culture of the federation that might have been lost to Earth.

I quoted the show. Season 3, episode 8. After several episodes of going by “she” did Adira actually say anything, after spending their entire life only telling Gray.

Why else would they withhold this their whole life except for anxiety. Is not like they had an awakening, they said they never felt that way and had already confided in the person they were closest to.

They made it very clear that asserting a non binary identity was just uncomfortable enough in society in the 32nd century that Adira felt a need to keep it to themselves.

Ugh, fine.

“Adira, who joined us from Earth, may be able to guide sto Federation headquarters one she regains her own memoris”

“Is there any way the symbiont was joined with Adira against her will?”

Basically, Adira spends episodes 3 through 8 rolling with feminine pronouns, keeping their non-binary nature a secret.

Adira doesn’t come out until Episode 8: ADIRA: Um, “they.” Not… not “she.” I’ve never felt like a “she” or or a “her,” so… I would prefer “they” or “them” from now on.

STAMETS: Okay.

ADIRA: Um, and I’ve never told anyone but Gray.

Adira kept their non-binary identity secret and took them 5 episodes to work up the nerve to declare to the first person other than Gray. I think the traditional trek move would have been from episode 3, right out the gate, first reference to this new character would use non-gendered pronouns because, well, why would they feel they need to keep it a secret?

I’d have to rewatch, but I recall as they picked Adira up from 32nd century Earth, despite being a fully grown up person, went by feminine pronouns. Adira had to work up to come out, rather than being out from the onset.

I recall because I was very confused on Adira’s introduction because they kept yelling from the rooftops about how progressive they were by having a non-binary character, but Adira and everyone around Adira kept using feminine terms. I distinctly recall a ‘coming out’ moment which seemed to be played with trepidation.

The fairest thing I could say is that 32nd century earth was no longer “federation” and so maybe they had a big old conservative backslide and so Adira’s plight was due to the gloomy setting of isolated Earth with the loss of FTL travel.

https://www.startrek.com/news/star-trek-discovery-introduces-first-trangender-and-non-binary-characters

Is where they officially declared that Trek was doing a non-binary character for the first time.

Actually, as I recall the entire society was ‘non-binary’ and that specific alien wanted to come out as female. And of course Riker banging was a green light after she declared herself female. Probably not the best choice to have Riker banging her as part of the narrative, but yeah, that was famously an example of them trying to address a point by inverting real-world, the ‘norm’ is non-binary and the ‘unusual’ one is gendered and the Federation serves as the model of ‘we respect your people either way, you should too’.

It got there, sure, but that coming out was a bit rough, because they treated it as a “big deal”, they were afraid of coming out and ultimately did, but seemed to harbor anxiety that should have not had a place anymore. They got over it (I assume, I actually kind of lost track of Discovery), but at one point it was too big a deal.

Also, out of universe, they were a bit annoying about bragging about being the first non-binary representation in Star Trek ever, which just seems disrepectful of the times it came up before.

The thing was in TOS that kiss, in-universe, was no biggie. In DS9 with all the gender and sexuality shifts in the Trill scenario, it again just ‘was’. When it was a big deal, it was some alien culture being backwards and the Federation being an example of doing it right.

STD was oddly self-congratulatory. “First ever non-binary character in trek!” they proclaim as people were able to respond with just so many examples of previous non-binary characters. The character despite being a human, being on Earth, had to make a big deal of “coming out” and a big outpouring of support in-universe to balance out the trepidation of coming out. Which should have just been a very mundane scenario, you want the character to be non-binary, fine, they are, people will be respectful but it will be a boring mundane fact rather than some big deal.

Yes, there are those that are flipping out over too much representation that are done consistently with star trek. Probably the most fair point was that someone probably wouldn’t be out of shape, but by that logic, Picard shouldn’t have been bald, so…

If I provide passkey support and still require a password, most users will get annoyed and not bother. If I provide it as a replacement for password, then I can get them onboard more often. I’d rather have them using passkey than sticking with password.

It’s client specific and my phone requires whatever can unlock the phone and chrome requires either windows hello or a pin if under linux.

Certain implementations do whatever, and as far as the backend is concerned, there’s no way of knowing, unless you want to get into the business of locking down specific vendor keys…

But I say MFA is overrated versus just getting away from generally crappy password factors. Also passkeys are less phish-able than OTP type solutions.

I wouldn’t even mind wrangling some normalized data, but it doesn’t seem very normalized in their examples.

Their first example suggests “great, there’s a human appropriate title and detail, and maybe this standard will say you should at least have those and they should be ready for pass through to a human operator”, with extensions providing room for more sophisticated behavior.

Then the second example, no more top level detail, now there’s an ‘errors’ array, and detail is under the children (which they don’t formally describe the concept of reparenting attributes, just incidentally showing it in an example of what an implementation could do with ‘extensions’). Well, at least I can still pass through the details if I find them and it will make sense right? “must be a positive integer”… Ok, nope, error information that requires the client to process a json pointer in order to manufacture some sort of actionable feedback. Again, this could be a neat optional feature, but a generic core client really has nothing they can bite into that generically applies to the standard.

The cited RFC I think is close to some ideas but softens it by trying to be open ended. If it specified mandatory top level “detail” member that is reasonably directly informative to a human operator without further processing, great, I know exactly where to find it even if I don’t otherwise understand your problem type. Mandate that errors may be a collection under an ‘errors’ list, but otherwise identical to top level? Cool. Saying that here’s some recommended members, but they are all optional and the behavior is really up to you, and you can just freely change everything you want and call it ‘extensions’… Just not prescriptive enough despite the long words…

Ok, got you, thought you were saying a bad url from client was inherently a backend mistake.

It’s ok, as long as you make sure to use mongodb it will be webscale no matter what. But if you date use anything else, it won’t be.

misdiagnosing errors originating from transport as application errors, and vice versa.

Shouldn’t the response body disambiguaite clearly whose fault it is? I mean you have to anyway if you advocate for ‘200 for everything’. You still have that same response body whether the HTTP status code is 200 or 500.

We honor the status code while providing an error body and it’s always blatantly obvious whether it’s an infrastructure issue or “true backend” issue when we see an issue. In my team I can’t recall anyone ever getting confused for even a little bit about whether an observed anomaly was web infrastructure or the backend, despite us setting HTTP status codes to error when, you know, we see an error.

I think the challenge is that it looks like a lot of other ‘standards’ I’ve seen: on one hand tediously specific yet on the other hand, so open ended as to largely defeat the point.

Every problem must have a ‘type’. Ok, fine, so what are the semantics of the ‘problem type’? Well, nothing in particular, just has to be defined, but it might be nice if it’s a url telling a human about your own human thoughts on the type. Also, if you encounter multiple ‘errors’, you need to omit any that you arbitrarily fail to group into the same ‘type’ which shouldn’t be subjectively too vague either, so don’t think about making catch-all types so you don’t have to discard some of the errors.

You can’t count on the members, and a problem type may arbitrarily ‘extend’ to completely rearrange those members into members of child objects instead, but that’s really all up to the backend to decide however they want to arrange it, with no prescribed standard for error bundling, but an example of how a backend could voluntarily implement such bundling as an implementer specific extension if they like, but again, don’t bundle errors that shouldn’t seem to be of a common type…

Also I think it’s funny that they say do this in the name of being a good web citizen, but then say send this new mime type down, client’s Accept header value be damned.

It purports to drive toward “machine-readable” problems but it seems like there’s not much actually actionable and the client has to in practical terms do a bunch of bespoke handling to deal with a backend that is still pretty much open to do whatever they like.

It has a couple of reasonable seeming examples, but nothing that would make me think “Oh, you implement RFC 9457? Then I already have error handling code ready to go!”

I’ve seen all sorts of complex errors generated by backends that have all sorts of features like this and more (error messages with parameterized string values, json pointers to specific problematic pieces of the client request. However people just want a human readable response to pass along. I could imagine the example ‘pointer’ being useful to map error details to a client maintained form, but that’s not even the ‘standard’, just a random example ‘extension’…

I would argue that in your application, a wrong URL is a sever error. That error being improper handling of a client error.

That’s certainly an unusual take. If you are a backend to HTTP and something throws a completely bogus URL out of left field at you, that’s not by any means a backend error.

I guess your take is that it might be some sort of usability issue or such because if 95% of clients try to hit the same non-existant URL, that probably means there’s some reasonable expectation that you should do something about the URL. However that’s relatively more rare a sort of ‘invalid URL’ scenario. The vast vast majority are some sort of scanners trying bogus crap, followed by an impossibly diverse set of typos and peculiar one-off assumptions that you can’t possibly reasonably cover.

I’d easily take that over ‘200 for everything’. If at least errors are distinct from success, I’d take that as a win. My standards have been lowered by so many ‘200 for everything’ backends…

My particular project did embrace HATEOAS, just other teams did not.

For people with Linux experience, I point to sys and proc as examples of some of the best principles of “REST” in play. You can get far exploring it and if nothing else it gives you some good discoverable clues for searching what you want.

Proxmox did something similarly nice by publishing a lot of their model via a fuse filesystem.

Imitating a filesystem like interface is a useful approach, and “REST” is the closest buzzy things to get people on that page.