Evaluate which REQUIRED_ROLE is really necessary

[akirk]

Currently, the Friends plugin requires the main user to be Administrator on the site.

The choice was initially made to align it with the fact that it assumes that a WordPress site is only being used by a single person, and that would be the administrator.

But from a priviledge position it is probably not necessary and also more secure. See Automattic/wordpress-activitypub#172 (comment)

cc @timnolte

[akirk]

I made some progress on the implementation in #121 but to be honest, it is not a high priority. I welcome contributions.

[alecmuffett]

@akirk referencing your answer at Automattic/wordpress-activitypub#238 (comment) does this mean that upgrading my Editor account to Administrator will make the plugin work, or does the plugin assume that there is only one administrator per blog, please?

[akirk]

If you upgrade your account to Administrator, it will work. There can be multiple administrators, in the setting you can specify the "main user" like this:

With #121 the plan is that all features will work except adding and removing Friends, so for those activities you would switch to an admin and can use the Editor user for all other activities.

[alecmuffett]

With #121 the plan is that all features will work except adding and removing Friends, so for those activities you would switch to an admin and can use the Editor user for all other activities

Given the nature of self-hosted WordPress, that sounds like an acceptable compromise. In the meantime I will try upgrading my Editor to an Admin and see how it goes. I'm still unclear why I am not seeing feed subscriptions from others when I am certain they have updated, so clearly I have a couple of other issues to sort, too.

Once you have #121 in a fit state, I would be happy to beta-test, if that's interesting? I lack time to code at the moment (because child care) but occasional debugging is doable.

[timnolte]

@akirk I haven't had a chance to try out this plugin yet but now I am reminded why with this issue. I don't operate as an administrator on any of my sites. However, now I am even more concerned about using this plugin based on your comment that your plugin creates users on the the site? Is that true? Can you explain why users would need to be created? Standard WordPress commenting doesn't require new user accounts to be created on a site. It would appear that I won't be trying out the plugin anytime soon as both the Administrator requirement and the act of creating users on my site are 2 pretty huge blockers for me. Once I get some other items cleared from my plate I can take a look at this issue, but if user creation is an absolute core requirement of the plugin I still will most likely not be using the plugin.

[alecmuffett]

Can you explain why users would need to be created?

@timnolte to answer on behalf of @akirk, I think it makes sense. Basically follows/subscriptions are implemented as "users" because (much like mastodon) the posts of the people you follow are imported into your blog, with one user per "follow". The intention appears to be that the users are created with really limited privileges (under a possibly-new user type called "Subscription") and the benefit is that there's no reinvention of architecture/code needed to manage their content.

I take your point about "Commenters" but commenter-content kinda "hangs off" major posts that the site users create, and is well-supported as such within the WP ecosystem. But the fediverse approach of "following" turns WP into something like an RSS aggregator (ed: corrected similie) - caching new, complete posts - and assigning them to individual users, one per feed, is a very WP-friendly way of managing that content elegantly.

Source: I am adding and deleting feeds while testing / trying to get the Fediverse plugins to work, and it's nice to have a clean "delete" which works.

I am a bit annoyed at the "Need an Admin account"-thing, but that's being at least partially addressed, and I have to admit that for people who self-host single-user a WP instance this makes a reasonable compromise. Mostly I want not to have to be running as an Admin all the time just in case someone steals my cookies, and I imagine that subscribing/unsubscribing from an Editor can be addressed over time, e.g. with some sort of cronjob running as a privileged user.

[timnolte]

So actually this doesn't work like Mastodon at all. When I follow or someone follows me an actual User account isn't created on my Mastodon instance. It is metadata attached to my Mastodon account, and likewise I would expect that it would be metadata attached to my WordPress account. The very fact that it is creating users now makes me concerned that when I have my WordPress site setup those new accounts will now also show up in Webfinger as accounts on my WordPress site just like accounts on a Mastodon instance. This is flat out wrong IMO.

[alecmuffett]

My understanding is that a given instance of Mastodon takes (somewhat temporary) local copies of the content created by people who rare followed by the users of that instance; this is similar behaviour to an RSS aggregator and it improves performance.

That content is presented as a page for viewers of (e.g.) https://mastodon.social/explore where it literally says:

These posts from this and other servers in the decentralized network are gaining traction on this server right now.

...and it is rendered from local copies of the followed content.

In the context of WordPress it makes sense for that content to be attributable to separate "feeds" and the simplest way to do that — the simplest way to bookkeep it — is for each feed to be a user.

If you don't like that, you probably also don't like the concept of Wordpress "Commenters" being able to register for limited comment-only accounts on a Wordpress instance. And that's okay. Nobody is forcing you to use any of this functionality. But speaking as a longterm Wordpress user and 35-years-of-writing-code, this approach is not unreasonable.

[timnolte]

