Moving Threadiverse WG to ActivityPub category

I see most of the ongoing topics in Threadiverse Working Group are actually related to implementation, so we should probably move it to ActivityPub, and maybe add another category under Meeting to announce the WG meetings, since #meetings is for announcements.

Also the WG has another name in the SWICG, so we should match that one.


That’s fine. The discussion taking place there is meant to be asynchronous information collection on the fediverse, instead of using something siloed like GitHub.


@angus can you please update About the Threadiverse Working Group category with the correct name for the WG, I have read it somewhere but cannot find it now.

I moved the original Threadiverse WG category to Threadiverse Working Group (under ActivityPub) and created a new Threadiverse WG (under Meeting) where I moved four existing topics related to the meetings.

The “Working Group” is federated and can host discussions, while the “WG” is not and should host events for announcements. Minutes may be pasted to the relevant meeting topic and quoted for discussion, or could be pasted in a linked topic under “Working Group” so they get federated from the start.

If the name should match “Task Force” we should be able to change it :slight_smile:

1 Like

Since I post meeting minutes and agenda prep topics as well, I will set up a corresponding meeting category in NodeBB and sync up.


@how can you please have the meetings category follow

I do not see a federation tab on your category so I am unable to have my category follow yours yet.


Yes, I did not federate the meetings yet. On it…

@angus I can’t see the federation settings for Threadiverse WG, is this because @everyone has only reply privilege there?

The ActivityPub actor settings are now centralised in an Admin panel (see here). When tag actors are added (once this is merged) you’ll see them here too.

1 Like

@how Sorry, but I’m going to need to reverse this as it’s causing some confusion. As a general rule in community management, the fewer categories the better (I normally force our clients to choose a maximum of 5). In the case of categories being ActivityPub actors, even more so :slight_smile:

1 Like

Meeting are for meetings, not for discussion. So please, use Meeting for announcements with a tag, and keep the discussions under ActivityPub. I have created this topic for a reason, you can’t just revert things that have been proposed and discussed like this.

Just for now while we’re getting the Forums WG up and running, and trying to get federation working smoothly, it would help if we could keep things in a single category. I don’t mind where the category is.

p.s. You’ll be happy to know that we decided (in our last meeting) to make the official name of the WG the “Forums and Threaded Discussion Working Group”. I’m going to update the handle of the category to as soon as I add the ability to change ActivityPub usernames to the Discourse plugin :slight_smile:

*edit :point_up: this will be possible once this is merged!


Some implementations may not support that:

Boggles the mind how that kind of UX limitation made it in and everybody involved thought that was an ok compromise to make at all.

I accidentally used a username in my id at the start, and the moment I noticed I refactored it out immediately…


I may be missing something, but it seems to work

Mastodon predates ActivityPub and there’s also precedent for unchangeable usernames in e.g. email, where reassigning an email address is a Bad Idea. To be clear, reassigning WebFinger handles is still a bad idea, but the stakes are lower because it’s not (or it shouldn’t be) your primary identifier. Now, if it was decided to be the primary identifier, then yeah, the stakes get raised again. And there is an argument to be made that it could/should be primary – it allows more-or-less transparently reassigning the actor by updating a link, which could be good for portability if you’re willing to concede that usernames should never change. Say for example you had a DID method like did:acct: or something that allowed for relative paths against a variable base uri. So could refer to my inbox, regardless of where it was hosted (you could specify to look up a self-link and then append the path to that)

1 Like

Right now, I’m not sure I agree. I think it makes more sense to keep the id and username (or preferredUsername) as separate concerns. An id was, is, and always will be serving the single purpose of being an identifier. In ActivityPub an id is essentially a UUID. I don’t see the utility of collapsing the username into that concept or role. It both confuses the roles of id and username and limits the separate utility of the username, e.g. making it harder to change.

There’s no reason you couldn’t do the same with an id.

To the extent that Mastodon conflates the two (query whether it really has), I think they have simply made a mistake. Again, happy to be shown I’m wrong on this, but right now, I don’t see it. On the WebFinger front I would note that WebFinger is essentially a discovery protocol. It doesn’t rely on the immutability of usernames.

by “webfinger handle as primary id” i mean that some earlier examples of AS2 documents explicitly use acct: URIs as the id of e.g. a Person actor or attributedTo. indeed, preferredUsername ought to be completely separate from id, i’m just saying that if the id was based on the acct: URI it would provide one layer of indirection at the cost of not being able to change your acct: URI (which depends on a username, not necessarily the preferredUsername)

Basically, in summary:

  • If id is an HTTPS URI, it SHOULD NOT depend on or include the username, because username might very well change.
  • If id is some kind of DID that depends on acct: URIs or WebFinger, then it necessarily MUST depend on username because it includes the username.

You either lean into it or run away from it. Mastodon’s half-measure of using either/or and also including the username in the id is the worst of both worlds.

1 Like

Webfinger address is sometimes used as primary ID because it’s a memorable name, like an email address, and people don’t expect it to change. I think the best approach is to allow remote actors to change preferredUsername, but don’t allow local actors to change preferredUsername (or at least don’t allow to change it casually). For mutable name, a name attribute should be used.