lexicon.community
Replies: 5 comments 8 replies
-
|
By the way, the |
Beta Was this translation helpful? Give feedback.
-
|
Here are some examples of records using the proposed Lexicon to help illustrate: |
Beta Was this translation helpful? Give feedback.
-
|
Note for posterity: I had decided to switch from the |
Beta Was this translation helpful? Give feedback.
-
|
Account profiles are an interesting use case. They represent common elements like display name, description, and avatar, but how and where they are used is very specific to the applications that create them. They also don't imply that information should be shared or used outside of the application. I suspect that my frontpage.fyi profile would be different from my bsky.app profile, and same for smokesignal.events. I think it'd be useful to have someone from Bluesky Social to weigh in and give some context around how they landed "self" in |
Beta Was this translation helpful? Give feedback.
-
|
The intended behavior is that the |
Beta Was this translation helpful? Give feedback.
-
|
Hello! I had a chat with folks in my community about this proposal, and here's some thoughts we have. You can see the live discussion in this video. This is our first time contributing to an effort like this, and we hope this feedback matches what you're looking for 🤞
...and this is all for now! Thanks for this initiative, very happy to see it! We'll also be looking at the social graph proposal soon :D |
Beta Was this translation helpful? Give feedback.
-
Thank you for your response, I'll be considering all this when drafting the PR soon! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reply! My main concern with having only a single description of even 300 characters and only a single banner, is that it overall forces most implementation of services based on AtProto to have a similar shape (unless they want additional complexity), which artificially limits the ability to create different experiences. It also complicates my life as a user. I believe that being too prescriptive here is going to not only make things harder for future extensibility (which I'm fairly confident will emerge as a need regardless of current choice), but also do me a disservice as a member of the ecosystem. Let me make an example that I hope illustrates. Imagine that I'm a fanworks fandom user, and the sites that I use most of all in the ATMosphere are "reimplementations" of two of my favorite sites: AO3 and Dreamwidth. Both of these sites allow (by design) very rich profile description experiences. Now, I go signup for those sites and given that the short description I have in my profile isn't enough for expressing myself in these spaces I go and write up a new description on both sites, which ends up in their respective Lexicons. This has already impacted my experience because, since these sites have made the choice to give me a different (and still valid!) experience, I had to go and put the same description in two different places. Now, I want to go and change my description. Because this information is saved in different Lexicons, instead of doing so in a single place like I could with the 300 characters description in my profile, I must go and remember all the sites that accept a longer description, maybe in a slightly different format (cause they had nothing to standardize on), and input it manually. Once again, my experience is impacted because of an "arbitrary" choice. With a system that allowed me to set descriptions of different lengths, I could have edited my "long-form description" and have it propagated. This is what people whose "everyday sites" are 300-characters-shaped experiences ((Edit: I can make a similar argument as these for the banners. As someone who currently maintains 5 different social accounts on 4 different social sites and often has to change them for specific initiatives or because of sales and events "you can go to each site and redo the whole process so you can adapt it to how the site wants it to look" feels like a non-solution that will once again artificially constraint the shape of ATMosphere sites.)) |
Beta Was this translation helpful? Give feedback.
-
|
@essential-randomness - Your points about not constraining the ecosystem to a single format really resonated. Would approaching this with predefined formats instead of arbitrary lengths address your concerns? e.g., for narratives support, ~3 different formats:
and for banners, maybe something like:
Services could then choose which formats they support, and users could provide content in multiple formats. Something like... {
"lexicon": 1,
"id": "community.lexicon.actor.profile",
"description": "A declaration of an AT Protocol account profile with support for multiple content formats",
"defs": {
"main": {
"type": "record",
"record": {
"type": "object",
"properties": {
"displayName": {
"type": "string",
"maxGraphemes": 64,
"maxLength": 640
},
"narratives": {
"type": "array",
"items": {
"type": "ref",
"ref": "#narrativeContent"
},
"maxLength": 3
},
"banners": {
"type": "array",
"items": {
"type": "ref",
"ref": "#bannerImage"
},
"maxLength": 3
},
"avatar": {
"type": "blob",
"accept": ["image/*"],
"maxSize": 1000000
}
}
}
},
"narrativeContent": {
"type": "object",
"properties": {
"format": {
"type": "string",
"enum": ["compact", "standard", "extended"]
},
"text": {
"type": "string",
"description": "Profile description text in the specified format",
"maxGraphemes": {
"$ref": "#formatLengths"
}
},
"facets": {
"type": "array",
"items": {
"type": "ref",
"ref": "app.bsky.richtext.facet"
}
}
}
},
"bannerImage": {
"type": "object",
"properties": {
"format": {
"type": "string",
"enum": ["compact", "wide", "square"],
"description": "Banner format - compact (16:9), wide (21:9), square (1:1)"
},
"image": {
"type": "blob",
"accept": ["image/*"],
"maxSize": 2000000
},
"alt": {
"type": "string",
"maxLength": 300
},
"focalPoint": {
"type": "object",
"properties": {
"x": {
"type": "number",
"minimum": 0,
"maximum": 1
},
"y": {
"type": "number",
"minimum": 0,
"maximum": 1
}
}
}
}
},
"formatLengths": {
"type": "integer",
"default": 300,
"enum": [
300, // compact
1000, // standard
5000 // extended
]
}
}
} |
Beta Was this translation helpful? Give feedback.
-
Thank you so much :) I often worry most developers won't care as much about this as they tend to be better served by restrictive formats than my community.
I think so! In general, making this an array rather than a single field would already be more future proof and allow to create multiple descriptions that can be reused across sites. The other point of contention beyond length would be what type of formatting will be allowed. We already have a discussion on the difficulties there in #22! I have mixed feelings on pre-determined lengths/ratios, but I think in general that would be a good thing to provide. There should probably be support for arbitrary one, but they could serve as hint for "these are generally what we suggest to pre-fill in the ecosystem". |
Beta Was this translation helpful? Give feedback.
-
|
Image aspect ratio, resolution, etc are interesting! And definitely not limited to profile pictures and banners. I wonder if we should split that out into a separate lexicon that profiles, posts, etc could eventually reuse? Also, HTML's |
Beta Was this translation helpful? Give feedback.
-
|
Please note that due to protocol specifications, multiple schemas cannot be directly linked to one collection. The FYI, followings are some alternatives that I can think of. Details
Refer to the same information from multiple servicesOnly generic information (base profile) is defined, and other information is defined in the collection for each service. {
"lexicon": 1,
"id": "community.lexicon.actor.profile",
"defs": {
"main": {
"type": "record",
"key": "literal:self",
"record": {
"type": "object",
"properties": {
"displayName": { "type": "string" }
}
}
}
}
}The service can be explicitly referenced from the record or automatically mixed in with the API. {
"lexicon": 1,
"id": "example.service.profile",
"defs": {
"main": {
"type": "record",
"key": "literal:self",
"record": {
"type": "object",
"properties": {
"importFrom" : {
"type": "string",
"format": "at-uri"
},
"serviceInfo": { "type": "string" }
}
}
}
}
}There is also a way to separate records by field to show partial references. Commonize the structure of the profileAllow the content to be defferent for each service, and if you want to unify only the type, define the type for the field, not the record. {
"lexicon": 1,
"id": "community.lexicon.actor.profile",
"defs": {
"main": {
"type": "object",
"properties": {
"displayName": { "type": "string" }
}
}
}
}The profile record of each service refers to this. {
"lexicon": 1,
"id": "example.service.profile",
"defs": {
"main": {
"type": "record",
"key": "literal:self",
"record": {
"type": "object",
"properties": {
"genericProfile" : {
"type": "ref",
"ref": "community.lexicon.actor.profile"
},
"serviceInfo": { "type": "string" }
}
}
}
}
}Collect profiles in one collectionIn contrast to the previous one, refer to the object definition of each service. Please note that {
"lexicon": 1,
"id": "community.lexicon.actor.profile",
"defs": {
"main": {
"type": "record",
"key": "nsid",
"record": {
"type": "object",
"required": ["body"],
"properties": {
"body": { "type": "union", "refs": ["#generic"] }
}
}
},
"generic": {
"type": "object",
"properties": {
"displayName": { "type": "string" }
}
}
}
}The service defines the object to be referenced to this record and creates an {
"lexicon": 1,
"id": "example.service.profile",
"defs": {
"main": {
"type": "object",
"properties": {
"generic" : {
"type": "string",
"format": "nsid",
"default": "community.lexicon.actor.profile"
},
"serviceInfo": { "type": "string" }
}
}
}
}List the profileIf you want to make a collection to make it easier to discover profiles for other services, simply collecting references may be enough. {
"lexicon": 1,
"id": "community.lexicon.actor.profile",
"defs": {
"main": {
"type": "record",
"key": "literal:self",
"record": {
"type": "object",
"properties": {
"profiles": {
"type": "array",
"items": { "type": "string", "format": "at-uri" }
}
}
}
}
}
}There are few uses for such references, but they may be meaningful for services that refer to records from any service. For example, AT Profile has a field that declares the collection to be imported, which is similar to this. |
Beta Was this translation helpful? Give feedback.
-
|
In my opinion, while other lexicon.community proposals provide useful options for developers, this discussion is trying to build a more universal mechanism. This is a respectable job, but as already discussed, it will be very difficult to find a universal profile schema. It's hard for me to discuss the schemas that should be, so this is just a list of possible options on the Lexicon system rather than a recommendation. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Intent and Rationale
Within a social graph, users have personal information they want to be able to manage and present to others. The most popular Lexicon namespace,
app.bsky, contains a record type for describing a user's social profile on Bluesky. Other AT Protocol services have adopted a variety of methods for managing user profiles, including:Intended Use
This Lexicon aims to bring consistency to profile behavior by allowing a user to declare their profile information independent of any service, override their generic profile for specific ATProto services, and declare service-specific profile information.
The new record type
community.lexicon.actor.profilewill be defined and primarily defined with rkeycom.atprototo declare a user's profile to be used in the absence of applicable service-specific profile records. Service-specific profile records should use their service's NSID (the service's homepage as a reverse-URI) as the rkey, and inherit all object properties from the generic profile record Lexicon. Services are free to define and store additional properties in their profiles.Care should be taken to ensure user interfaces appropriately inform the user of the difference between the generic profile and the service-specific profile, especially when editing the profile information.
Lexicon
Generic profile (rkey
com.atproto){ "lexicon": 1, "id": "community.lexicon.actor.profile", "defs": { "main": { "type": "record", "description": "A declaration of an AT Protocol account profile.", "key": "literal:com.atproto", "record": { "type": "object", "properties": { "displayName": { "type": "string", "maxGraphemes": 64, "maxLength": 640 }, "description": { "type": "string", "description": "Free-form profile description text.", "maxGraphemes": 256, "maxLength": 2560 }, "avatar": { "type": "blob", "description": "Small image to be displayed next to posts from account. AKA, 'profile picture'", "accept": ["image/png", "image/jpeg"], "maxSize": 1000000 }, "banner": { "type": "blob", "description": "Larger horizontal image to display behind profile view." "accept": ["image/png", "image/jpeg"], "maxSize": 1000000 } } } } } }Bluesky profile (rkey
app.bsky){ "lexicon": 1, "id": "community.lexicon.actor.profile", "defs": { "main": { "type": "record", "description": "A declaration of a Bluesky account profile.", "key": "literal:app.bsky", "record": { "type": "object", "properties": { "joinedViaStarterPack": { "type": "ref", "ref": "com.atproto.repo.strongRef" }, "pinnedPost": { "type": "ref", "ref": "com.atproto.repo.strongRef" } } } } } }Smoke Signal profile (rkey
events.smokesignal){ "lexicon": 1, "id": "community.lexicon.actor.profile", "defs": { "main": { "type": "record", "description": "A declaration of a Smoke Signal account profile.", "key": "literal:events.smokesignal", "record": { "type": "object", "properties": { "tz": { "type": "string", "description": "The time zone of the profile (e.g. 'America/New_York')." } } } } } }Beta Was this translation helpful? Give feedback.
All reactions