Issue #213 - UI - Initial support for ActivityPub comments

[dellagustin]

This commit introduces initial support for showing comments. It relies on the API also including socialInteracts and on a new API on the server being implemented to fetch the comments.

This is not yet ready, I have implemented some mock code on the server side that is not included in this commit.

The front-end code expects the comments API to respond with the same format as podverse's /api/v1/episode/{episodeid}/proxy/activity-pub, which is exactly what is returned by threadcap.

To Do

• Sanitize content html - done with 07207d2
• Fetch comments on the server using threadcap - done with bdf237e
• Add state for "loading comments" - currently is taking circa 7s, so there is a noticeable wait - done with 5282362
• Solve the react warning Warning: Each child in a list should have a unique "key" prop. - done with 22f868b
• Define global constant for user agent - done with 2f826a7
• Use socialInteract from the API, when it becomes available - done with f2037c2
• Show comment publication date and time - done with b48dc1b
• Support language-tagged values - see Issue #213 - UI - Initial support for ActivityPub comments #218 (comment) - done with 608dcfb
• Implement @nathangathright's design - Issue #213 - UI - Initial support for ActivityPub comments #218 (comment) - done with - b48dc1b
• Support summary (stretch goal)- see Issue #213 - UI - Initial support for ActivityPub comments #218 (comment) - done with 094393d
• Fix content overflow issue (stretch goal) - see Issue #213 - UI - Initial support for ActivityPub comments #218 (comment) - done with d33af68

Limitations

Performance

When this PR is ready for merge, it will still be limited to fetching all comments in a single shot, and the UI will wait until they are all fetched, which can take some time.

A potential improvement would be some kind of "long pooling", where the server sends partial updates back each time a new comment is fetched. This way the UI could be progressively updated. Maybe this can be achieved with https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams.

I have created an issue to track this future improvement: #228

Summary / Content warning

