Rhonda suggested I document how to use the LLS (Launchpad Login Service — their implementation of an OpenID provider) as Delegate, which basically means, you can put something up on your webpage, which can be a simple static (X)HTML page like mine (a /index.htm is especially nice, a /~user/index.htm works too), and use its URI and not https://launchpad.net/~me to login. For example, this often hides the LLS from view e.g. in blog comments, such as those where Canonical is being criticised ☺ — but it’s also yours, easier to type and to change if you switch service providers.

The basic idea is to go to your Launchpad user page and view its page source. Look for openid relation links in the header — on Rhonda’s the value we’re looking for is “cyLQbcp”, and you see it several times.

Now you put this on your web page:

	<!-- begin: OpenID delegation to LP -->
	 <link rel="openid.server" href="https://login.launchpad.net/+openid" />
	 <link rel="openid.delegate" href="https://login.launchpad.net/+id/cyLQbcp" />
	 <link rel="openid2.provider" href="https://login.launchpad.net/+openid" />
	 <link rel="openid2.local_id" href="https://login.launchpad.net/+id/cyLQbcp" />
	<!-- end: OpenID delegation -->

Of course, insert your, not Rhonda’s, ID. Do note that we don’t copy the X-XRDS-Location tag (that breaks things for some unknown reason), but otherwise, what we insert on our page is pretty much a copy of the info on the user page (maybe it’s a Delegate page, too?).

As usual, try at your own risk, bug Canonical if it breaks. It works with AO3, Gerrit Code Review, and others though (interestingly enough, better in Lynx than GUI browsers because I stay logged in across Lynx sessions (and just have to confirm sending “my information” to the accessing site), whereas I have to re-login to the LLS in every GUI browser session).

As with the LLS generally, “to access a site which is not recognised” is expected and worked on with low urgency (mostly cosmetical, I think).