Consider moving from `/.well-known/identity` to simply `/.identity`

[csuwildcat]

@TelegramSam this may be a good option to entirely avoid the rigidness and controversy over 'abusing' /.well-known, as defined by its maintainers/creators.

This is shorter, and doesn't tread on some standard that is close-but-not-quite what we want.

[csuwildcat]

@thedoctor curious to get your opinion on this as well

[thedoctor]

Well, I either don't correctly understand the purpose of RFC-5785 or I think it's dumb, so I'm totally behind the suggestion to not use /.well-known.

While we're discussing it, what exactly would /.identity be relative to? Does it have to follow the URI host or can it appear anywhere in the URI path? Does it matter? Are all valid hub URIs of the form: [scheme]://[host]/[maybe-sub-paths]/.identity/matt-or-whomever.id/?

I honestly don't understand the utility of having a URI-path prefix at all.

[csuwildcat]

The goal is to have the entire URL path composable in the same way across any URI base - this delivers a few benefits:

• Immediately recognizable URLs that become recognizable as part of the same, cohesive system
  • Devs: known immediately what they are working with and how to handle them
  • Users: at some point, these may reach ubiquity, and users will begin to form behavioral memory to know what is going to happen when they encounter these URLs
  • Browsers: without performing additional logic, a browser could add special UI/handling to how they display or handle these special URLs
• No need for any mapping files or intermediary resolution to discover the actual URL
• Lesser, but still important: developer branding for the project baked right into the REST interface

The primary concern was that the folks who created /.well-known didn't intend to have the paths be anything but simple, one route deep, flat metadata, vs a full API. I am happy to oblige them by 'getting off their lawn' with a much shorter and specific prefix that does the job.

[thedoctor]

So I think the issue with the well-known folks not wanting their namespace used for unintended means illustrates the crux of my problem with this kind of system: it's opt-in and the semantic meaning of the prefix is unenforceable. Worse, it's a pretty natural developer inclination to hack new behavior on top of existing, somewhat-related systems, so it was inevitable that eventually someone (us) started (mis-)using /.well-known for something it's not meant to do. Worse still, developers don't actually know immediately what they're working with –– they just think they do, and that leads to bad engineers writing vulnerable code with untrue assumptions.

Sorry for the rant, I'm not trying to get into an argument about it; it's perfectly fine with me if we use a prefix by convention as long as our code never assumes that a URI starting with /.identity must actually be an identity hub, and handles non-standard behavior robustly.

Is the prefix in use anywhere else besides the hub spec? If not, why not choose something even shorter? /.hub/?

[csuwildcat]

The differences here are these:

• Well Known was intended to be extended, but only by things that fit in their cookie cutter vision of what it was intended
• If we picked a reserved path scheme for our own stuff outside of /.well-known we aren't dealing with the same constraints
• Our code would handle requests in accordance with the Hub spec, regardless of what someone else tries to do with it (which is unlikely, but our Hubs would just reject it anyway)
• I'd prefer /.identity, because /.hub is a super generic term that doesn't tell you what the path revolves around

[csuwildcat]

Given the shorter, non-IETF-encumbered, well-recognized pathing option is better than tangling with something that was not intended for our purpose, I am going to change it in the explainer, and we can talk about the broader issue more as time goes on.

[thedoctor]

Cool with me.

[csuwildcat]

Modified in Explainer