Resolve Bluesky DIDs to handles client-side

MusicBrainz
,
1

Not sure if I’m allowed to create feature requests on https://tickets.metabrainz.org, so I’m posting this here.

As discussed in MBS-13902, Bluesky URL relationships shown on the sidebar of an artist page only shows “Bluesky” if linked with a DID PLC (an immutable identifier, like: did:plc:er6aruerpzuu52tftoay6fyy), rather than the human-readable, changable handle (@popbot.work). Similar to YouTube “at” URLs, these handles are only shown if the URL contains the handle, as is normally shown on Bluesky (https://bsky.app/profile/popbot.work).

Since we would rather store the DID PLC in case an artist’s handle changes, but as we would rather show anything else:

but I’m not sure it’s a good idea to just show “Bluesky”

(and really, I just think it’d be nice to show the human-readable handle,)

I suggest that Bluesky links containing a DID PLC should be “reverse” resolved into its handle client-side.

Bluesky themselves have a web service for resolving DID PLCs: https://web.plc.directory, and they also provide an API for it: https://web.plc.directory/api/redoc

It doesn’t require authentication, but there are “reasonable rate-limits” (which are not detailed).

2

This should be a userscript, not part of NGS code (too much maintenance cost for an external website).

3

I think it could be a good feature to have in the core MusicBrainz website actually, unless it does turn out to be too much to maintain. would also help in those cases where a user has multiple Bluesky accounts (not too common for musicians, but artists often have alts for different kinds of art)

I know a big portion of our userbase is editors who have the power of God and Tampermonkey on their side, but I think this could be good for your average web surfer who doesn’t use userscripts

that said, it could be difficult for editors to tell whether a handle or DID URL is present without going into the edit page or mousing over the link

(to be fair tho, I don’t personally have an issue just showing “Bluesky”, as it is right now)

4

I have never heard of this external website, so I would rather like MBS dev efforts be put on any one of the core long standing MBS tickets, like highlight collection items everywhere, or the likes.

I suggested userscript because we would be dependent of that third party website code and its little changes.

1 Like
5

The API (and what it represents) should be pretty static. The only thing that comes to mind is:

Possible Future Changes

In the context of atproto, support for multiple handles for the same DID is being considered, with a single primary handle. But no final decision has been made yet.

but if that ever comes around, we’d be able to plan for it since DID PLC is open source.

@UltimateRiff Are there any dynamic frontend elements in MusicBrainz? As in, is there anything that changes based on the content of an external web service?

6

I’d love if there were a field in the database to hold the short aliases for YouTube ids, and all of these similar cases.

Client side wouldn’t be ideal for this though I think, because it would reveal what artists you look at on MusicBrainz to those other websites.

7

I know CritiqueBrainz reviews are shown several places, but that’s the only one I can think of offhand (and is only barely an external web service, lol)