Drafting a Threads lexicon

[erlend.sh]

Continuing the discussion from Basic Metadata for Modality Spaces and..

@schlage.town

I think it’s better for standard.site to stay focused on longform blog-like content. Not that it has to be strictly blogging only, I think it’s a bit fuzzy and that’s fine, but yes I’d say something like forum threads should be a different lexicon!

This has come up before b/c it’s not super well defined and there are definitely cases where folks want to use it even where (imo) it doesn’t always make sense.

Following from this, it sounds like the best way to sketch out a common Threads lexicon is to essentially fork standard.site as a wholly separate but baseline-compatible lexicon, e.g. community.lexicon.thread

I firmly believe a unified threads-lexicon core can adequately cover both the group chat and internet forum cases interchangeably.

Each modality (synchronous vs async, fast vs slow) can still extend that core with its specialties, but the semantics and affordances of a thread in two distinct apps like Discord or Discourse are fundamentally the same:

• there’s a thread title, i.e. the label of the posts-container
• thread contains one or more posts
• posts are ordered linearly (this doesn’t exclude nesting, but that’s non-default and more specific to the forum modality)
• posts can reply to other posts
• posts can have reactions
• thread can be subscribed to
• thread was created by someone, at a specific time
• thread has a permanent URL/URI
• private/public thread access is determined by its channel/category container (space).

Prior art

Approximations of this kind of lexicon have already been drafted in

• Colibri by @lou.gg
• atmoBB by @keithkurson
• Barazo by @gui.do
• UserInput by @brookie.blog
• and in-progress for Roomy by @meri.garden @zicklag.dev @erlend.sh

Colibri

• Lexicons | Colibri Social Documentation
• social.colibri.beta.thread - Lexicon Garden

atmoBB

• https://github.com/keithk/atmoBB/blob/main/docs/lexicons.md
• https://github.com/keithk/atmoBB/tree/main/lexicons/app/atmobb/discussion

Barazo

• Barazo - forum AppView lexicons for topics, replies, and reactions
• https://github.com/singi-labs/barazo-lexicons
• https://github.com/singi-labs/barazo-lexicons/tree/main/lexicons/forum/barazo/topic

UserInput

Bit of a special case since it doesn’t intend for threads to be very discursive, but it still follows the same general discussion-container format, and there’s prior art in Discourse which we extended with a voting feature to do exactly what UserInput does.

• app.userinput.discussion - Lexicon Garden

Roomy

Roomy is/was planning to adopt lexicons as part of our pending migration to atproto spaces. Our team’s capacity is much more limited nowadays though, so the timeline for this change is uncertain.

Same thread at different speeds

The only big difference between the chat-modality of colibri/roomy and the forum modality of atmobb/barazo is the speed of conversation, which also affects the conversational style. The originating app context of a given thread would determine its default pacing, but a chat-first thread can still work in a forum context.

An atmobb thread could be interacted with just fine via colibri, it’d just be like a thread in slow-mode (minimum one reply per minute) .

A colibri thread could be interacted with just fine via atmobb, it would just update every few seconds instead of in real-time.

It’s also possible to combine both speeds by separating out chatty digressions in the UI like so:

Motivation

I want a community space like the hypothetical forum.atmosphere.community (running on a natively atmospheric comms app, not Discourse) to be equally accessible as an atmospheric group space in other interfaces, like Bluesky’s social-app and its derivatives.

Here’s a mockup:

So all of these interfaces would be windows into the same group-space of threads:

• forum.atmosphere.community
• mu.social/groupspace/atmosphere.community
• roomy.space/atmosphere.community

What’s next

I’m not lexicon-fluent enough to take the lead on the lexicon specifications required, and no one I’ve talked to yet in the “threadisphere” has the bandwidth to own this, which is fine.

I expect the individual projects mentioned herein to continue with their own respective lexicons for the time being, but I’m hoping other lexicon experts around here can help move these sketches towards a concrete specification.

[erlend.sh]

As an aside, it’s also interesting to see how threads as a context-container has become, as our lil machine helpers like to say, load-bearing for agentic development.

Threads: where work happens - Core Concepts

