This is a draft specification for the implementation of a kind of ATProto universal profile service. Developed during discussion with and .

Assumption: For now we'll assume that the service is scoped under atmosphere.onl for lexicon / hosting purposes. This might change

tl;dr:

  • Create a universal profile "intermediate representation" lexicon where all fields are optional

  • Create panproto lenses that map from all kinds of app specific profiles to this intermediate profile.

    • This allows us to convert registered app's profile to any other registered app's profile, while still only maintaining one lens per participating app.

  • The intermediate representation can be used by apps that haven't registered a lens for their own lexicon.

  • The service allows you to list all of a user's profiles, auto-translated to any supported lexicon that you request.

  • Apps can now use this to show a list of possible profiles to import to your app-specific profile as just a quick starter profile / import, without that app having to do anything to support any registered profile lexicons.

Target User Experiences

To start will focus on target user experiences and how they will be implemented.

Set My Profile In a New App

Situation: I login to an ATProto app and I want to set up my profile.

  1. 1.

    I go to wherever the profile configuration is in the app. Maybe this is when I first signed in and the app is asking me to configure my profile as part of onboarding.

  2. 2.

    The user is presented with all the profiles that they have on other ATProto apps, but adjusted to show only the information supported in this app, possibly as a profile card.

  3. 3.

    I am able to select a profile card to use as a base, and then customize the profile, if desired, for this particular application.

Configure a Universal Default Profile

Situation: I want a centralized place I can manage all my profiles, and set a "default" profile that I can use in anything supporting the profile service.

  1. 1.

    I go to atmosphere.onl and login and it shows me all the profiles that I have across all applications.

  2. 2.

    I can click on any profile and edit it, which will update that profile in the corresponding app.

  3. 3.

    I can also create a new "generic" atmosphere.onl profile that lets me set almost any kind of profile settings that is possible, and will automatically be translatable into any supported lexicons.

  4. 4.

    Later when setting my profile in other apps, I'm able to select my atmosphere.onl profile as a base, so I can use it as a universal default profile.

Universal Profile Endpoint

Situation: I'm making an ATProto app and I want to be able to fetch the user's profile, but I'm not really interested in providing an app-specific profile. I just want a sensible way to get their profile without being Bluesky specific.

  1. 1.

    My app can fetch the user's profile from atmosphere.onl, and it will infer a sensible default.

    1. 1.

      The user's default atmosphere.onl if they have specified one.

    2. 2.

      A deterministic ( yet currently unspecified ) existing profile from another app, automatically converted to a atmosphere.onl profile lexicon, or another supported lexicon of the app's choice.

  2. 2.

    For example, my app can request a profile in the Bluesky profile lexicon format from atmosphere.onl for a user, and receive a valid profile, even if that user only ever has a Roomy or Tangled account, and doesn't have a Bluesky profile. Normie will detect the profile that the user has, and return that with an automatic conversion.

Implementation Notes

Service Complexity and Features

I think that we should start off by making the service as simple as possible, and avoid any state, other than possibly some simple caching.

This will allow the service to be easily self-hosted, and allow us to reasonably provide a public instance for free.

That means that the service will not index profiles across the network. We don't want to have to build a database of all profiles across the entire network. We can just fetch the profiles directly from the PDS like pdsls.dev when the API requests them.

Multiple Profiles Per App

I think most if not all apps generally use the self rkey for the profile record. Some apps like Roomy might allow you to have different profiles for different chat spaces that you join, so there may be more than one profile in the same collection.

The server should resolve all the profiles regardless of the rkey.

API Endpoints

xrpc/onl.atmosphere.getProfile

This will resolve to the user's default profile.

Determining the Default Profile

The default profile can be set through the atmosphere.onl app, or it will be inferred by some mechanism which is undefined, other than that it must return the same profile deterministically for multiple request. This doesn't need to remain stable across versions of the service.

Query Parameters

  • did: The DID of the user to resolve the profile for.

  • lexicon (optional): The lexicon to convert the profile to. If not specified it will use the onl.atmosphere.profile lexicon. If specified, it will use any lenses available to convert the profile to the requested lexicon. It will error if the requested lexicon is not supported.

xrpc/onl.atmosphere.getProfiles

This will return the full list of user profiles that can be found across any app lexicon.

This can be used by apps for the "Set My Profile In a New App".

Query Parameters

  • did: The DID of the user to resolve the profile for.

  • lexicon (optional): The lexicon to convert the profiles to. If not specified it will use the onl.atmosphere.profile lexicon. If specified, it will use any lenses available to convert the profiles to the requested lexicon. It will error if the requested lexicon is not supported.