search

Podcastindex-org / web-ui

The public home page of podcastindex.org
MIT License
52 stars 116 forks source link

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

Closed dellagustin closed 1 year ago

dellagustin commented 1 year ago

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: image

Related issues

Links and References

dellagustin commented 1 year ago

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

ericpp commented 1 year ago

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 commented 1 year ago

I was looking into the code today. Since dialog requires the javascript method showModalis 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 commented 1 year ago

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: CleanShot 2023-03-10 at 07 34 32

dellagustin commented 1 year ago

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 commented 1 year ago

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:

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

dellagustin commented 1 year ago

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, dellagustin@fosstodon.org.

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

{
    "subject": "acct:dellagustin@fosstodon.org",
    "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 commented 1 year ago

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

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 commented 1 year ago

Implemented with https://github.com/Podcastindex-org/web-ui/pull/253.