Will user search/discovery in clients ever trigger handle resolution?

[snarfed]

Hi all! Looking at how people find and follow users in https://bsky.app/ 's search, I see a few requests to bsky.social (PDS) and search.bsky.social:

• bsky.social:
  • app.bsky.actor.searchActorsTypeahead
  • app.bsky.actor.getProfile
  • app.bsky.actor.getProfiles
• search.bsky.social/search/profiles

...but not resolveHandle. Do you all expect that clients will ever call that during discovery UX flows, eg when they press enter in the search box? Or that PDSes/AppViews will ever do it as a fallback in getProfile[s] when the input handle or actor isn't found?

My use case is on-demand profiles. I'd like users to be able to discover profiles that are generated dynamically, on the fly, as opposed to only profiles that have already been indexed in the AppView. Specifically, when a PDS or AppView does HTTPS handle resolution on eg user.com.brid.gy, I plan to create a new did:plc, repo, and user profile commit synchronously, then return its DID. This will only work if clients call resolveHandle or PDSes/AppViews fall back to it in search, though.

(I know there would be subscribeRepos propagation delay from my PDS => BGS => AppView. If we end up with that as the only difficulty, I'll count it as a win. 😁)

[bnewbold]

Kind of a tricky question because we can't really control what clients/apps will decide to do! Also external services. Definitely services are constantly doing both handle and DID resolutions, both when new identities are notices, and check for updates to known identities (aka, cache refreshes). Right now the only time I write code that actually calls resolveHandle is CLI tools for debugging.

I haven't thought this all through, but does your setup get easier if you use did:web instead of did:plc? then you are getting both the handle and DID resolutions as HTTP requests. did:web is more ephemeral (no external resource/request to serve them), which could fit the virtual bridge use-case well.

[snarfed]

Thanks! I don't think did:web vs did:plc changes my use case much. The key point is that I want to be able create accounts on demand, not ahead of time.

Specifically, when a Bluesky user searches on bsky.app for eg user.instance.ap.brid.gy - the bridged handle of arbitrary fediverse user @user@instance, which won't have an ATProto repo or profile record yet - I'm hoping to receive a handle resolution request for https://user.instance.ap.brid.gy/.well-known/atproto-did, create a repo and profile record (and possibly did:plc), and then serve the DID in response. Or something similar.

This is what Bridgy Fed already does to surface web sites into the fediverse on demand. The key point is that fediverse implementations generally do WebFinger resolution/discovery when you enter eg @user@instance into their search. Is there any way to get bsky.app or the AppView to do the equivalent?

[bnewbold]

ah, I see. yeah, that is not how things work today: the search simply goes against an index of known repositories, we don't special-case it. Even with federation we have been thinking that accounts will either get pushed to BGS, or detected and spidered via graph interactions.

I can see how doing a resolution when a specific handle or DID might make sense, but that is not how things are set up currently, and I haven't really thought that through.

[snarfed]

OK! Totally understandable. As a clunky workaround, I can make people trigger bridging an account in a UI on https://fed.brid.gy/ first. Then, after a few seconds to let it propagate, hopefully they'll be able to see it in search.