The property summary is not taken into account, which is returned by Pleroma and Mastodon posts as a Content warning (e.g. to avoid spoilers). This is, to my best knowledge, also a limitation of threadcap (see skymethod/minipub#6), not anymore, see #218 (comment). I set this now as a stretch goal, could be easily added later in a compatible way with a separate PR, if this one is dragging too long.

Attachments

Attachments are currently not shown (e.g. attached images).

I have created an issue to track this future improvement: #229.

Scaling

As all the API calls are going out from the same IP, if many users are checking comments in parallel, they could reach the instances' rate limit. For instance, the default for Mastodon instances is 300 calls within 5 mins (mastodon rate limits).

Related issues

• resolves Add support for comments #213

Dependencies

• the content of the socialInteract tag must be returned by the API
  • Include socialInteract (comments) data on the episodes returned by the API docs-api#91
• (weak dependency) created Threadcap: Add support for the "summary" property skymethod/minipub#6
• (weak dependency) created v0.1.10 seems to be non-backwards compatible, summary is treated as mandatory skymethod/minipub#7

Links and References

• socialInteract at the
• Fediverse threads
  • Main thread discussing this issue
  • Promotion for this issue by @daveajones
• Support Podcasting 2.0 ActivityPub comments podStation/podStation#304
• Activity Streams 2.0 / ActivityPub
  • https://www.w3.org/TR/activitystreams-core/
  • https://www.w3.org/TR/activitystreams-vocabulary/
  • https://www.w3.org/TR/activitypub/

[dellagustin]

Additional server side code I'm using at server/index.js, to mock the API data:

const fakeCommentsResponse = require('./fake-comments-response.json')

app.use('/api/episodes/byfeedid', async (req, res) => {
    let feedId = req.query.id
    let max = req.query.max
    const response = await api.episodesByFeedId(feedId, null, max)

    // Injects fake socialInteract content here for testing
    response.items.forEach((item) => {
        item.socialInteracts = [{
            uri: 'https://podcastindex.social/users/dave/statuses/109683341113064081',
            protocol: 'activitypub',
        }]
    })

    res.send(response)
})

// ------------------------------------------------
// ------------ API to get comments for episode ---
// ------------------------------------------------
app.use('/api/comments/byepisodeid', async (req, res) => {
    let feedUrl = req.query.url
    // fakeCommentsResponse was taken directly from the API used by podverse
    res.send(fakeCommentsResponse)
})

For server/fake-comments-response.json I simply inspected the return of the API in podverse and copied the response body.

Current result:

[dellagustin]

@daveajones, we'll need to sanitize the content of the comments, do you have any library recommendations?

[daveajones]

Threadcap doesn't sanitize?

[dellagustin]

Threadcap doesn't sanitize?

@daveajones I'm not sure, but I am assuming it doesn't. I could not find information indicating whether it does or does not on the documentation. I asked @johnspurlock-skymethod, see skymethod/minipub#5 and https://fosstodon.org/@dellagustin/109771551290816322.

Now that's the server is doing requests to 3rd party servers, we should define a user agent. Do you have any preferences on this one?

I'll move forward with missing pieces, but soon it will be blocked only by Podcastindex-org/docs-api#91.

Could you do a "call to action" for the community to contribute on the "beautification" part? Maybe on the next Podcasting 2.0 episode? This is a part were I'm very weak.

[dellagustin]

Current error handling:

[daveajones]

I will 100% do a call out on the next board meeting. For user agent I typically use Podcastindex.org/v1.x so maybe something like:

Podcastindex.org-web/v1.0 ?

[Clay-Ferguson]

@daveajones, we'll need to sanitize the content of the comments, do you have any library recommendations?

I recommend DOMPurify NPM module for sanitizing. I have been using it in my project "Quanta" for a while.

[dellagustin]

One current limitation, I'm only taking into account English language content.

threadcap returns the content of the comments as language-tagged strings:

"content": {
          "en": "content in English"
        }

I'm currently hardcoding to English.

Note that the content on the Activity is not always language-tagged, and when it is, this is under the property contentMap instead of content.

e.g.:

"content": "content in English",
    "contentMap": {
        "en": "content in English"
    },

I was remembered about this when testing with a reply from a different account where it is not set to English (simplified example below):

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://blob.cat/schemas/litepub-0.1.jsonld",
        {
            "@language": "und"
        }
    ],
    "content": "Content in und",
}

Note that in the absence of a contentMap threadcap seems to be building one from content and @language.

[dellagustin]

@daveajones

Podcastindex.org-web/v1.0 ?

Sounds good to me. Is it ok if I read the version from package.json to build the final user agent?

[dellagustin]

Design by @nathangathright: https://codepen.io/nathangath/pen/jOpvKJo?editors=1000

[nathangathright]

I’ve just updated the CodePen with a custom disclosure chevron, better support for Safari, and some space-saving mobile enhancements.

[dellagustin]

@nathangathright my mouse pointer is going a bit haywire on the clickable elements of the UI at the current version, but it may be a codepen thing, let's see if it happens when I implement it in PI.
It shows a hand cursor as if it was clickable, but if I let it there it goest back to being an arrow.
I'll probably leave the <relative-time> usage out of this PR as it adds another dependency, if I understood it correctly, and implement it afterwards with a dedicated PR.
Is this this the one you used, https://github.com/github/relative-time-element?

[dellagustin]

So an expectation management message: as you can see, the To Do list is packed. What I did so far was during a "time multiplexing window" that I dedicate to this project, now I have to do the same to other projects 😄 . Also, I have the feeling we are at a "80% of the functionality with 20% of the effor" point. In other words, what is left may take more time than you would expect to be ready. I'm guessing something like 4 weeks with me "multiplexing" between projects and life. Let's see.

[johnspurlock-skymethod]

