Threadiverse Working Group
-
@[email protected] +1 on all of the above.
Unnecessary duplication of resources would be unfortunate, so let's avoid that.
Part of the discussion on the fedidevs session (which I think you were in?) centred around building that one central directory for resources.
I'm not sure whether @[email protected] or @[email protected] have any specific software in mind (oooh, federated wiki? haha), but could be Federated Hub; have you got a link?
I'm focusing on getting category actors up ASAP so I can make a followable category for the WG.
-
-
@andypiper @julian @scott Hugo is really easy to do once set up and GitHub hosts it for us. It has its limitations but we haven’t run into them. Are there requirements that the current setup doesn’t meet?
-
@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.
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.
- You don't have to know git to update documentation.
-
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.
-
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 -
@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 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.
-
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 -
-
@[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.
-
@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.
-
@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
-
@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 toalligators
. -
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]. -
-
@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. Stolzreplied to shoq on last edited by [email protected]@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.
-
@[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.