AT Identities for Lexicon Community subdomains

Lexicon Community
1

We are all jealous of the branding success that is standard.site.

It would be easier to direct attention, make salient, attract contributors and developers, etc, to community lexicons if we could point to a unit of lexicons that have a consistent use case. It’s easy to say ‘hey check out standard site’ because I can tag @standard.site, send you to http://standard.site which will immediately explain what those lexicons do and are for.

Lexicon community is a great vehicle for cooperatively shaped and stewarded schemas. Currently, when presenting it to someone new, they see a bunch of seemingly unrelated lexicons that they may or may not care about, and information on governance. This is all important information! Not necessarily relevant to encouraging adoption of a particular domain. If I am making a scheduling app on atproto, I just want to know what the common lexicon to use would be. If the answer is calendar.lexicon.community, I should be able to go to that website, see a quick explainer of what the schema does, maybe even some usage stats to provide social proof, and docs on that group of schemas. No distractions, just what I need to get internecting.

How can we do this for lexicon.community? Make atproto accounts for each of the top level subdomains, as well as landing pages similar to the standard.site site.

  • @app.lexicon.community
  • @bookmarks.lexicon.community
  • @calendar.lexicon.community
  • @interaction.lexicon.community
  • @location.lexicon.community
  • @payments.lexicon.community
  • @preference.lexicon.community

Nobody needs to post to these accounts frequently, if at all. They simply provide a surface for advertising these schemas to the folks who would benefit from their usage. The docs and landing pages can be templated to require little marginal effort per additional namespace.

3 Likes
2

I think a landing page on the new https://lexicon.community (or subdomain as you suggest) as default info would be great, which I think @ngerakines.me agrees with / has planned.

And for anything beyond that, it’s up to the working group leads and members to do the work.

Ultimately — volunteers wanted! Who wants to take on comms and marketing and promotion for a lexicon working group? Who wants to gather the content for those landing pages and curate them?

I think we’ve got a real strength in events adoption – but the Calendar Events WG Lexicon Community > Community Lexicon Calendar needs rebooting, as there is definitely experience on a few pieces of new data that could be included in the base. I think, technically, there aren’t people leading it at the moment?

(this is on me, where several people said they wanted to extend the lexicon, I made the category, but I think we didn’t have people who were prepared to lead the group…or maybe not know how to propose extending the lexicon)

1 Like
3

P.S. not at all “jealous of standard site” - they put in the time and did the work!

We also realized that event adoption / interop got to a similar spot organically. Could it better?

Yeah! Nick did all the hard work initially, got to interop, and is moving on from Smoke Signal to other things.

The lesson is: recruit people to lead the work, it needs a repeated cadence of messaging, updates, outreach, and support.

If no one is leading the work, it will not get done.

1 Like
4

Yeah, I wouldn’t go so far as to use the word jealous.

I’m not against NSIDs having their own identities, but I don’t think it’s necessary yet. Currently the most used NSID is the lexicon community calendar, and even it doesn’t have enough “activity” to warrant its own social identity or website.

Open to it in the future though.

5

I don’t mean to convey any sort of animosity, only as a hook at the beginning of post :winking_face_with_tongue:. Stansite is a model of success in collaborative lexicon. I wish to see similar adoption and success for LC schemas. Calendar certainly has the most promise so far. I would posit that theres chicken and egg phenomenon when it comes to widespread adoption. We want more folks to use them no? And out of more usage more validated use cases for which to evolve the schemas.

1 Like