I think this will be difficult to understand at a glance how I'd display an error to the user.

Here's an alternative structure that just tweaks the names a bit and adds examples, but could help:

typeResponsestruct {// An actionable message that depicts actions the request took. Examples:// - "A user has been created."// - "Failed to create a user."Messagestring`json:"message"`// A debug message that provides further insight into why the action failed.// - "database: too many open connections"// - "stat: too many open files"Detailstring`json:"detail"`}

I don't know what to nameErrors. since it's form-specific I'd lean towardsValidations maybe?

I'm curious for your take@presleyp, you're a magician with words! 🪄

@Kira-Pilot suggestedVerbose instead ofInternal and I like that;Detail works too.

I likeValidations better thanErrors - more specific! Right now I feel like it requires an explanatory comment on the frontend.

But I know@Emyrk doesn't want this PR to be open for long, maybe these tweaks can be a followup.

I can change that now, that's easy with IDE tools

question: what allowed us to make this change? Does it mean that we no longer send those randomMessage errors on forbidden routes?

@vapurrmaid for security reasons all forbidden messages should be identical. If they were different, then the different errors allow the end user to gain information.

There is a line of "security" vs "usability" that we will need to decide on these endpoints. As it's unhelpful by design.