Comments: Add button / icon to open the original post in a new tab

[dellagustin]

Currently the only way to comment on the podcasts in the podcast index is to copy the link of the post and use it to find it in the instance where the user has and account.

The only way to get the original post link, currently, is to copy it from the timestamp. Having a link to the post/comment is a comment UX practice, but it is kind of a hidden feature, as it is not that intuitive.

I suggest that we add a more clear indication on how to open the original post or copy the post link.
A common icon for opening a link in another domain is like the one shown in the screenshot below:

Related issues

• Comments: reply to comments on the podcast page #233

Links and References

• Matodon thread - https://social.oberhauser.space/@obale/109961887303322180

[dellagustin]

New mockup from @nathangathright : https://xoxo.zone/@nathan/109973226991064790
live: https://nathangathright.github.io/comment-thread-mockup/
nathangathright/comment-thread-mockup@6b2f716

[ericpp]

This looks great! Should also check if this works well on mobile. Popup dialogs like this tend to be difficult to use on mobile devices.

[dellagustin]

I was looking into the code today.
Since dialog requires the javascript method showModal is used to show the dialog, I'm assuming it does not work well with React. The fact that there are react components for modal stuff is likely an indication that this is complicated.
I'm tempted to use a simple prompt instead.
Also, I'll have to include an option to remove/update the saved home instance, otherwise it would be a "write once" scenario.
Aside from that, I think I understood the stuff.

[nathangathright]

The dialog element and showModal method are newer elements, but they’re available in all major browsers. I’m unclear why you think this will be an issue with React.

I actually did make a version with prompt first, but it had a major drawback: it was blocked by the browser’s popup blocker. Since I couldn’t set an EventListener on the submit button of the prompt, trying to open a new window after a prompt didn't appear to be in response to a user event, and it was blocked.

I think a way to clear the localStorage would be nice, but was unclear where we’d like to expose controls for that. Maybe we could just store it as a cookie with a short expiration date. Otherwise, asking the user to clear it manually isn’t that complicated:

[dellagustin]

Hi @nathangathright ,

I think a way to clear the localStorage would be nice, but was unclear where we’d like to expose controls for that. Maybe we could just store it as a cookie with a short expiration date. Otherwise, asking the user to clear it manually isn’t that complicated:

I thought about adding an extra item in the menu, like "forget my account home instance" or something like that.
Contextually it is not an action that belongs to any individual post, but in the other hand, it would easily educate the user on how to do it, so I think it is an ok approximation.

I’m unclear why you think this will be an issue with React.

Take into account I'm writing as someone that learns React on demand (i.e. the minimum I need to contribute).
React is state based and more descriptive and reactive (as per its name 😄) then imperative.

You typically don't give commands like showModal or show, but you change the state to with a property like isShowing and adapt your rendering method to deal with that. So I'll need to research a bit what is the best way do this in react.

Thanks for clearing out the drawback on using prompt.

[dellagustin]

Regarding the remote interact (i.e. follow, reply, etc...), the patterns https://${instance.hostname}/authorize_interaction?acct=${username}
and https://${instance.hostname}/authorize_interaction?uri=${url} are not a standard, they work for Mastodon and may work for some other instance "types". I consider it an ok first implementation, but moving forward it would be good to have something based on standard protocols.
To my best knowledge, the state of the art is to use WebFinger to find out the OStatus subscribe URL for the Actor (I'm not sure which one, the interactor or the "interactee"). My understanding is that this is intended only for subscriptions (i.e follow), but that many instance "types" (tested with Mastodon and Pleroma) also can use it for redirecting to a post, as represented in their instance, for further interaction (e.g. boosting, favoriting, bookmarking, liking, replying, etc...).

Here are some references:

• https://socialhub.activitypub.rocks/t/represent-endpoint-for-remote-interaction/480
• https://socialhub.activitypub.rocks/t/what-is-the-current-spec-for-remote-follow/2020
• https://socialhub.activitypub.rocks/t/cross-instance-interactions-determining-the-kind-of-action-user-wants-to-perform-to-a-remote-object/734
• https://www.hughrundle.net/how-to-implement-remote-following-for-your-activitypub-project/
• WebFinger Spec - https://www.rfc-editor.org/rfc/rfc7033
• https://en.wikipedia.org/wiki/OStatus

@nathangathright , if you have any good references for this, please share.

[dellagustin]

I did some more tests with the WebFinger protocol to get the remote interact URL pattern.
To do the WebFinger request I need to pass the account of an existing user in the instance where the interaction will happen.

As far as I can tell, the remote interact URL pattern does not change from user to user, yet we will need to pass a user to get it.

We'll have to prompt for the account of the user initiating the interaction then, not only the instance host.

Example

I want to
interact (e.g. comment) with the post https://podcastindex.social/@dave/110237990624503755 from my account, [email protected].

I need to send the request https://fosstodon.org/.well-known/webfinger?resource=acct:[email protected], it will return:

{
    "subject": "acct:[email protected]",
    "aliases": [
        "https://fosstodon.org/@dellagustin",
        "https://fosstodon.org/users/dellagustin"
    ],
    "links": [
        {
            "rel": "http://webfinger.net/rel/profile-page",
            "type": "text/html",
            "href": "https://fosstodon.org/@dellagustin"
        },
        {
            "rel": "self",
            "type": "application/activity+json",
            "href": "https://fosstodon.org/users/dellagustin"
        },
        {
            "rel": "http://ostatus.org/schema/1.0/subscribe",
            "template": "https://fosstodon.org/authorize_interaction?uri={uri}"
        }
    ]
}

I'll get the template from the link with rel equal to http://ostatus.org/schema/1.0/subscribe, then replace {uri} with https://podcastindex.social/@dave/110237990624503755, and open the resulting url on the browser. This should open the post in my instance so that I can interact with it there. A login flow takes place if I am not logged in yet.

[dellagustin]

Some more test results of the URLs resulting of the approach above:

• https://fosstodon.org - Mastodon - v4.1.2
  • 👍interact with post - https://fosstodon.org/authorize_interaction?uri=https://podcastindex.social/@js/110238757531058833
  • 👍interact with user - https://fosstodon.org/authorize_interaction?uri=@[email protected]
  • 👍interact with user - https://fosstodon.org/[email protected]
  • 👍interact with user - https://fosstodon.org/authorize_interaction?uri=https://podcastindex.social/@js
• https://blob.cat - Akkoma - 3.3.1-0-gbba467b39-blob (a fork of Pleroma)
  • 👍interact with post - https://blob.cat/ostatus_subscribe?acct=https://podcastindex.social/@js/110238757531058833
  • 👎 interact with user - https://blob.cat/ostatus_subscribe?acct=@[email protected]
    • "Error fetching user"
  • 👍interact with user - https://blob.cat/[email protected]
  • 👎interact with user - https://blob.cat/ostatus_subscribe?acct=https://podcastindex.social/@js
    • HTTP ERROR 500

The common denominator so far for interacting with users (e.g. follow) is to replace {uri} with the user account in the format user@host.

[dellagustin]

Implemented with #253.