I’m just catching up with this thread—but I certainly think the answer is yes
Because of the success of our enterprise community (both with our users, and within our business) our documentation team reached out and asked if we could build a comment system for all of documentation.sailpoint.com. From the looks of it, we’ll be able to do almost everything we want to accomplish at a bare minimum:
Embed comments (embedding feature)
We also want to use different users to post as, and apply different sets of tags, based on the embedding. This feature is coming very soon:
From there, everything else the docs team (and my team) wanted was within Discourse for us to effectively segregate this experience from the rest of our “day to day” forum usage, while still giving people the ability comment, get notified of replies, etc.
Ability to designate which users can and cannot comment
Assign category moderators to the associated topics
Suppress this plethora of categories for these docs from our main site
category not searchable
theme component used to hide it from main category list
suppressed from digest
added to default muted categories
Comments removed after n days
A few other settings…
I definitely would love to see many of the features mentioned here implemented, though!
Is the goal to allow users to create comments on https://documentation.sailpoint.com/, or are you ok with just embedding the comments on the docs site and having users visit your Discourse site to comment on articles?
The former is a feature I’d welcome and love to have (read: please build, CDCK), but the latter meets our minimum requirements, at least.
I actually will be exploring an idea in the near future of having Discourse serve up our markdown documentation (no, not in topics, but in traditional markdown-style docs) in which case comments, and signing up to make them, would be all-inclusive. But that exploration hasn’t begun yet.
With the approach I’m working on now, it would be technically possible to allow Discourse comments to be generated directly on MkDocs pages, but it would require using a server side framework (Remix, Rails, etc) to serve the MkDocs pages. That would make it possible to authenticate users (with DiscourseConnect) on the docs site and also allow an in-memory database to be used for caching previously returned comments.
(Edit: just to be clear, I’m talking about using Discourse as an identity provider for the website, not the website as the identity provider for Discourse. The latter approach works, but it’s too inflexible for most use cases.)
That would be a big change to ask your team to make though.
I’m sure from your perspective it would be more straightforward if this was accomplished entirely inside of Discourse, but it’s also possible to use Discourse as a content management system. In that case, the markdown documentation would be generated as regular Discourse topics. Discourse webhooks would be used to trigger the generation of a docs page on an external site. That’s actually the basis of the Discourse comments demo site I’m setting up.
Since this topic was linked to today, I figured I should update it with the conclusions I came to after putting some work into the idea.
I still think Discourse would make a good comment platform for the reasons I outlined in the OP.
In terms of how to do that, I think the work needs to be done on the Discourse end - ideally by improving the Discourse comment embed script. This could be done incrementally.
It’s technically possible to use Discourse as the server for a comment platform by doing all the work on a Discourse client (for example, the WP Discourse plugin), but due to having to manage the state between the client and Discourse, and get around rate limiting issues, it turns into a complex problem. It’s definitely more complex that something I want to be responsible for maintaining.
A few posts in this topic indicated that people would be interested in just allowing users to create Discourse comments on a blog site. From my point of view that’s not a great solution, but it can be achieved now with the Discourse API. Where things get complicated is in trying to create a full comment system, where users can interact with Discourse comments on a website in a similar way to how they’d expect to interact with comments on a typical mainstream news site.
Given my experience with ActivityPub and WP Discourse I think two-way commenting via embedded javascript is achievable. The embed script would contain the following:
Unauthenticated “read” working in a similar fashion to current js embed (with some optimisations).
Remote client (i.e. the user’s browser) registers a user api key client, specific to the user’s session and stores relevant details in the browser’s local storage.
User is presented with “Login to comment”.
User authenticates (with Discourse) to retrieve a session user api key which is stored in the browser’s local storage.
Each activity (comment, like, etc) is directly posted to a dedicated endpoint with appropriate safeguards, handling and task management.
With the right budget I think I could get v1 production ready and integrated with discourse/discourse in 6-8 months. Following on from initial release I could do the following:
Add explicit support for Wordpress, Ghost and other select platforms.
Try to implement it in a way that makes sense for non-technical users. Existing platforms like Disqus and Facebook comments probably offer good examples.
Some more authentication options:
the client site becomes a DiscourseConnect client. This is straightforward to implement, but requires added server side code to the client site.
My reluctance to developing this purely on the client side came from considering the problems of the system working at any kind of scale. Essentially, I was having to queue API requests and handle responses from queued requests. It didn’t feel robust enough to deal with, say 1000 concurrent users. I’d have similar concerns, but for different reasons with the javascript embed approach. I suspect it would be much easier to deal with than trying to synchronize everything on the client though.
I gave this some more in-depth thought yesterday as the topic was bumped (which is why I ended up posting here). I think a client-only solution (i.e. a javascript embed) is the only one that really makes sense here. Otherwise we’re essentially talking about a number of platform-specific implementations, each with their own set of issues.
You’re right that concurrency and load are issues. There are significant load and concurrency issues with ActivityPub as a single ActivityPub post can open you up to many incoming and outgoing requests to and from the Fediverse. In that context, this may be actually slightly easier as the remote client(s) are controlled. Moreover, in this case, concurrency and load are only really issues on the server side (i.e. the Discourse side), and, while they are issues, I think they should be solvable via background jobs, caching and mutexes. But yes, important issues to consider.
Composer v2 is just around the corner, it would be crazy to embark on this adventure and not lean on our new composer but there is a mountain of work we need upfront to make using it in a lightweight app feasible.
I think the right thing to do here is to watch this space for new composer for say 2-3 months and then revisit the question.
I think it can be done in parallel. You need to make 2 changes to the discourse.
The “Reply” button should be visible to unregistered users.
And when unregistered users click on this button, this should be displayed:
Next, you need to figure out how to use comment insertion. These are likely to be small code changes rather than a lot of work.
I’m wondering if there is still interest in developing this feature, now that Composer v2 is out. Putting my vote in that it’s still something I’d love to see and use.
