Yeah this is something that is not standardized yet, so I only use it if it exists (otherwise, I fall back to the domain of the webId or the url they introduced). But this is being looked into, so it may become part of the spec eventually. If you want more info about it, check out this repo: solid/webid-profile.
It uses two libraries at the moment: @inrupt/solid-client-authn-browser (the default one) and solid-auth-client (legacy). The reason why I’m using two is that Inrupt’s library is not compatible with some old servers, so I’m keeping both for backwards compatibility.
However, all the logic about what url to use for log in is in a different package: @noeldemartin/solid-utils.
Yeah, I agree with that and I would prefer to follow a best practice if there was any. I do prefer “Log in with Solid” for my apps, but if as a community we settle on a best practice to say “Connect with Solid” or whatever, I wouldn’t mind changing my apps to conform.
Something I’m conflicted about though is suggesting any pod providers. One of the reasons why I like Solid is the decentralized aspect, so I don’t want to reinforce using any particular provider. At the same time, we know most people will use a handful of providers because these things follow a Power law distribution, so it would result in better UX.
Another huge issue is where to point users who don’t have an account. Right now I am pointing them to the get a POD page on solidproject.org, but there’s a lot of things I don’t like about it. Right now I’m not focusing my efforts on onboarding users who don’t have a POD already, but if I were there’s a lot of things I’d probably change. @jaxoncreed wrote a post a while ago that touches on the topic, and there were some nice ideas in there: The Full Complexity of On-boarding with Solid.