Threadiverse Working Group

Scott M. Stolz

@Andy Piper @julian @Johannes Ernst We're converting some software that we use internally and creating an open source fediverse-enabled version of it. The two projects that we are converting are our project management software and our knowledge and information management system, which is an advanced content management system. We have some test sites up but we have not released the code yet. I'll have some examples, hopefully, sometime next month, if not sooner.

Some of the goals of the knowledge base system include:

You don't have to know git to update documentation.
But it still supports importing documentation maintained in git.
It is multiuser.
It is fediverse-enabled (you can log in with your fediverse ID).
It is integrated into a fediverse-enabled website (social channels, fediverse-enabled forums, discussion groups, etc.) so that people can discuss the documentation on the same platform they viewed it on. (Optional, but this is what we will use for all of our websites.)
It includes basic project management features for maintaining and updating content, specifically designed for a multiuser environment.
It is re-themable so that it can match the rest of the website.
It is on your own domain name.

We will be using this for all of our websites in the future.

One of our goals is that documentation and conversations about the fediverse are on the fediverse. And this software is part of realizing that goal.

Also, since our websites will include admin and user documentation, and not all of our writers are git savvy, we want an option where the technical writers can add and update their own articles without using git.

If you are happy with Hugo, that is okay. It is suitable for developers. But a lot of our contributors are not developers, so we can't use Hugo for ourselves.

Image/photo

julian

I'm platform agnostic, NodeBB isn't ideal for collaborative editing of documentation (at least, not yet hahah), but I'd love to host all of the announcements on something like NodeBB.

@[email protected] @[email protected] @[email protected]

Scott M. Stolz

Right now WisTex KIMS, the knowledge and information management system is mostly the admin area and database. The front end is a completely different component. I am creating a front end for Hubzilla, but we can create a front end for NodeBB as well. The goal of the project is that it is (mostly) headless, and you can create your own front end UI for your specific needs. Different websites can have different themes and UIs.

CC: @julian @Andy Piper @Johannes Ernst

shoq

@julian et al. I am new to all of this, so forgive me my dumb questions, but this is a lot to take in on day one, but i like jumping ahead, so can you point me to a post that clearly articulates the "threadiverse" vision in the simplest terms possible? I see a lot of terms being thrown around and not sure how they relate. is there a clear description of what the threadiverse is? What collections of topics are and how they would be used, etc? Are there any librarians involved thus far, in what I assume is the need for public topic ontology and/or directory design of some kind?

shoq

Also, where's the best place to post enhancement requests? Is there an integrated issue tracker, or is all that being done via the github?

julian

@shoq I can't really point you to any resources because — simply put — there aren't any. The "threadiverse" thus far has only been used in conversation to mean that subset of ActivityPub enabled apps that collate notes/posts/toots into collections; think Lemmy, kbin, (streams), etc.

My fediverse history is rusty (maybe we need some official fedi historians!) but I think those were the apps referred to when the term was first used.

This working group is an attempt to bring some cohesion to the disparate development effort for those various apps.

The second reason is that Mastodon is the largest implementor of ActivityPub. It means that much of the fediverse consists of loose chains of posts that don't have any higher level organization. This model works fine in a microblogging environment but doesn't serve well when other implementors have higher level organizations of content.

Scott M. Stolz

The topic of the first WG call is: Representation of the higher level collection of Notes (posts, etc.) — Article vs. Page, etc?

I thought you might find this interesting. As of Version 9.0 of Hubzilla, we switched to sending Articles instead of Notes, but administrators can switch it back to Notes if they want.

CC: @julian @Andy Piper @Johannes Ernst

julian

Indeed, a quick poll of what people currently do is probably going to be illuminating.

Point is, Hubzilla does one thing, WordPress does another, etc.

We need to standardize (informally, anyway) on one approach.

shoq

