An idea I'm playing with, what do you think?

Use @[email protected] as the catchall account. Perhaps allow overriding via constant or filter (and I would even see if we can get away without that), but URL@URL is a consistent, predictable, workable default that requires no setting and won't collide with any given WP user name. It's truly an identity for the whole site. A good place for decisions not options!

And if we can't collide on usernames, there's a bunch of chances for code simplification in here. And I think we can then support both catchall user and single users at the same time with no trouble? Or is there a problem with content duplication that way?

I also remember back when I knew I could try /feed to any given site and find out if it was WP that way. I like predictable, hackable URLs and this provides that for our whole-site identifier.

Use @[email protected] as the catchall account.

We considered this for the "application" actor, but found a risk for WP users who use / have previously used brid.gy fed.

We considered this for the "application" actor, but found a risk for WP users who use / have previously used brid.gy fed.

Hi @mediaformat , thanks a bunch for the context!

My perspective is that I would hate to make our product worse simply because some users have hooked their site up to Bridgy at some point. Requiring everyone to default to the weird-looking [email protected] just because it won't conflict with an edge case seems backwards.

But this is good to understand so that we can ensure there's a sensible path to allowing those users to work around their issue by setting a custom identifier as a fallback. Can we outright detect Bridgy usage?

It might also mean that we don't want to enable the catchall "account" for existing sites that upgrade to the new version, but we do opt in fresh plugin activations. The catchall account seems to be what most people would like. It's certainly what I was expecting when I came to the plugin.

I really don't think the site-wide user should ever be on by default. I actually wouldn't expect that to be the default. Honestly, if someone only has 1 account on their site why would they not just be using their single account as the author anyways. As I see it this sort of "user" is really just for sites with multiple authors that want content to appear from only a single account regardless of the author, or as an aggregate type of account when there are multiple authors.

I really don't think the site-wide user should ever be on by default. I actually wouldn't expect that to be the default. Honestly, if someone only has 1 account on their site why would they not just be using their single account as the author anyways. As I see it this sort of "user" is really just for sites with multiple authors that want content to appear from only a single account regardless of the author, or as an aggregate type of account when there are multiple authors.

Thanks for the input! I am agnostic at this point about if both user- and site-centric modes should or can be enabled simultaneously.

But I do think that onboarding new users and setting expectations so that they can decide which works best for them is the way forward. The user-based model is agreeable to you and that's great, but that's far from universal: #1's popularity attests to that.

Is this feature going to be implementing the ActivityPub Groups feature?

https://socialhub.activitypub.rocks/t/groups-implementation/591

It seems like for WordPress this might be classified as a "Working Group".

Some additional context of Groups that seems related. https://mastodon.social/@mcc/110539051666442298

I'm just shining some light on this existing work in the larger Fediverse landscape in the hopes that what is implemented is something that falls within existing standards.

I really don't think the site-wide user should ever be on by default. I actually wouldn't expect that to be the default. Honestly, if someone only has 1 account on their site why would they not just be using their single account as the author anyways.

Since you asked—because this isn't all about blogs. Sometimes I'm publishing content that I want divorced from authorial identity; for example, I have a site which is a vaguely wiki-esque rules compendium for a game. On the site there is a clear delineation between blog articles and rules content, and I display author info only on blog posts, because that's the only time I'm writing conversationally. I'm still the only author on the site, but only one type of content acknowledges the presence of an author.

With both types of content in mind, it's definitely more appropriate for the feed to be as an identity, not as an identity; at the very least, it should have the site's icon for a profile pic, not my personal user icon. But it's silly to ask a user to change their name and icon for the sake of the feed's presentation (plus I do want to look like a person when my info is displayed on the blog articles). I could make two authors, but I don't want two feeds; this is not a high volume site, any anybody following it almost certainly wants updates of both types.

In short, a unified feed would give me exactly the end result I want without any silly hacks.

@FoxLee ultimately my point was about defaults. While your use case warrants using the full site pseudo identity I still don't think it should be the default, but it should be easy enough for folks like yourself that do need this feature to turn on.

Does it hurt if the blog-wide user is active by default? I think you can force visitors to follow either of the identifiers, by only providing the identifiers of the users you want them to follow.

I am also thinking about: maybe the blog-wide user will "only" boost the users/authors post (at least at default setting).

But I hear you and will think about a way to enable/disable users.

@pfefferle so as a plugin developer myself I'm always looking at how I am handling changes for existing users when my plugins are upgraded. I never want my plugins to unexpectedly do something, or change a users site, in ways they were never expecting. I never want to force something on my users that they didn't ask for, so I work to always give them options.

Additionally, I feel like WordPress sites aren't necessarily multiuser by majority. I'd be very curious to look at the FediDb tracker to see how many WordPress sites it finds are actually multi-author/user sites. My take on this feature is that a large portion of the user base has no need for it. That doesn't mean I'm saying that it's not needed but for those that do need it let them turn it on when they upgrade or install it.

With any WordPress plugin it is generally better to have less on by default and let people turn on the things they need. This also helps to reduce the load on a site and potentially reduce the attack surface a plugin adds to a site.

Hey @timnolte

Additionally, I feel like WordPress sites aren't necessarily multiuser by majority. I'd be very curious to look at the FediDb tracker to see how many WordPress sites it finds are actually multi-author/user sites. My take on this feature is that a large portion of the user base has no need for it. That doesn't mean I'm saying that it's not needed but for those that do need it let them turn it on when they upgrade or install it.

That is exactly the point, why a lot of users requested a blog wide account. To not use a WordPress user, but to have the blog itself as a user. If you refer to the "boost" feature, you are right!

What I want:

• Be able to disable/enable users and/or the blog wide user
• Decide if the blog-wide user should post real Activities or if he should "only" boost the user posts (maybe this could be implicit: If user accounts are active -> boost, if not -> create full activity)

I would love to have some kind of onboarding process, to check what setting is the best for every user.

@pfefferle yeah, I think an onboarding process would be very helpful.

I see the two 2 models as mutually exclusive:

1. A Service actor (appears to Mastodon users as a Bot) that will Announce all published posts.
2. Single user mode, where all Posts regardless of the Author post as the Single Actor.

It's a tricky presentation because there are really 3 choices:

• Service Actor
• Single Actor
• Current mode (I'm tempted to refer to it as Multi Actor, but the term doesn't exclude having the Service Actor)

Maybe a radio button?

Single Actor mode brings up another issue of what could/should be done about existing Accounts / Posts

@mattwiebe this is ready to review now

I tried running this branch on a live dev server, wiebeatomic.wpcomstaging.com. By default it generated [email protected] which seemed fine but I couldn't follow it as a profile from Mastodon. Then I used the settings to change over to [email protected] and the setting appears to have taken but alas I still cannot follow it properly from Mastodon.

[email protected] works fine.

Do I need to set any constants?