Investigate Feasibility: Social Sharing Previews

[apbendi]

Social Sharing Previews for links to poll results pages should show

• Poll Title
• Winning Or Leading Option
• Winning Or Leading Option Vote Percentage By Token Weight

Example:

Might show something like:

POAP VOTE

Devcon IV Location
Buenos Aires (83%)

Note: The feasibility needs investigation here. Social previews are generated from header metadata. How easily can we populate this dynamically? It may be prohibitively difficult without a costly architecture change. We will investigate this

[mds1]

Ok, some notes on this below. Let me know your thoughts feedback on everything.

Page Title

Changing the page title is easy, and I think we should do this anyway since it is very simple. Though it may or may not change social sharing link previews. Suggested titles to use:

• "Vote: | POAP Vote" for the vote pages (or do you prefer Cast)?
• "Results: | POAP Vote" for the results pages
• "Home | POAP Vote" or "View Polls | POAP Vote" for the home page.

See example image below:

Previews

Getting more specific than just the title gets tricker. The good part is pretty much every uses The Open Graph protocol (TOGP) to generate the previews. This requires special meta tags in the html head.

Some specifics:

• iMessage previews use TOGP
• Twitter previews use their own card metadata, but if not found it falls back to TOGP
• I couldn't find official documentation from WhatsApp or Telegram but from StackOverflow/other forum posts it seems they also use TOGP
• Discord previews also use TOGP
• Facebook previews also use TOGP

Setting a pretty preview using TOGP meta tags that is constant for all pages is easy, as we just hardcode the desired properties in our index.template.html file. As a result, we should probably do this also.

Doing this dynamically per-poll is not as straightforward.

From some googling, reading the Quasar discord server, and some forum posts it seems this requires Server-Side Rendering (SSR) (Vue SSR docs, Quasar SSR docs), where you "render the same components into HTML strings on the server, send them directly to the browser, and finally “hydrate” the static markup into a fully interactive app on the client."

SSR is required because otherwise meta tags are only loaded once the first time the app loads, whereas SSR lets you send the dynamic meta tags with the HTM on each page load. So you are correct—it does require an architecture change. (Other benefits of SSR are that it helps with SEO and reduces loading time on devices with slow internet connections).

Quasar does have a Meta plugin which will facilitate configuring TOGP tags on SSR.

If we do implement this feature, https://metatags.io/ is a good site for testing the implementation before deploying.

Estimated Work

Kind of like when you write upgradable contracts, writing for SSR requires special considerations and patterns. I read through the Quasar docs on what changes are required, and while it's a non-trivial amount of work, it doesn't seem like there's any dealbreakers. The important caveat is I've never worked with SSR before so of course there may be things I'm missing or unforseen problems.

The one potential issue is that browser-only globals have to be accessed in lifecycle hooks. So when we call window.web3 to get a signature we might need to do some hacky workaround for that, where we move that call into the mounted lifecycle hook of a blank component that has no html.

This would likely also change the server configuration for deployment, though I haven't looked into exactly how.

Having said all that, here's an hours estimate: I'd probably estimate ~2 full days (~16 hours) to configure SSR + TOGP meta tags, maybe quicker if everything were to go perfect with no hurdles. It really doesn't seem like there's major changes to be made, but it's tough to give a good estimate due to unknown unknowns

[apbendi]

Decided this is not worth the complexity/effort right now. Closing.