app.bsky.actor.profile vs app.bsky.feed.generator lexicons

[snarfed]

Hi again! Minor question: app.bsky.actor.profile and app.bsky.feed.generator seem to overlap a lot, they're both effectively profiles, and the only notable differences seem to be banner in app.bsky.actor.profile and acceptsInteractions and descriptionFacets in app.bsky.feed.generator.

I'm working on code that auto-links URLs and domains in profiles. Is the lack of facets in profiles (vs generators) intentional? Should these lexicons eventually be unified? Anything else I should think about here?

Thanks in advance!

[bnewbold]

They are distinct, in that they mean different things: a Bluesky microblogging account gets a profile, while a feed generator gets a feed gen declaration record. I would guess they will probably evolve in different ways over time.

The profile record probably should (and probably will) eventually get description facets; the facet system didn't exist when that record type was first specified. There is some real developer friction around the profile not having facets already. The facet system is abstracted and can be shared across lexicons.

I don't think that a feed gen will get a banner image any time soon, but could be wrong.

It is interesting how similar they are, and there is certainly temptation to create abstractions around that. IIRC list definitions and labeler declarations are also pretty similar. Maybe we could end up with a concept like "traits" around Lexicons that all have a common subset of fields. But for now there is no explicit commonality at the protocol level, and we have no intention to "merge" these concepts.

[snarfed]

Thanks! Sounds good. I get that they're different things; I was originally curious about feed generators having facets while profiles don't, which I figured was just legacy baggage, as you mention.

The overlap is still interesting, makes me wonder if they could eventually consolidate that, eg feed generators could switch to including a app.bsky.actor.profile ref field, but obviously low priority and would require a back compat migration. No matter!