Alex Kirk

<meta http-equiv=”content-type” content=”text/html; charset=utf-8″></meta>Thank you for reporting! I fixed this in https://github.com/akirk/friends/commit/1bb81e6dae9474c0834ada8c296cbedcb0ec1d13 and it will be fixed in the next release.

Thank you for reporting! I fixed this in https://github.com/akirk/friends/commit/62a43c31384e653549e4820c9f4d3f4f72b5972b and it will be fixed in the next release.

Thank you, Michelle, for giving me some insight into your perspective! This is very helpful.

I think to sum it up, I want to follow you but don’t want to be your partner for life. Adding a user is like a partner for life.

I am curious about this statement and why you believe that? I think we need to make a distinction between a user who is able to log in to your site, and one that doesn’t.

The users that the friends plugin creates have a long unknown password. They don’t have an e-mail address through which a password could be retrieved.

If you follow a site, such a user is created (with the role “Subscription” and no other priviledges) and merely used for the following things:

• Attribute posts to that user in the caching post (i.e. the post_author is the id of that user).
• Store metadata such as profile picture, website, description.
• Make it easy to delete all posts and metadata associated with that folllowed site when you decide to delete/unfriend the user.

If you befriend a site, such a user can get a role where they have some priviledges. A “friend” will indeed be able to read private posts. An “acquaintance” will not. Both can use the friends plugin on their site to log in to your site with this user in order to make comments on your posts. This is only true if the friend user has one of those roles. There is an issue on Github to discuss ideas around potentially preventing priviledge escalation.

Users with a Subscription role (thus not having a “friend” capability) cannot log in to your site.

You never get into the territory of someone having more priviledges on your site if you don’t send or accept any friend requests. You can prevent receiving friend requests by setting a passphrase in settings.

Recently the Advanced Custom Fields plugin vulnerability “allows any unauthenticated user to steal sensitive information for, in this case, privilege escalation on the WordPress site tricking a privileged user to visit the crafted URL path.”

An unauthenticated user is someone who doesn’t have an account on a site. So in such a scenario any Friends users would have been irrelevant.

To me, every user that I add to my website, adds a risk that someone out there can exploit.

I hear you but I’d argue that this is only the case when there is a chance that they can log in.

There has been a similar discussion on Github already and this system has been compared with Unix/Linux. Often services have their own user in the system that cannot be used for logging in and this is not considered a security problem.

I have read that Friends uses the common WordPress infrastructure. Could you possibly have a Friends plugin that gives an option to have the users in a customer table for Friends plugin users that don’t want to add actual WordPress Users?

Exactly using “common WordPress infrastructure” means not creating custom tables. So this is not an option. I could not attribute the posts to users in that table since the ids in that table could clash with real users in the system.

Summary

I hear your concerns and I have seen in other discussions that technical arguments do not help the perception that people don’t like its usage of users for post attribution.

Thus, I am investigating if I could replace subscription users with a taxonomy. I cannot give a timeframe but the code design has some potential to allow this.

I believe taxnomies have much worse visibility and it is much easier to lose overview of them, but “out of sight” might just be what people would like.

Hi Michelle,

this is a thing that people frequently seem to dislike about the plugin. Could you enlighten me about your reasons?

For context, when you follow a user or become friends with another WordPress, that friend or follower is represented as a WordPress user that the Friends plugin creates. When they post something elsewhere, their post is cached in a custom post type and as a post_author that user is set. Thus, the posts are segmented per user. The users have very low privileges (read) and a throw-away long password.

but don’t want any other users in my WordPress installation

I am curious why this is? Is it of cosmetic nature or security reasons?

On your WordPress users list you can filter users with a certain role so that you don’t see the friend users in the list.

Each user has a throw-away long password, so it’s impossible to login with them. Thus not a security risk.

The positive sides are that the cached custom posts are assigned to the right sources. If we didn’t use WordPress users or virtual users, all posts would be assigned to the same user, thus showing just the posts for a certain user would be more expensive.

For the friendship aspect, if you, through a friendship request+confirmation, establish a trusted connection to another WordPress, you can login to your friend’s blog through that connection (similar to IndieAuth). But only in that case.

I am considering changing the creating-user because I hear this a lot. But I also have to say: it is just a user. A line in a the users table.

Curious about your reasons, thank you.

Quick Q: what’s the “Avatar” title supposed to show? ??

When using Activitypub, it will show the avatar picture for each feed and you can set it as the avatar picture.

