the problem with the nickname is, that it is not unique and it might have spaces in it.

I think the uniqueness is something that should be addressed by the instance administrator... I find it highly unlikely that a WordPress instance is going to use the same nickname for multiple contributors / admins.

As for spaces, there are many cases where there are disallowed characters that need to be dealt with. That's kind of a coding 101 issue that has multiple solutions (substitution, deletion, etc.) If those options aren't acceptable, you could always add another field to the user record to add an ActivitySteam identifier.

No matter how you slice it, exposing the user ID of an account publicly is not a good idea.

I understand your point, but without using plugins, the username will always exposed with the Autor URL.

I think it is better to add an extra field to not upset long time WordPress users and to not force them to maybe change their nickname afterwards.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Keep

My username also contains dial tone and because of that there is an error when calling/searching.

@thomas [email protected]

the problem with the nickname is, that it is not unique and it might have spaces in it.

usernames can contain spaces as well. See #221

the problem with the nickname is, that it is not unique and it might have spaces in it.

For me the not-uniqueness of the nickname would be very desirable. We have many people working on our site, but I would prefer if people could simply follow all entries from the team by following one nickname. Alternatively, it would be great if the display_name could be used.

The display_name brings the same
Issues as the nickname... it could have spaces and is not unique...

Hey,

thanks for the quick reply. That was unexpected in a very positive way. I understand that a space could be an issue, but same as the uniqueness, this should be something which should be manageable by the site admin.

I agree that potential usability issues could arise from this, but IMHO that's something a documentation entry would solve easily.

Alternatively: Is there a way to follow a whole blog?

@stiller-leser See issue #1. :-)

The other problem with display_name & nickname is they are user editable.
If this happens it would break federation, and your followers servers would likely drop all sent messages.

Shouldn't this be solved in code?

if (nickName)isUnique {
nickEligible=true;
}

If a nickname is not unique, shouldn't it just be greyed out as an option (along with an explanation which might encourage someone to come up with a unique nickname)?

The initial poster is correct in the assertion that mandating the use of actual usernames lessens WP security on every instance with this plugin active. So, any option that results in people not getting 50% of my login information just by looking at my ActivityPub handle should be explored.

The other problem with display_name & nickname is they are user editable. If this happens it would break federation, and your followers servers would likely drop all sent messages.

Sure, so warn the end user?
Lock the display or nick (if possible)?
Allow an arbitrary name to be defined in the plugin and mapped to the account?

That last idea is probably the simplest and the most secure. To reiterate, as it stands, activating this plugin announces to the world 50% of the login data for every account on an instance. That is a major security consideration.

Actually, I would refute the idea that using the username reduces anything security-wise. If you actually have a Mastodon, or any other Fediverse platform, account your identity is your username. Same was always true with even platforms such as Twitter. If you properly secure your accounts with good passwords and 2FA then all of this is pretty much moot.

Same was always true with even platforms such as Twitter.

Correct, platforms like Twitter have decided to compromise security by forcing a username to be public. WordPress chose not to do this, hence one of the reasons DisplayName and NickName exist.

This is a WordPress plugin. Respecting a wordpress design choice while achieving integration would make more sense. This would be achieved most simply with a new table for ActivityPub username (which is then mapped to the account internally).

No, security through obscurity is actually not real security, that is what you are pushing for. This makes this unnecessary complex for little actual benefit.

Not to mention the fact, that unless you've taken extra precautions, if you simply go to the open REST endpoint of your WordPress site https://example.com/wp-json/wp/v2/users all of this data is exposed, by WordPress, by default.

security through obscurity is actually not real security

You are missing the point. Exposing someone's username opens social engineering vectors for attackers that are only exposed by insisting that login data be made public.

Grab a username here, grab an email address there...

Not to mention the fact, that unless you've taken extra precautions, if you simply go to the open REST endpoint of your WordPress site https://example.com/wp-json/wp/v2/users all of this data is exposed, by WordPress, by default.

I stand corrected.

So, if someone visits http://example.org/author/user; and user happens to be the nickname of multiple user accounts, how does Wordpress handle this? Does it just pick one user? Or does it merge everyone's posts together?

Why would following @[email protected] via ActivityPub not provide identical behaviour?

@sjlongland so that is a very good point that ActivityPub should be following the same logic. Looking at the Core methods for the author permalink it is using the user_nicename, and looking at get_posts() and assuming the default would be to call that with author_name => user_nicename that would in fact mean that all posts for users with the same user_nicename would be returned.

In keeping with what WordPress Core does, I would say this logic should be maintained. Essentially, this Issue shouldn't be about anything to do with changing the URL, because that is already handled by WordPress.

As a quick fix: You can install the WebFinger plugin for WordPress, that already supports the user_nicename (hidden feature).

... user happens to be the nickname of multiple user accounts

This wouldn't happen since user_nicename is not the same as the user nickname, it is rather a url sanitized version of user_login.

From wp_insert_user()

• user_login string
  The user's login username.
• user_nicename string
  The URL-friendly user name.
• nickname string
  The user's nickname.
  Default is the user's username.

There are many Wordpress admins that have used their email addresses as a login and (required) email address. Which can not be changed. Or re-used. That exposes those site admin's email addresses in a very public way.

So is the plugin simply going to dictate that those admins create new email addresses, to create new Wordpress profiles, in order to get a second chance at creating a username that is not an email address?

That seems very restrictive. If a user loses access to that specific username profile, do they lose access to their ActivityPub feed? I feel there should be a way to recover (e.g. seed phrase) and migrate one's content to a new username.

Migrating content is just the normal WordPress Core method of migration. When you delete a WordPress user you are prompted with the option to reassign the content to another user. I don't understand what the concern is here as there is nothing restrictive.

Let me clarify the scenario because it's not about migrating content from one profile to a different profile. It's about changing the profile username and continuing to use the same email address associated with that profile.

Granted, this is a Wordpress restriction, but it's exacerbated with the ActivityPub plugin because the username is now public. (Most people don't care what the username is when it's private)

The ActivityPub plugin uses the profile username, and it becomes a major effort to change it. You can't simply create a new profile because you won't be able to use your existing email address. The next alternative is finding a plugin to do it. Or opening phpMyAdmin and performing surgery on the database.

Perhaps there is a solution I'm not seeing.

We have built in a possibility to change the username of the blog user and will be implementing the same possibility for author profiles in one of the next versions.

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days.

keep!