There is a big difference between content and accounts. As I've already stated, as I run my own actual Mastodon instance, caching content on an instance is nowhere near the same thing as creating actual users on a Mastodon instance. I'm not talking about rejecting the ability to cache/store content, I'm talking about the misuse of actual WordPress user accounts. I also do understand the concept of allowing, or requiring, WordPress accounts for commenting. That is also very much like having WooCommerce customers creating accounts on your WordPress site. My key point is that these Friend users will never be, and should never be, logging into the WordPress site, and that very fact means WordPress accounts are not the right content type to be using.

[alecmuffett]

I'm talking about the misuse of actual WordPress user accounts

I would describe it as creative use of existing content-management mechanisms in order to maximise reuse.

Your /etc/passwd file contains likely dozens of "service" accounts which exist purely for the convenience of administration and content-separation; and leveraging that to manage content separation within the Unix metaphor, is elegant.

My key point is that these Friend users will never be, and should never be, logging into the WordPress site

...and they cannot, because the accounts are, like Unix "service" accounts, locked in a way to prevent them being logged-in-to; but of course you knew that before you launched your complaint?

[timnolte]

Actually, your use of the Unix service account metaphor isn't correct. Those accounts have various privileges on a system and are used by the service that runs under that account. In this case these Friend users shouldn't ever be performing tasks on their own.

[timnolte]

Also, just because you can do something doesn't automatically mean you should.

[timnolte]

Additionally, my point is if this plugin is to provide functionality similar to that of the other Fediverse platforms, like Mastodon, then looking at how those systems are actually built is what should be done. They are built the way they are for a reason.

[alecmuffett]

In this case these Friend users shouldn't ever be performing tasks on their own.

Content needs to be fetched (again, compare to an RSS aggregator) and it also needs to be stored somewhere. This is an elegant solution which mostly fits the WP metaphor, and (personal opinions ahoy!) the benefits of this approach outweigh the disbenefits, especially with active development ongoing.

They are built the way they are for a reason.

Mastodon is horribly over-engineered for the purposes of a single-user instance; and in any case the Friends plugin is an approach to overall "feeds" management, (apparently) not just Fediverse. If you would prefer to "Make WordPress More Like Mastodon" then you're apparently excellently positioned to undertake that effort.

In the meantime: I think @akirk is doing something reasonably sane and — so far — promising.

[akirk]

Thanks for the lively discussion and the insightful perspectives!

It is important to know that Mastodon or ActivityPub is not the origin or purpose of the Friends plugin. It was designed to connect WordPresses and to give you the power to consume the web your way by pulling things that you want to read in a single place (and through plugins like Post Collection to do further things like store other blog posts with full content or automatically fetch the content for mangled RSS feeds, and then even push them to your e-reader).

It has been very interesting for me to see that ActivityPub's design fits the Friends Plugin's design so well. But that said, there are a number of aspects that, in my opinion, and I made these design decisions, speak for using dedicated WordPress users:

• Incoming content is cached in Custom Post Types and those posts are associated with the respective user and not coalesced into a single one.
• A user on your WordPress site is meant to represent a real person, and you can follow a person on multiple platforms with multiple feeds from different sources (RSS, JsonFeed, custom parsers for Twitter, Tumblr etc using Fraidycat's parsers and RSS Bridge).
• WordPress has a priviledge system, and those users have very low priviledges (subscriptions only have read).
• You can become friends with other WordPress blogs (resp. the person who writes the blog). This actually does allow that other person to authenticate into the account on your own blog because you established trust (but not using a username or password, a long one is assigned and thrown away but by authenticating through your own site), and they can use that account to comment on your blog.
• It is quite useful to see your friend network as a list of users on your site, with their profile pictures, the number of posts associated with them. All this is just using the database design that WordPress was design for.
• If you unfollow a user, just all their content and feeds are deleted. This is a clean abstraction.

As @alecmuffett already said: Nobody forces you to use the plugin if you don't agree with the design decisions or their implications. I am happy that you brought your opinion to the discussion because it is worth highlighting aspects of these decisions that need to be taken into consideration.

[timnolte]

I think you totally miss my point about these Friend accounts being created, they are in no way being used directly as running accounts to pull content. Again there are easy ways to implement this without using actual WordPress accounts. The fact that it is using WordPress accounts also complicates, or even prevents, the use of this plugin on a MultiSite WordPress instance.

[timnolte]

The fact that WordPress accounts were used instead of simply a Custom Post Type is my issue with the design. There is nothing I see in this setup that requires these to actually be real WordPress accounts. From a security standpoint I just can't see it being acceptable to have all of these accounts created that no one uses or monitors.

And yes, there is nothing requiring me to use this plugin but I was hoping that it was going to be something I could support instead of reinventing the wheel. Unfortunately, based on this design decision I just can't get on board with that, so I will probably look elsewhere for WordPress & Fediverse integration like this.