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 
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.
@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
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 forum-wg@socialhub.activitypub.rocks as soon as I add the ability to change ActivityPub usernames to the Discourse plugin
*edit 
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 did:acct:a@trwnh.com:/inbox 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)
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:
id is an HTTPS URI, it SHOULD NOT depend on or include the username, because username might very well change.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.
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.