Social Media Previews

[bedeho]

We would love to be able to embed Atlas videos on twitter, and even facilitate playback, to this end we are interested in determining

1. what is required by Twitter to allow this,
2. what is the best way to accommodate these requirements in the Atlas code base.

Please write up proposal as reply to this issue.

[DzhideX]

With regards to #1:

To facilitate Atlas video playback on Twitter we essentially need to add some meta tags that will let Twitter know which content to use. Currently, Atlas doesn't support Twitter cards at all, meaning that when I share an Atlas link there is no content being shown other than the link itself.

While we're implementing video playback it might also be a good idea to implement support for what Twitter calls Summary Cards. This would mean that whenever we share the link to atlas, we would get a picture, title and some description rather than just a link that would leave the user guessing what it could be. Example from when you share a joystream-org link:

To do this, the Summary Cards link above explains everything in detail but here are the essential tags we would need to implement (example content from joystream-org):

<meta name="twitter:card" content="summary" />
<meta name="twitter:title" content="Joystream: The video platform DAO" />
<meta name="twitter:description" content="Joystream is a video platform controlled, owned, and operated by its users." />
<meta name="twitter:image" content="https://joystream.org/static/logo-twitter-83dd2bd29f9900bbf4b4d50f8662d9a8.png" />

Now, for Player Cards (cards with video support) we would need to implement some more tags. All of this is explained very well under "Reference" towards the bottom of the Player Cards link but the essentials would be:

twitter:card, twitter:title, twitter:site, twitter:player, twitter:player:width, twitter:player:height and twitter:image

With regards to #2:

The most popular (by # of downloads) solution for adding dynamic content into the head of the html document would be react-helmet. This library is also used in joystream-org and where have a component called SiteMetadata that has default values and we put it at the top of each new page we make and adjust the title and description to match the page we're on. We could probably do something similar here.

Now, I could make some assumptions about how and where to implement this inside of Atlas but I think @kdembler could probably do this much better as his knowledge of the codebase is more extensive than mine!

[kdembler]

I think this may be slightly more complicated than this.

To begin with, I agree summary cards are a great place to start. We actually already have an issue about that: https://github.com/Joystream/atlas/issues/75 Video cards would certainly be an even better experience!

---

Having said that, the technicalities can be a bit complex. Let's use a video page as an example

Just for any kind of preview (Summary):

• A good question to ask is how does the Twitter crawler work. When you open a link to the video, the content won't be available right away, we need to first fetch the data from the query node. So for some time (should be <0.5s of loading), we won't be able to populate the tags because we won't even know the video title. Will Twitter handle that gracefully or will it just give up after tags aren't there right away?
• Assuming most of the assets will be hosted by the storage system, we will need to choose some provider that should be used for URL access. I guess we can just default to the liaison and I also guess Twitter will cache the image on its servers but that should be worth confirming

Then for the video preview:

• All of the above applies
• For the playback it seems we would need to support an embedded player - providing a link to the video won't be enough since Twitter will allow users to play content right in the card, so it needs to render our player inside their app. You can see what Youtube provides - https://www.youtube.com/embed/Kauv7MVPcsA. Thing is, I'm not 100% sure this is possible with our current setup and again depends on how smart the Twitter crawler is. What we could is have a separate view in the app, like /video/embed/123 and render only the player inside it. The question is, whether Twitter will accept that as it involves SPA setup, some loading, browser-side routing etc. May or may not be easy to do, we'd need to investigate
• We probably would need to improve our mobile video player (since I guess the embedded player on Twitter won't have much space). Right now the experience is okay-ish

[DzhideX]

Thank you for the detailed answer, I really appreciate it! Here are my thoughts on it:

Summary Cards:

• Not sure I follow, at least in regards to the summary cards. I think we could do the same thing we do on joystream-org as the data there is technically "static". At least initially, we can have every route show the same image but change the title and description to some predetermined, hard-coded text (that is, if you consider this sort of preview acceptable).

• This should be fairly simple and quick to do (unless I'm missing something..) which is a big plus considering atlas doesn't have any kind of preview at the moment. At the moment I think this makes the most sense for the /,/videos,/channels routes because we don't really need any dynamic data for these.

Player Cards:

• When it comes to the video preview, I've also had similar thoughts, at least when it comes to the fact that the video data won't be available immediately. I'm not really sure how twitter would deal with that. Further investigation is definitely necessary.

• On your other points, I misunderstood the api initially and thought we could just link the video but I think you're right. We would probably need a separate view for this. Also, more investigation necessary.

So, from my POV I think it would make the most sense to implement that basic/static summary card on the three aforementioned routes and then we can move from there and see if it is possible to have a player card with the current state of the app or if more changes are necessary. Thoughts?

[kdembler]

Not sure I follow, at least in regards to the summary cards. I think we could do the same thing we do on joystream-org as the data there is technically "static".

That depends on what routes you mean. For /, /videos and /channels, I agree, the summary will be static. However, the most value would probably come from summary for the non-static sites. I suppose if someone is sharing something on Twitter it's much more likely that it's a specific video/channel than videos/channels list.

I propose we do this with the following milestones: 1) Summary cards just for the static pages - we learn how Twitter deals with JS-injected meta tags 2) Summary cards for dynamic content pages (/video/xxx and /channel/xxx) - we learn how Twitter deals with async content and whether this is actually possible without something like SSR 3) Player cards for videos

[DzhideX]

Yeah, that makes sense. I agree with the milestones as well!

What do you think would be the way to approach this? In my opinion it would make the most sense to make an issue with 3 "tasks/todos" and then slowly tick them as I go through the tasks. That would be 3 separate PR's as well which should also make the review process easier.

Also, to what branch should I make the PR?

[kdembler]

3 tasks with 1 PR/task certainly sounds good!

I think you can base your work on master, it's not really dependent on any work we do currently for sumer

[DzhideX]

Update(summary):

The desired functionality is that when linked a play.joystream.org video on twitter/other networks, we want a video player to appear for specific video links and a generic card to appear for routes like /,/videos,/channels, etc. To do this we would need to dynamically update html meta tags and supply them with information not really available to us initially (i.e. video information that needs to be fetched) and this async action would take some time.

I initially thought that we could just do this client-side and this technically would be possible but twitter crawlers would not be able to see it because they would have to download and run the javascript themselves. They don't have that functionality at this point in time.

The solution to this problem is SSR(Server-Side Rendering) which essentially means that the server will do all the necessary work and just serve the html on the necessary route. This means that we can serve the html along with the necessary meta tags on request and the crawlers don't have to do any work themselves.

@kdembler I also found this idea that could(*) help us maybe get around doing SSR. I'm not sure what the implications on doing this for something as complicated as Atlas would be (i.e. would it even be possible)?

[kdembler]

Thanks for the summary!

My two cents - I see two solutions two move forward with this:

1. Like you mentioned, fully embrace SSR - this would come with its set of implications (both positive and negative) and would be most likely quite time-consuming
2. Something along the lines of your second suggestion - we could serve Atlas app from some proxy (nginx, etc). This proxy could check for the user agent on the request - all the crawlers should identify themselves. If the user agent is a crawler, we return an empty HTML with just the meta tags populated with a backend function. Otherwise we just serve the static files.

[kdembler]

Closing in favor of #1785