A community app lexicon

Lexicon Community
41

I really like the idea of type/domain, tho Im sure wrangling the exact words to use there will be a project.

I think differentiating between clients and tools is important, since I see a world where we start building more and more apps that don’t really have anything to do with Bluesky at all.

My one note is that “domain” or “category” or “tags” or whatever should absolutely not be constrained to an enum, predefined list. Let a thousand tags bloom, or else we get a thousand listing as “other”.

@pixeline.be and @dame.is, lets kick together a rough lexicon that meets in the middle. I’ll try and start publishing records in that shape this week.

Oh, and the oAuth client id idea is somethng the Solid community thought of too – thats a good idea that I will be supporting.

2 Likes
42

I’m excited about Alternative_to! Regardless of whether it should be included in the initial set, I would like this lexicon to support it in the future.

I just researched it personally recently. (the link is in Japanese)

https://chatgpt.com/s/69a8cfb96ed48191aee1753354de2f1f

As for your proposal, from the experience of seeing a lot of services, although the type is useful, it can be difficult to classify it well.

  • Is an app like blahg that self-hosts for each user a service? (it may be a tool)
  • Is WhiteWind a Bluesky client? (partially yes)
  • Is this forum included in atproto services? (probably not)

In my opinion, it may be enough to include these in tag.

1 Like
43

Someone want to take a stab at making this into a WG per the original post? I don’t have the bandwidth right now to lead or make big moves/pushes (phd is requiring more focus), so hoping someone else can get interested folks organized to make this happen.

1 Like
44

Incidentally, I work for an ASO company so store taxonomies are indeed quite a challenge.
We maintain a database of all categories used in both the iOS and Play Stores, and our data science team built a finer classification layer (“appDNA”) based on large-scale app metadata. It groups apps using underlying signals and tends to perform much better at clustering apps by actual user intent.

One consistent takeaway from this work: trying to define an exhaustive, fixed taxonomy indeed doesn’t scale.

So with that in mind, I don’t think the goal of this lexicon should be to enumerate all possible types and domains. That will quickly become either too complex or too generic.

Instead, it might be more effective to bake into this lexicon a smaller set of signals (and/or “features”, as in atproto.garden) that describe what an app does and how it behaves.

From those signals, different consumers can derive their own groupings depending on their needs:

  • user-facing directories → “Photos apps”, “Messaging apps”
  • developer views → “feed builders”, “repo tools”
  • analytics / discovery → clustering based on usage patterns

Rather than hardcoding categories, each app could expose things like:

  • capabilities (posting, publishing, messaging, etc.)
  • protocol interactions (feeds, repos, firehose, identity, etc.)
  • surface type (client, service, tool, etc.)

Then “categories” become a view, not the source of truth. We could even have an optional tech_stack entry listing the tech related to the app (interesting for finding developers)

That said, I don’t think this contradicts having a minimal set of high-level fields like Type or Domain. Those are useful as human-readable entry points, but they shouldn’t be the foundation of the lexicon. The foundation should be these lower-level signals, from which higher-level groupings can be derived.

I’m very interested in collaborating on a minimal version of this.
I can also share my current dataset (~75 apps) to test different approaches against something real.

Also +1 on the “garden” framing — it fits well with the idea of something that grows organically rather than being strictly defined upfront.

also a last thought: we could probably also do an analysis of what schema.org for apps SoftwareApplication - Schema.org Type can teach us

2 Likes
45

Really wish I had known this existed before I finished and published AlternativeProto! Though my app does specifically aim to list alternatives to existing non-atproto apps, not just atproto apps in general, and the lexicon reflects that. Nonetheless I’d be happy to switch and just do the “alternative to” thing using a sort of sidecar record.

2 Likes
46

Ha sorry I didn’t catch you before you worked on it! But I think it’s good to have folks who have actually built these things out already, gives a better framing for the minimal set for community lexicons.

And given I have almost 200+ apps (apps, not even including tools) in my semble collection, a central lexicon hub developers can submit to will be useful - even if others want to expand with more detail for their own use cases.

1 Like
47

Wow, that’s crazy. :astonished_face:

48

This thread has surfaced a lot of good perspectives and directions.

A possible next step would be to start moving from discussion into action. What do you think about the working group template shared by @bmann.ca in the initial post ? Should we set up a WG to design a community “App” lexicon ? Personally, I’m in!

3 Likes
49

Yup I think this is the next reasonable step! I’d be happy to be involved w the WG but can’t commit to lead on either front (comms or WG lead).

@bmann.ca do we just work on that in here and when we come to a consensus set a new thread? The template explains what to fill in / setup but not if there’s how/where to work/establish a filled-in template.

2 Likes
50

Thanks for digging in!

I think I can be your TSC point of contact while I’m still on it :wink: basically I bug the lead for updates once a month.

Theoretically everyone is in Vancouver next week and could talk live too.

I’d say make a new thread posting the template in. I can turn on wiki mode so y’all can group edit.

We can make a dedicated category here if you want, eg like Lexicon Community > Community Lexicon Calendar

51

I’ve started working on a lexicon proposal based on this discussion. Would this work as NSID: community.lexicon.app.entry or directly community.lexicon.app ?

For now, i went ahead with the former pixeline.be/community.lexicon.app.entry at main

2 Likes
52

I don’t have a ton strong focus for this with my attention dedicated to Roomy & the conference at the moment, but I do want to get a little more involved in some ATProto stuff and will give some best effort involvement.

1 Like
53

Hmm, it feels maybe best to have it scoped so that it could be alongside other record types like app.collection or something like that.

1 Like
54

yes, my thoughts exactly ( app.review)

55

It would be nice if this lexicon could also embed information about what kind of records under a collection has a special page for it. For example, BlueSky clients handle profiles and posts by their own lexicons. Events have their own pages. This could be used to have very simple to implement redirectors like aturi.to or eventsl.ink