mainly it’s around YouTube videos such as with this post. When viewed in the Friends page, there is a screen full of white space after each of the 3 videos. If text, it looks fine… Could come from the RSS data…

I think this might be an interference from your site’s frontend theme that bleeds in to the friends page, this is what it looks like for me (no weird spacing):

I responded here: https://alex.kirk.at/2023/05/06/1715899/, did you not receive the reply in the “External Mentions” section?

Hi @didierjm,

to be honest, I have not tested two sites communicating via ActivityPub. I think it should work but maybe not for private posts, for this direct communication via RSS is being used (although posts are pushed directly to friends, so maybe this also works).

To fix the fatal error I have committed a fix (thank you for providing the traceback that is really helpful for fixing this) that will ship in the next version. But as you mentioned, this should be unrelated, it comes from inadequate handling when the incoming ActivityPub metadata is invalid.

Main problem: the way content was generated was not looking good, with a lot of blank space between blocks… So tried to play with various options, modifying the parser, requesting full content (option appears inconsistently, both in Front & Back office, and still can’t find how to have it or not…).

The “request full content” function is provided by the Post Collection plugin and is meant for sites that provide incomplete RSS feeds. When two sites are friends with each other, they automatically send full feeds. So this should not be needed here.

I am curious about blank space between the blocks, did you possibly check the CSS (like: right click the block and click “inspect” and then you can see whether the spacing is caused by HTML layout or CSS)? The content coming via RSS should be identical to the source. Where do you see the space? Maybe this is an incompatibilty of the Friends CSS and the page content?

Re purging caches, what problems did you encounter without refreshing them?

Hi, sorry for the late reply. This is actually a problem with the Friends Post Collection plugin, and likely also a false alarm. I suppose in the title of the Site Health report it mentions post_collection?

I have updated the Post Collection plugin to version 1.1.1 which should fix this problem. It might take a while until you see the new version. I hope this helps!

I’ve tried this with the blog not in / and it works. I was only able to reproduce it when enabling another plugin (Post Kinds) but I don’t think you have that one installed. Could you provide me with a list of the plugins you have activated?

You can send it to me on the Making WordPress Slack or via https://wpfriends.at/get-in-touch/

Thank you!

I now see it too, maybe there was some caching. It might be related to the blog not being in /. I’ll investigate, sorry for the trouble!

I am sorry but I do see that you have the Friends plugin active but I can still see all posts on https://sethgoldstein.me/thoughts/, I don’t see a “Nothing Found”. Which URL is that screenshot of?

Yes, I still see all your posts. Could you view yourself in an Incognito/Private window to verify?

Maybe you could also share a screenshot of what you’re seeing? Thank you!

Oh no. You’re saying it removes the posts from your frontpage when it’s active? In order to show your own Friends feed at https://sethgoldstein.me/friends/ (when logged in), it does modify the Query Loop but it should only do so on /friends/ to avoid what you are describing.

Do you have other plugins installed that might be interfering?

Hi, it does sound like something causes a PHP fatal error (sorry about that!) Do you have access to your server’s error log? Maybe you can find something there.

It is normal (until I implement Get old ActivityPub messages upon subscribe using RSS #136) that when you add a Mastodon account, no messages appear. Only when they post something.

Thank you for your feedback! This is helpful indeed.

I did quite a bit work to make the Friends plugin functional on multisite and it should work both inside a multisite and between multisites, so I wonder what might be going wrong for you. I have to admit that primary and original focus is on creating friendships between completely unrelated sites across the internet.

Regarding BuddyPress functionality, I am afraid I don’t have a lot of experience. Could you help me with some screenshots at which points it would make sense to integrate the Friends plugin?

I did not find an obvious way to friend request another user on the same blog.

This is not supported. I tried to cover this in the FAQ entry “Why is the friendship established between WordPress sites and not WordPress users?” Specifically, a “friend user” is associated with a remote site. This could be one inside a multisite network or one elsewhere.

The 404 page for the /friends/ page is possibly a known bug, could you check that Github issue and maybe draw the connection to your experience?

On multisite (even when using different domains and subdomains) every sub-site needs the main site with the plugin installed. This is because the friend link always goes to the root blog. That’s less than ideal for me.

Could you maybe post one or more screenshots to illustrate this? This would be a bug since by design the home_url() of a site is supposed to be used, it should not even be aware of the root site. Are you working with a subdir multisite?