Profile background image lexicon

mx.mt · April 8, 2026, 12:42pm

Hiya, I’m designing an iOS Bluesky client and I want to allow people to set a background image on their feed/profile page that would be visible to other users of the client (and hopefully other clients). I don’t believe there’s an existing lexicon in use for it, or at least I wasn’t able to find one, so I’ve made a GitHub issue on Profile background image lexicon · Issue #74 · lexicon-community/lexicon · GitHub with a vague proposal, but I’m curious for input or if there happen to be any existing ‘supplementary profile image’ lexicons that I’ve missed.

bmann.ca · April 9, 2026, 4:15am

Heya welcome!

There isn’t a community lexicon for profiles yet — and there has been some reluctance to do one by some, and others REALLY WANT ONE BIG PROFILE that everyone agrees to use.

Using the community lexicon namespace — eG community.lexicon.profile.background or similar should have some other people weigh in.

Or, you can just use your own since you’re the first one to need it, and then see if others want to adopt it. So app.your.profile and you can define what you want there.

Tangled and Grain are two examples who have their own profile fields and follow graph.

felinus.fish · April 21, 2026, 5:46pm

I’m for separate profiles for each “app” with those that are accomplishing the same goals potentially using a standardized lexicon (like how standard.site and lexicon.community works)

dave.self.surf · April 23, 2026, 8:47am

Hii,

I do this on Linkna.me where I offer people gif-avatars & the option to use their own image as a background wallpaper.

Here is what I implemented, which you are welcome to fork/copy/modify.

Linkname publishes its own me.linkna record type in our own NSID namespace, stored at key: "self" in the user’s repo.

See here for the profile lexicon: me.linkna.profile - Lexicon Garden

For the background wallpaper, its stored on the me.linkna.linkinbio lexicon instead of the .profile lexicon

"backgroundImage": {
  "type": "blob",
  "accept": ["image/png", "image/jpeg", "image/webp"],
  "maxSize": 10000000
},
"backgroundImageCredit": { "type": "string", "format": "uri" }

see: me.linkna.linkinbio - Lexicon Garden

The backgroundImageCredit is intended to be used to credit the artist/creator of the image.

I would be interested in supporting something where the user only specifies their preference for background image ONCE. And when they Sign in with Bluesky, we read that and display that preference instead of the user having to upload the same background image again.

Im happy to use a community namespace for this too, if it gains adoption. For the time being I will remain in the linkname namespace but happy to interoperate with other lexicons later down the line!

dave.self.surf · April 23, 2026, 8:58am

I also support this use case on Linkname, when you Sign in with Bluesky on Linkname we get the default data from your Bluesky profile.

But under Theme → Profile, you can modify your profile image & bio and this is custom to Linkname linkinbio.

tamme.schichler.de · April 24, 2026, 9:28pm

As a user, I’d very strongly prefer being able to set this separately by app, to be honest.

Apps falling back to other apps’ records with similar intent is great for convenience, but being forced to use the same profile-anything across apps that aren’t clearly just parts of one context is a massive anti-feature to me.

dave.self.surf · April 25, 2026, 10:16am

I agree, I would see this to function like this:

You sign in with Bluesky with @Alice.com on app ABC. App ABC offers you a custom wallpaper field (namespace: community.atprotocol.background.wallpaper). You upload your favorite cat pics wallpaper.
You sign in with Bluesky with @Alice.com on app XYZ. App XYZ sees you already use the above namespace and that you have uploaded an image. App XYZ uses this image as your default profile background wallpaper.
App XYZ offers you the choice in settings to update the wallpaper image. When you do so, it gets uploaded to the com.xyz.background.wallpaper namespace, which is the default wallpaper for xyz app users. (but uses community.atprotocol.background.wallpaper as default if @Alice.com does not upload a custom one for app XYZ).

This way we would achieve:

Alice set her wallpaper once (and is default used by other apps that care).
Alice can update the wallpaper on other apps (that enable them to do so, overrides default).

Any concerns/remarks about this approach @tamme.schichler.de ? Or something I am missing you think could be done differently?

essentialrandom.bsky.social · April 26, 2026, 7:15am

This requires a different lexicon, but personally what I’d like to see is a “personal preferences" lexicon where I can save a default background to be shared by apps, as well as other backgrounds I commonly use.

If I have set a default background in my preferences, apps can use it without issues
If not, apps can present me a picker (as part of onboarding) with other backgrounds in my preferences OR backgrounds I’ve chosen in other apps they know about, if I have no preferences set.
Once I set my background, if it’s in a new one I haven’t saved before, Apps can ask me if I want to save it to my preferences/make default.
Apps can keep a pointer to the background in my preferences they derived the background from, so one can update all linked backgrounds at the same time.

IMO an easy onboarding where you offer backgrounds from another apps as a yes/no/make default choice should be low friction enough, and beats the moment a family friendly app ends up with the very inappropriate background someone had somewhere else…for both the app and the background-haver.

In general, the lexicon community background should be a shared standard to define what a background is, but it would be nice to make a default preference be a choice made explicitly rather than assumed. Especially now that people don’t conceptualize all these apps as belonging together, yet.

dave.self.surf · April 26, 2026, 5:57pm

Thanks for providing your feedback, I generally agree but here is where I push back:

easy onboarding where you offer backgrounds

easy onboarding come without offering backgrounds:

this is an app developers choice about whether the app offers “background” as a “feature” during onboarding. imo, this is not a big enough value to be part of the onboarding. I rather have apps offer this somewhere in the settings page, so that apps can onboard users with their main value prop.

You don’t signup to offprint.app to see your pre-set background image.
You signup to offprint to send emails to people / blog about your thing.

On all your other points, I agree.

Re: the lexicon:

This requires a different lexicon

Which lexicon do you think is best?

I suggested community.aprotocol.background.image but im open to use a different default. Should we maybe think about supporting three different versions, one for desktop, tablet and mobile?, maybe one (or three) for animated backgrounds?

I feel like this overbloats this and we should probably just start with one image for desktop and see from there? We can always extend/modify.