The property summary is not taken into account, which is returned by Pleroma and Mastodon posts as a Content warning (e.g. to avoid spoilers). This is, to my best knowledge, also a limitation of threadcap (see skymethod/minipub#6).

Just for you Guilherme, this morning I added summary to the comment payload in the latest version of Threadcap - version 0.1.10

[nathangathright]

@dellagustin Yeah, cursor:pointer on absolutely-positioned pseudo-elements might not be the best idea. Given that all interactive elements don't need a hand cursor, I’ll remove that affordance.

I’ve pushed an updated code to a stand-alone repo with GitHub Pages so you can see the behavior without CodePen’s interference. Additionally, I’ve mocked up what Summarized/Content Warnings could look like.

https://nathangathright.github.io/comment-thread-mockup/

[nathangathright]

I'll probably leave the <relative-time> usage out of this PR as it adds another dependency, if I understood it correctly, and implement it afterwards with a dedicated PR. Is this this the one you used, https://github.com/github/relative-time-element?

Yeah, that’s fine. Just replace that custom element with the HTML5 standard <time> element. And yes, I just used unpkg to include GitHub’s package as a module at the bottom of the page, and everything else took care of itself.

[dellagustin]

@johnspurlock-skymethod , @nathangathright you both have to slow down on your great and timely contributions, it is making me look bad 😛.
Seriously now, the teamwork here is amazing, open source Christmas came early this year for me. I cannot wait to get this finished and integrated, it will be awesome!

[dellagustin]

@nathangathright , one note about the Content Warning, event though that the semantic for summary used by (at least) Mastodon and Pleroma, they show this in a very "neutral" way, meaning: they call it Content Warning when your are editing, but they don't refer to it when they are showing it, they just hide the content under a Show More/Show Content user interaction. Screenshots below.
I like this neutral approach in the context of ActivityPub, as the Activity Vocabulary does not define a way to represent content warnings or spoiler alerts (that I could find), so summary is intended to be just a summary, and the neutra approach does not go against that.
In summary (😜), I suggest our implementation support summary in a similar way, just show the summary and have a Show more or Show content button.

[dellagustin]

Testing with threadcap v0.1.10 showed a regression, reported with skymethod/minipub#7.

[dellagustin]

@nathangathright , I just implemented the support for summary. When I saw that your css trickery saved me from managing the state of Show More / Less, I was relieved!

[dellagustin]

I have been thinking about how stream back the comments processed by threadcap to the front-end, so that the user does not need to wait for the threadcap to finish its work to start seeing comments.

The idea is to use the threadcap callback and send back a JSON with new nodes and and commenters each time there is a node-processed event for a comment, then rebuilt the response on the frontend based on these chunked updates and update the state each time a chunk arrives.

[dellagustin]

Indication that comments are loading is there:

Ugly, but it works 😄
@nathangathright , if you feel like beautifying that, come along.
Also, did you see my overflow message from earlier - #218 (comment)?
One more TODO to go and the blockers from my side would be gone - I'm racing @daveajones here, hoping to finish this before he finishes introducing socialInteract to the API 😜.

[nathangathright]

@dellagustin The CSS for the summary element didn't account for display names + handles + long timestamps. Adding width:100%; overflow:hidden; on that element would patch the problem.

But I’ve gone a bit further and pushed an update to my little repo with stacked name and handles on desktop and hiding the handles on mobile.

(I still think handles are unnecessary given that you can click through to the original profile to verify anyone’s identity.)

[dellagustin]

Hello @nathangathright , thank you for the changes. I can see they work well in your standalone mock up, but when I implemented them inside the podcast index, it still overflows, here is a screenshot:

[dellagustin]

Fixed it by adding width: 100% to an outer div I added with the comments section.
I did remove the body CSS that came with @nathangathright 's mock up, as I feared it would affect the rest of the site somehow.

[dellagustin]

Content sanitization added with 07207d2 using DOMPurify.

To test it, I faked the response of /api/comments/byepisodeid
with a hard coded json file containing in the content of comments
some examples from the section "Some purification samples please?".

References:

• https://www.npmjs.com/package/dompurify

[dellagustin]

@daveajones , ready for review 🎉 .
special thanks to @johnspurlock-skymethod and @nathangathright for the help with threadcap and the design and code for the frontend.