Yes, Discourse could do something similar to that with its comment embed widget. Among other things, it might help to reduce the awkwardness that some people experience when starting a forum that only has a few active users: AI sockpuppet accounts to jumpstart my community?. New Discourse sites could use blog posts to promote and seed their forum. That is kind of possible now, but allowing users to comment directly from the embed widget would make the process more seamless.
3 Likes
A simple Discourse-connected comment form on the Wordpress side, so that visitors do not have to first go to Discourse and create an account there, before posting a comment, would help reduce the friction and build engagement, at least for publishers like me.
For my use case, it would be ideal if a commenter could leave their comment simply with a name and email address. This then could be used to create a staged user in Discourse and invite them to fully join to continue the conversation, without stopping them from leaving their comment.
We’re finding that the extra friction of creating an account to leave a comment on a published article is making it hard to build engagement and ultimately grow the community in our forum. For example, when asked about our comment section (using the current Discourse-Wordpress integration), one author gave us the following feedback:
Re the conversation area: now that you mention it… I remember seeing this. And at the time, I actually figured I’d forget it for the time being since it seemed time consuming to sign up. That’s strong evidence re: how most people would feel about having to go through that process. I’m normally borderline obsessed with seeing comments on my writing. I remember laughing to myself and saying : “Guess I’m not obsessed enough to deal with this right now.” Ideally, you’d just leave comments open to everyone with no sign-up process. But any level of simplification/ease would improve engagement there. Comments like that are usually an impulse move. If people are stymied at all, they’ll tend to move on and not take the time.
3 Likes
I was just thinking about this the other day. Oddly I’ve missed having Wordpress comments on my blog posts because it seemed so fast for people to get started, very low barrier to entry.
Despite having a really simple sign-up process, right now if someone wants to comment on the post, they have to visit a new page. I think crossing that threshold may feel too burdensome. Almost like I want to comment on A, but I have to visit B to comment on A and then go back to A to see the comment. Would feel more natural to comment on A right underneath A.
I like the idea of staging users. I can think of maybe hacking this together by having the Wordpress comment form send an email to the Discourse forum and then stage a user that way, although I imagine it may get more complex to fully integrate it this way.
3 Likes
I think this used to be possible, but I’m fairly sure that Discourse now compares the email’s “From Header” to its Return Path. If those don’t match, the email is rejected. (If Discourse isn’t checking the Return Path, the comment system could be easily abused - any email address could be entered into the form.)
There are a few ways that the problem of Discourse as a comment system could be approached. I think the best approach would be for Discourse to improve its comment embed iframe so that users could interact with it as authenticated Discourse users. If that’s not possible, an embedded Discourse comments web app could be developed. That would be an interesting project, but I’d want to be sure that Discourse wasn’t going to provide similar functionality via their embedded comments iframe before pursuing it too far.
There are also some possible WordPress specific solutions. The simplest one being to enable WordPress comments and the WP Discourse plugin. The risk is that this would reduce activity on the Discourse forum. I think there’d be ways of helping with that in the WordPress UI though - for example, link to related conversations that were happening on Discourse.
It would also be possible to develop something specific to WordPress sites that were functioning as the Discourse SSO provider. I wrote about that in previous posts in this topic. To do a good job of it might require significant changes to the WP Discourse plugin. Unless (I’m thinking out loud here):
What I’m trying to indicate with the above screenshot is that for the case of a WordPress site that’s the Discourse SSO provider, comments could be displayed with the Discourse comment iframe. Comments could be created through a form that posts to the Discourse API. This might require some changes to the Discourse comment iframe to ensure that it refreshes when a new comment is added, but wouldn’t require users to be able to interact with it as authenticated Discourse users.
4 Likes
So, if I understand correctly, the idea would be that the commenter would register on the Wordpress side, then leave a comment via the embedded Discourse iframe, which would post to the topic on Discourse, then refresh the display back on Wordpress, so that it appears right away.
The Wordpress registration process would validate the email, I take it. But this would also require switching to Wordpress as the Discourse SSO provider—doable, but in a way unfortunate, because it moves the friction to the other side for people who might just want to sign up for the forum.
I tend to agree with what you’ve said here:
If it were even possible to register right there in the iframe, or at least be staged, so that one could proceed with the comment (which might only get posted once the email is validated), that would strike me as one solution that balances ease of use with security.
2 Likes
Yes, you’ve got it. If WordPress is the SSO provider, the problem of allowing users to comment on Discourse topics isn’t that hard to solve. The tricky part, in terms of working with the current state of the WP Discourse plugin, is figuring out how to display the comments on WordPress - currently the WP Discourse comment section doesn’t mirror the Discourse topic’s replies. Instead, a selection of the “best” comments is displayed.
It would be possible to update the WP Discourse plugin to handle this use case, but to do it properly would require completely re-writing the way it handles Discourse comments. It’s not my decision to make, but I think that putting effort into improving the Discourse comment iframe would be a better use of time.
5 Likes
I just wanted to add my voice for wanting this feature.
It would be really good if users on WP could simply register/sign in and comment directly under a post on WP without having to navigate away to the forum, so that the whole thing feels more like a commenting system. Their comment would appear both beneath the post and on the discourse thread that was created. And they always have the choice of posting either in discourse, wordpress or both - seamlessly. I have no idea how this would be achieved, but that would be a really seemless way of integrating WP comments with Discourse that feels less clunky and would no doubt vastly improve the number of comments than we currently get with the existing plugin.
3 Likes
Perhaps this:
But it hijacks totally login of Discourse AFAIK.
Would that allow users to post comments directly under a Wordpress post and auto populate that post on the corresponding Discourse thread?
I’m working on this now. The first version is for a headless WordPress site that uses the Remix framework for its front end. Once that’s done I’ll make a version for regular WordPress sites. It will likely be a plugin that extends the WP Discourse plugin. I’m hoping that most of what I’m doing on the headless WordPress site can be transferred over to regular WordPress sites, but it might require some compromises.
Allowing users to comment directly from an external site is trivial to implement. The main requirement is that the external site has access to the user’s Discourse credentials. That can be done either by using the external site as the DiscourseConnect provider for Discourse or by configuring Discourse to be a DiscourseConnect provider for the external site.
In the second scenario - where the external site isn’t the DiscourseConnect provider for Discourse - the first time a user wants to comment from the external site, they’ll need to click a link to connect their account on the external site to their Discourse account (or to register on Discourse if they haven’t done that yet). It can be fairly seamless from a user’s point of view.
The above change doesn’t make the whole thing feel like a regular commenting system though. A normal expectation for a commenting system is that you can read and interact with all the comments. The WP Discourse plugin only displays a selection of comments that are pulled in from a special route that’s provided by Discourse. It doesn’t provide any functionality for interacting with comments.
The difficult parts of the problem are:
- paginating through all of a topic’s comments on WordPress, keeping in mind that there could be thousands of them
- providing a UI that give a user some feedback about where they are in a long list of comments
- figuring out how to display comments that are direct replies to other comments. (The Discourse convention for this is out of line with how most comment systems deal with replies.)
- allowing users to reply directly to a comment, like a comment, edit their own comments, etc
- dealing with comments that were created on Discourse that might contain content or markup that can’t be easily rendered or interacted with on the external site. For example oneboxes, polls…
- providing a way of filtering comments by recent, oldest, best, etc…
This all needs to be accomplished without putting an excessive load on the external site’s server, making too many API requests to Discourse, or consuming too much memory on the user’s device (the goal is to make a lightweight comment system). It’s achievable, but it’s not something that can be just dropped into the existing WP Discourse code without making significant changes to it.
4 Likes
Good to hear you’ve gotten a start on this!
Just a thought: since part of the idea is to reduce the friction of getting people to comment in the first place, it could be a good idea to focus on that seamlessness of that first comment. As mentioned above, it seems many people simply want to be able to comment with their email address; the issue then is validation and login, or account creation (depending, I suppose, on how DiscourseConnect is configured).
Once a user is in the door, I would expect they are more likely to visit the corresponding forum topic to get all the Discourse-based discussion functionality. I just hope all those difficult parts of the problem don’t impede solving for the “first comment” problem. Having thousands of comments that we have to figure out pagination for would then be a “good problem to have.” 
4 Likes
This is enough to me cause did new and old users will participate and engage each others to It’s not a big deal to me a external
Yeah, that’s a genuine concern. The first step is to get a demo site online. Having a live site to test things out on should make it obvious what the points of friction are.
It might be technically possible to allow anonymous users to comment on posts. The only non-hacky way I can think of would be to have the comments posted on behalf of the anonymous user by a real user. That feels a little weird though.
I know that WordPress has a setting to allow “guest” users to create comments. It comes with the limitation that a “guest” comment will not be associated with a real user if the user who created the guest comment registers on the site after creating the comment. Posting “on behalf of” a user would have to function in a similar way - there wouldn’t be a way knowing that the user who created the anonymous comment was the owner of the email address they’d supplied with the comment.
Ideally, users will be authenticated either on the external site or on Discourse before creating a comment.
From a user’s point of view, the least possible friction would be for the case where the external site is the SSO provider for Discourse. That would make it possible for them to comment on Discourse topics without ever having to visit the Discourse site.
From a site owner’s point of view, the technically easiest way to authenticate users would be to have Discourse function as an auth provider for the external site. That’s the configuration that I’m currently using on my local test site. The external (Remix) site doesn’t even have a users table. It just creates a user session based on the response from Discourse /session/sso_provider route.
The downside of using Discourse as the auth provider for the external site is that it forces users to go through the Discourse register/login process. There’s nothing wrong with that process, except that it seems to force users to download all the Discourse assets when they might just want to leave a comment on the external site. So it’s kind of slow. I’ll investigate more…
It would Maybe reduce that to 100s for a more realistic scenario. The point I’m trying to make is the problem gets complex once you go beyond 1 page of posts (20 posts).
Edit: it might be possible to use Discourse invites to streamline the process - if an anonymous user wanted to comment on a post, there would be an email field displayed along with the comment form. Submitting the comment would trigger Discourse to send an invite to the email address. The comment would be held in a queue until the invite was accepted. This would let users create the comment when they felt the inspiration and give them immediate feedback about the status of their comment.
4 Likes
I’m excited to see what @simon’s solution is here.
I just wanted to note that a solution that’s developing on a different track on this front is to use ActivityPub. In its latest release, the official Wordpress ActivityPub plugin added support for the Discourse ActivityPub plugin.
This means that if you have the Wordpress ActivityPub plugin installed and the Discourse ActivityPub plugin installed, all you need to do is set up a category to “Follow” a wordpress actor making a post (or the whole wordpress site) and your wordpress posts will appear as new topics in that Discourse category.
(note that the Wordpress plugin has a publication delay, which is why it takes a minute for it to appear in Discourse in the video; skip to 1:40 to see it appear).
The Wordpress ActivityPub plugin supports Activity ingestion too, and is already setup to process incoming activities in reply to a post as a “Comment” on that post, however that particular part is not yet working with the Activities being sent out by the Discourse plugin (I think the Wordpress plugin doesn’t support announced notes yet). But that should work soon too.
See further
6 Likes
Note that Matthias, the maintainer of the Wordpress plugin has got this working, so there should be support for publication sharing and native two-way commenting between Discourse and Wordpress (via ActivityPub) soon.
3 Likes
This topic started with the idea that a Discourse powered comment system could provide similar functionality to Coral, with the added benefit of allowing website comments to branch off into regular Discourse topics. Discourse is providing the ability to moderate a website’s comments and allowing discussions related to the comments to occur on the forum.
I don’t think the need for moderation needs to be argued for.
The need for allowing comments to branch off into actual Discourse topics might be less obvious. I’m working from the assumption that having any sort of online conversation is difficult - in-person conversation provides all sorts of subtle cues that don’t exist online. Having meaningful online conversations with more than a handful of people is next to impossible. That’s where Discourse comes in. Discourse’s group functionality provides the ability to limit who can participate in a topic. Groups of commenters can be allowed to participate in walled-off Discourse topics. This is kind of the opposite to how the fediverse works.
That said, I’m curious about how Discourse/WordPress fediverse integration could work. For example, if Sally comments on Bob’s WordPress post, what would be expected to happen to Sally’s comment if she had a Discourse account? What could be expected to happen to Sally’s comment if she didn’t have a Discourse account? Is there any way that Sally could opt out of having her comment published to the fediverse?
Getting off topic, but with the various online-harms types of bills that are being implemented or proposed in western countries, if Sally’s comment is deemed to be offensive, who is responsible for publishing it? I’m assuming that’s an unanswerable question at this point.
3 Likes
Interesting!
The way I would suggest thinking about how ActivityPub works with both moderation and grouping (and other rubrics of online communication) is that it’s primarily a communication standard. It provides some mechanisms to handle those questions, but largely leaves them up to the various clients in the system.
Email as a communication standard is an imperfect, but perhaps useful, analogy. “Email” is collection of communication standards that allows you to exchange messages with anyone on the internet. It has various “quality control” issues, e.g. spam. There are some aspects of the collection of standards we call “email” that help to deal with those issues (e.g. DMARC, DKIM, SPF etc), however perhaps the primary way quality control is dealt with is in the email clients themselves. Gmail became a popular email client partly because it arguably dealt with spam (and similar quality control issues) quite well.
Following the analogy through Discourse would be the “Gmail” of ActivityPub. All of the moderation tools, user grouping and other features that make Discourse a great discussion platform are (pretty much) still available within the context of ActivityPub. I’ll flesh that out by starting to answer your questions.
I’ll start by describing what happens then we can perhaps move onto the more nuanced questions. I’m going to skip over a lot of things here, with a view to answering the basics:
-
Sally’s comment is published as an ActivityPub object from Wordpress.
-
The object is ingested into Discourse and converted into a post.
-
If Sally’s “Actor” is associated with a user account in Discourse the post will be associated with that user account. If her Actor is not already associated with a user account, a staged user will be created from Sally’s actor and they will own the post.
You can see the above at work in this topic:
-
The Discourse category WordPress - SocialHub is following Matthias’ Wordpress.
-
Matthias posted a new article on his blog using his regular wordpress account.
-
That appeared in Discourse as a new topic, with the post being associated with a staged user associated with Matthias’ Actor
-
The way comments work is exactly the same.
Just to cover perhaps the most obvious question: Can Matthias reconcile the “staged” user created from his Wordpress actor and his normal Discourse user on that server?
The short term answer is that the Discourse plugin has an “Authorization” feature set that currently lets you claim your ownership of actors from other Discourse servers or Mastodon servers which merges any such staged users into your account (meaning you now own the posts in your main Discourse account). That feature set could be extended to Wordpress. I appreciate this is a bit wordy, and it might be easier to understand what I mean with this demo:
The longer term answer is that identity proofs may be baked into ActivityPub activities at some point, perhaps removing the need for user-driven authorization, meaning the “reconciliation” could be (more) automatic.
Perhaps another question is whether “reconciliation” is necessary, given that Matthias still controls the identity attributes of his staged user via his ActivityPub Actor (which is editable on Wordpress, the edits of which filter through to the staged user on Discourse).
I say most of this as a form of throat clearing, so we can move onto your more nuanced, and important, questions. I hope I’m making sense so far.
2 Likes
It’s making sense.
In terms of the moderation issue, I’m talking about using Discourse to moderate WordPress comments. That’s the functionality that would allow Discourse to be used in a similar way to Coral. This is easy to achieve if WordPress comments are actually Discourse comments that are published from WordPress to Discourse via the API. It just works out of the box. This allows for things like using any AI powered moderation tools that are provided by Discourse. I’m wondering if something similar could be achieved with WordPress/Discourse ActivityPub integration.
What’s the proof of identity for the staged user? Is their email address passed from the origin server?
For my (personal) concern about not wanting to publish content to the entire fediverse, it seems that it’s technically possible to setup a one to one ActivityPub relationship between a Discourse site and a WordPress site, but I wonder if this kind of defeats the purpose of the ActivityPub protocol.
Edit: it might be worth adding that the goal is to create a win-win relationship between a website and an associated Discourse forum. Discourse’s moderation tools are intended to provide reassurance that the website’s comment system is well moderated. The website’s comment section is intended to be used to seed the Discourse site with topics and users.
2 Likes
The post that is converted from the ActivityPub object has mostly* the same pre-processing and post-processing functions applied to it as a post created via the API. The entry point is different (i.e. an ActivityPub controller instead of the posts controller), but the way posts are created are mostly the same.
*In more technical terms, if you create a post via the API, the actual processing is done via the NewPostManager, which then hands off most of the work to the PostCreator. The main thing the NewPostManager handles (for our purposes here) is the review queue. Everything else is handled in the PostCreator
Currently the ActivityPub plugin skips the NewPostManager and hands it off to the PostCreator in it’s (i.e. the plugin’s) own PostHandler. I did this mostly to reduce complexity in the initial implementation. There isn’t an inherent reason why the plugin’s PostHandler couldn’t hand the post off to the NewPostManager and get benefit of the review queue checks.
In short, there isn’t a substantive difference between posts created via the ActivityPub plugin and via the normal API.
There’s a few layers to this.
-
Firstly, the POST from the origin to your server is signed using HTTP signatures to ensure that the request is indeed originating from the origin.
-
Secondly, each Actor (i.e. user) on that origin has a UUID, i.e. an id tied to their domain, unique in the fediverse. It looks something like this:
https://angus.ngrok.io/ap/actor/f4b517bf6f81dbddfad3e44a45c9619dEmails are not used in ActivityPub.
-
Each Activity (e.g. a Create of a post-like object) you receive is associated with an Actor id. And Each actor id can be resolved to Actor attributes.
-
So by the time you receive an “Activity”, e.g. the creation of a new post-like object, on your server, you know, according to the domain you received the activity from, the attributes of the Actor performing the Activity. You are trusting the sending domain here, but this is always the case to the extent, e.g. Discourse trusts Wordpress instances with the WP Discourse plugin to send the correct user attributes associated too.
So the staged user itself doesn’t need an identity proof per se, in the same way a staged user from email doesn’t need an identity proof.
The need for an identity proof arises when the real person associated with the ActivityPub actor, and another discourse account, like the example with Matthias above, wants to consolidate (or “reconcile”) their identity. They may not like that they have effectively two “users” on a single Discourse. I would note that, without such a reconciliation, they can control
-
The identity attributes of the ActivityPub Actor / Staged user via the source domain, e.g. by updating their Wordpress profile, those updates being federated and Discourse applying the same); and
-
The content associated with the ActivityPub Actor / Staged user via the source domain, e.g. by editing their Wordpress comment, an Update activity being sent out and then processed by Discourse.
But, nevertheless, they may feel it is “messy” to effectively have two users on Discourse. That is why the plugin has its “Authorization” feature set, to allow you to show that your normal Discourse user is associated with the ActivityPub actor with its staged user. This is currently done via platform-specific authorization mechanisms:
-
For Mastodon it is done via Mastodon’s OAuth API. It requires to you authenticate your account on Mastodon to prove you control the relevant actor.
-
For Discourse it is done via the User API. This is what is shown in the video in my previous post.
-
There are a few ways the same thing could be done for Wordpress, e.g. DiscourseConnect via the WP Discourse plugin. This is not yet implemented.
Once you prove you own the actor associated with the staged user, the staged user is merged with your normal user, their posts become yours, and any new Activities associated with that Actor automatically become yours. But this feature set is really more to improve UX and is strictly speaking not necessary. The real person behind these various users controls both the user attributes and their content from the beginning.
Yes, it is possible to channel the target of outgoing publications, and restrict the source of incoming publications. Whether or not this defeats the purpose of ActivityPub is debatable. Strictly speaking ActivityPub is just a standard. I would argue that there’s no reason why you can’t use the standard in this way. Historically ActivityPub has been associated with decentralised social networks, particularly Mastodon, which may be why you feel this kind of approach defeats the purpose of ActivityPub. But I would draw a distinction between the ActivityPub standard itself and its existing implementations here.
Moreover in this context I would note that, like email, what we call “ActivityPub” is really a collection of standards. The standards document that is titled “ActivityPub” has to be read alongside another standards document called “ActivityStreams”, which describes the main objects in play here. The ActivityStreams standard is more firmly “service neutral” than ActivityPub itself (i.e. less tied to decentralised social networks).
To use (another) analogy, blockchain as a technology is simply a decentralised ledger, the first time it was explained to me it made me think of the Torrens System of land registration, invented in the 19th Century (in Australia) for essentially the same reasons blockchain was invented (i.e. to prevent fraud in property transactions). But blockchain’s most popular implementation is Bitcoin, which has a (different) specific use, and certain cultural valences. The analogy is not the best, but one way to think about it is that Mastodon and decentralised social networks are to ActivityPub what what Bitcoin is to blockchain.
Indeed, one of the reasons I helped to set up a new W3C ActivityPub for Forums working group with NodeBB, Flarum and others is to try and shift the focus of ActivityPub integration from the existing implementations (e.g. Mastodon) to the concerns of forums, like those around moderation that you’re raising. We actually have our next meeting today. If you have time, I’d love to have a fellow “Discourser” (is that a term?) there
4 Likes
I’m talking about using Discourse’s moderation tools to moderate comments that appear on WordPress. Technically that could be done with a Discourse API request or Webhook - after a moderation action occurred on Discourse, a request could be made to change the comment’s status on WordPress.
Assuming things are changed so that ActivityPub posts get handled by the review queue, there’d still be an issue with the time delay between when the comment is initially published on WordPress and when it appears on Discourse. I believe that’s a couple of minutes?
For this particular case, one of the main selling points is “use Discourse to moderate your website’s comments.” It goes on to list Discourse’s moderation features, the trust level system, review queue, AI powered moderation tools, etc. These are tools that would be nice to have for smaller blogs, but a requirement for mainstream news sites. I’m thinking that the best way to achieve this is to use Discourse as the single source of truth for comments, instead of having comments exist on two (or more) databases.
That’s great! Without having time to give it more thought, I don’t think I’d be a great representative of Discourse.
I’ve got some general concerns around the idea of treating topics, posts, and users as just bits of data. There needs to be a way of making sure the context of where a discussion is occurring is not lost.
On a more practical level, the ActivityPub protocol took off before the introduction of the online-harms bills that are being introduced in various countries. There needs to be some assurance that servers that are consuming data from an origin will respect deletion requests. Otherwise, users who generate content on an origin server are risking legal repercussions if their content is later deemed to be harmful in their country.
3 Likes