Delta organizes agent-assisted work into threads. A thread is a conversation with an agent. It can stand alone or include one or more projects. You describe what you want in plain language and steer the work as it develops.

If “thread” makes you think of Slack or a ChatGPT conversation, keep the picture of a conversation and enlarge it: when a Delta thread includes a project, it also owns working copies of the files it touches. The conversation and file changes are recorded together, in order. That combination is what makes a thread the basic unit of work in Delta:

• A thread persists. Leave and come back later; the conversation and any project files are still there.
• Threads run in parallel. When threads use projects, each thread works in its own isolated copy by default. Several agents can work on the same project at once without stepping on each other.
• Revert any thread to an earlier point. The conversation and the thread’s project files rewind together. In a chat app, history is messages. In Delta, history can include messages and edits.
• A thread is shareable. Invite collaborators, and they see the same conversation and any project files, live.

[cloud]

Very cool @erlend.sh - happy to add some ideas from our experiences with SIOC, which was used for forums, blogs, microblogs, mailing lists, and that all have similar threaded structures. More info at SIOC Core Ontology Specification - we had some very similar concepts. Given the strong overlap, it’s fair to say you are in safe territory with your spec below. I’ve prefixed my comments with JB:

• there’s a thread title, i.e. the label of the posts-container - JB: we just used dcterms:title

• thread contains one or more posts - JB: we had created a class for this called sioc:Thread, which was the sioc:container_of a sioc:Post

• posts are ordered linearly (this doesn’t exclude nesting, but that’s non-default and more specific to the forum modality) - JB: we had sioc:Post here and you could assume if a Thread is just a container_of a set of Posts, it’s linear by date, or else see below…

• posts can reply to other posts - JB: we used a sioc:has_reply / reply_of structure which allows nesting or linear depending on the social platform

• posts can have reactions - JB: we added sioc:likes in 2018 but maybe there are other types of reactions

• thread can be subscribed to - JB: our sioc:Thread was a sub-type of sioc:Container, all of which can have a sioc:has_subscriber or in the reverse direction sioc:subscriber_of

• thread was created by someone, at a specific time - JB: sioc:has_creator, dcterms:created

• thread has a permanent URL/URI - JB: great!

• private/public thread access is determined by its channel/category container (space). - JB: We made a module for this called SIOC Access - but we differentiated between Forums or Containers which hold Posts or Items, and a Site or Space which is more like the social platform or data space that houses Forums or Containers. We had more types of Forums, Containers, Posts, etc. in a SIOC Types module.

[bretton.dev]

Coming from the aggregator-style forum modality, as opposed to the classical forum style, I have a few thoughts that might make interop between the two nice:

1. Nesting: I agree linear makes sense as the default, but if every reply could carry both root and parent (with parent == root for top-level replies, like Barazo does), linear apps lose nothing, and apps that nest or sort by votes/algorithm can rebuild the tree. Really just extends flexibility.

2. Votes: Another flexibility would be votes as a core primitive, at the end of the day I don’t think it would impact anyone else as you could choose to ignore and build off of the linearity, but it gives more flexibility for any style of aggregator forum to interop. I don’t think squeezing it into reactions would work since votes are typically one user per post, whereas reactions can contain multiple (I believe?).

This should give flexibility for interop across platforms similar to Lobsters/HN/Reddit/Lemmy, and at the end of the day it may not make sense for some of these to interop, but that’s more of a product decision imo. Ex I could see Coves and AtmoBB interop cleanly, but Coves and Colibri probably not (or maybe so ).

Coves lexicons if anyone wants to compare, we keep them separated for posts / comments, but fairly easy to mirror back to this style where it makes sense.

• social.coves.community.postv2 - Lexicon Garden

• social.coves.community.comment - Lexicon Garden

• social.coves.feed.vote - Lexicon Garden

[ngerakines.me]

Catching up here, but I have a couple of thoughts.

The most minimal amount of information needed to be a post is the text content and a created-at field (user contributed). Facets are nice, but aren’t essential.

For contextual posts, you need a root, and for threads you need a parent. Anything that is the root effectively becomes the post container. That container could be another post as represented by Bluesky’s threads, it could be a discussion in a formal “topic” record for a forum, or could be an event for discussing a calendar event.