De-duping bridges: profile links? alsoKnownAs?

[snarfed]

So, I've been thinking about de-duping bridged accounts. There are a number of bridges between networks out there, which results in multiple bridged accounts for the same original user. For example, my web site https://snarfed.org/ is currently bridged into the fediverse as both @snarfed.org@snarfed.org (by Bridgy Fed) and @snarfed.org@rss-parrot.net (by RSS Parrot).

Profile links, ie "this is my web site, this is my bandcamp, etc," could be part of an answer. If an ActivityPub <=> ATProto bridge detects a fediverse link in a Bluesky profile, it could infer that that user already has a fediverse presence, and may not want another, so it could ignore them and not bridge them. Bluesky profiles don't currently have user-provided links, but I'm sure the idea has been discussed before. What's the current status and thinking? (Related: #1227, #1652)

There are more formal mechanisms too: FEP-fffd for ActivityPub, rel=me for web sites, NIP-39 for Nostr.

Is alsoKnownAs in the DID document the ATProto equivalent? Should I consider that?

More discussion: snarfed/bridgy-fed#800

[bnewbold]

Adding profile web links is something we'd like to do, and should not be too much of a lift, but our dev pipeline is very full for the next month or two.

Fediverse account syntax, with the double-@, is fairly distinctive, so using a regex to parse that out of free-form bluesky profile description should be reasonably reliable?

[snarfed]

Glad to hear it! And yeah identifying fediverse handles specifically is doable, that's a good heuristic for now. Other networks are harder to get out of profile description: web sites aren't really deterministic, Nostr npubs are awkward and NIP-05 domains are similarly non-deterministic, etc.

Can you think of anything wrong with using DID alsoKnownAs? The main drawback I see is that it's not easily user-editable; not sure if there are any others.

[bnewbold]

things to consider with alsoKnownAs:

• at least for DID PLC, the identity metadata is public, permanent, and can't be redacted. this makes the privacy and PII stakes pretty high, and I would personally try to keep real-world metadata out of there if there is an option. that being said, the handle is obviously already in there, and it does kind of align with DID usage generally
• it'll need to be in URI format. that would probably mean an http:// URL, though keep in mind there might not be a clear way to know that you are looking at a fediverse account handle vs. a generic website URL
• DID docs don't get hydrated in to things like profile views, at least for now, and are not as easy to edit within atproto (aka, CLI or similar)

from a product standpoint, if you are trying to avoid creating dupe bridge accounts, consider that that you can probably do a search query on profiles (using the existing searchProfile endpoint) with the handle (or some minimal transform of the handle, like the username and domain name as separate tokens) to quickly find any accounts with that username already in the profile.

[snarfed]

Thanks!

• DID docs don't get hydrated in to things like profile views, at least for now, and are not as easy to edit within atproto (aka, CLI or similar)

Yeah this seems like the kicker so far. Unfortunate...but this is way too esoteric and niche a use case to change that. 🤷

consider that that you can probably do a search query on profiles (using the existing searchProfile endpoint) with the handle (or some minimal transform of the handle, like the username and domain name as separate tokens) to quickly find any accounts with that username already in the profile

True! That works for manual or semi-automated workflows, but it's probably not deterministic enough to use fully automated. Still useful though!