@[email protected] there is no right or wrong choice, I found. Having gone through that nomenclatural labyrinth for years, when I accounted for all the possible subtypes of objects that could be represented in different schemas, flows, taxonomies, and ontologies, the most generic term for the data always seemed to be -- if not "posts" -- the even more generic, "Items." But of course, an article is just a sub item type in itself. Just not the highest order of them. But item could avoid confusion with most local nomenclatures using more specific terms.

shoq

@julian To your point, this has been out there for many months. I always assumed it was the OG use of the term, without much refinement added (yet). You're confirming my hunch https://sh.itjust.works/post/1119840

shoq

@julian I was dabbling with this draft description to give my copywriter brother something he might improve upon. Could this work?

What is "The Threadiverse." Where "Fediverse" now refers to the decentralized social networking of people and content items, the "Threadiverse" seeks to evolve applications that make group discussions, or collections of them, as followable via popular social networking protocols.

shoq

@julian How do you see the category namespaces working? Is the "topic" always going to be required by each nodebb domain using it? e .g
[email protected], [email protected], topicA@domain3, etc. In which case, how is term authority going to be curated across those domains?
I realize you may not have an answer yet, but curious as to how much thought you've already put into this. It's not going to the fun part.

Also, earlier you spoke of visual hierarchies, but I'm not seeing an example of exactly what you meant. Did you mean within the @actorname itself, (e.g. @US-CivilWar-history@ nodedomain.com? That will get messy fast. At best that can be a short alias entry for a more formal name-path you would expect to see in a serious topic catalogue. I know from hard experience there are no easy answers to these things. If there were, we'd have seen them by now. It's necessity is the mother of invention time

julian

@shoq in terms of namespaces, that is up to the forum administrator to decide. Each individual category has a handle that is unique to it.

Additionally, a category's handle cannot conflict with an existing user or group slug.

Category handles can be changed or adjusted by the admin and doesn't need to correspond to the category name.

For example, the ActivityPub category has the handle activitypub and so it's fediverse handle is [email protected]. If I wished, I could change the handle to alligators.

shoq

Thanks Julian. I figured this was the case. Have you considered rules for tuples? Like should the main entry be the the left or right of a descriptor or qualifier?
[email protected] vs [email protected].

Scott M. Stolz

@shoq In my mind, articles are more appropriate for blog posts. But on the backend, we can literally use any of them, as long as we can pass on the required parameters indicating whether it is a top level post or a comment to a thread.

I just find it odd that ActivityPub has nothing called "posts" and "comments." It is almost as if they are assuming all posts are top level posts, which is how Mastodon operates.

Scott M. Stolz

@shoq Another thing to consider is that although we may agree to use one type, other platforms might not, and we would have to be able to parse what they give us. So if one platform uses article (or whatever) and another uses note, we have to be able to accept their posts anyway.

julian

@[email protected] @[email protected] yes, unfortunately we can't make any implementor do anything but I think a published set of best practices would go a long way toward eventual consistency and interop between instances.

julian

@shoq said in Threadiverse Working Group:

Have you considered rules for tuples? Like should the main entry be the the left or right of a descriptor or qualifier?

Since categories are standalone, we don't enforce hierarchies on the handles. You can name them whatever you want.

shoq

@julian I get that, but a lot of really bad habits will likely be impossible to rectify later. Not suggesting anyone be forced to implement anything, but it's another case were "best practices" would avoid a lot of unforced errors. Whether they see categories as random topics, or controlled vocabularies for any particular mission, some skilled librarians might be invited to describe some of those and provide working examples. This won't matter for stand-alone communities, but it might matter a lot for federated communities looking to optimize their knowledge sharing and distribution as things evolve.

julian

@shoq NodeBB is designed to be flexible enough to allow you to construct a hierarchy that makes sense for your particular community.

One's interpretation may not match others', and that is ok. We've found that being overly opinionated in implementation forces you into a corner and leads to feature requests asking for exceptions.