Due to needs of analytics, we need to design a way to store information of card exposure.

• database
• tables

Describe the solution you'd like
A clear and concise description of what you want to happen.

Hi, I want to make an application for users of matters to manage their article at matters.news, could I get a oauth2 application for user to authorize their article scope for me? For now, my needs is only to read the authorized user's article.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

For now, may be I can get the articles of user through scraping the graphql api, but I don't think it's a good use case.

Additional context
Add any other context or screenshots about the feature request here.

thanks!

It seems there are two notice types have logic inconsistency. Below are possible problems based on my understanding:

👍🏻 comment_new_upvote

Before queue trigger inserts notice data into DB, it generates different data objects according to different notice types. Like this:

-------------------------------------------------
File: src/connectors/notificationService/index.ts
-------------------------------------------------

private getNoticeParams = async (params): Promise<any> => {
  switch (params.event) {
    case 'user_new_follower':
    case 'comment_new_upvote':
      return {
        type: params.event,
        recipientId: params.recipientId,
        actorId: params.actorId
      }
    ...
 }

In above, there is no entities in comment_new_upvote's returned object. Howerver, entities are required in the query API and they will be displayed in notice digest:

-------------------------------------------------
File: src/common/utils/notice.ts
-------------------------------------------------

const actorsRequired = {
  ...
}

const entitiesRequired = {
  comment_new_upvote: true
  ...
}

export const filterMissingFieldNoticeEdges = (params): any => {
  return edges.filter(({ node: notice }) => {
    const noticeType = notice.type
    ...
    // check entities
    if (entitiesRequired[noticeType] && _.isEmpty(notice.entities)) {
      return false
    }
    ...
    return true
  })
}

So, there is logic inconsitency in it. Except that, it causes another problem. Since comment_new_upvote are always filtered out of query result and state still stay unread, our notice service will try to bundle all comment_new_upvote as one even upvote targets are different. 🤔

🏅 comment_pinned

Pretty similar to previous case:

private getNoticeParams = async (params): Promise<any> => {
  switch (params.event) {
    case 'comment_pinned':
      return {
        type: params.event,
        recipientId: params.recipientId,
        entities: params.entities
      }
    ...
}

Our filter will kick comment_pinned out of query result becasuse of lacking actors:

const actorsRequired = {
  comment_pinned: true
  ...
}

export const filterMissingFieldNoticeEdges = (params): any => {
  return edges.filter(({ node: notice }) => {
    const noticeType = notice.type
    // check actors
    if (actorsRequired[noticeType] && _.isEmpty(notice.actors)) {
      return false
    }
    ...
    return true
  })
}

And I found we tried to get actor from comment data so that we don't have to record actor in DB:

-------------------------------------------------
File: src/queries/notice/index.ts
-------------------------------------------------

  ...
  CommentPinnedNotice: {
    id: ({ uuid }) => uuid,
    actor: ({ entities }, _: any, { dataSources: { userService } }) => {
      const target = entities.target
      return userService.dataloader.load(target.authorId)
    },
    target: ({ entities }) => entities.target
  },
  ...

But the target here is the comment, so target_authorId is the comment creator instead of article author. In notice digests, they look like comment authors pinned their own comments. 😂

type Article {
  ...
  content: JSON!
  ...
}

Due to content is require index.html, use custom scalar (ContentJSON) to restrict may be better.

Previous permissions:
2 * appreciation + read >= 30

New permissions:
2 *appreciation + read >=10

To simplify registration process, we will provide an email attached a link in order to confirm and activate THE following steps.

We will need:

• New email template
• Link generator
• Confirm mechanism
• Retire old verification

Describe the bug
Some covers of tag are still vacant although covers of articles in the tag can be found.

Screenshots

Desktop (please complete the following information):

• MacOS
• Chrome

An user should automatically follow a tag when s/he:

• submit an article to the tag
• become tag owner
• become tag collaborator

thematters/matters-web#1556

In one of new user tasks, there will be three new feed types most trendy, most appreciated and most active for new registered users to follow.

Logics:

• Most trendy: List creators who has over 60 followers in 90 days.
• Most appreciated: List top 60 creators who got HKD donations, but exclude creators in most trendy.
• Most active: List top 60 creators who has more comments in 90 days, but exclude creators who receive downvote rate > 10%. (downvote/(upvote + downvote))

We have discovered that Matters IPFS public gateway was used to pirate video files, and will therefore temporarily remove it.

Describe the bug
Search API should only record searches in search bar, but is currently recording every search including @ user, connect articles and add article to tag.

To Reproduce
Steps to reproduce the behavior:

1. @ user, connect articles or add article to tag
2. see the recent query when clicking on search bar

Expected behavior
Queries from @ user, connect articles or add article to tag should not be included in search history

Additional context
Search API input should include record: boolean to notate if the current search should be recorded, and frontend should use it accordingly.

Is your feature request related to a problem? Please describe.

Currently two home article feeds, 『熱門』and『熱議』, have vague design goals and significant overlap with each other. 『熱門』should be a collective choice for articles that are worth reading at a given moment, and 『熱議』should be a collective choice for articles that are worth discussing at a given moment.

For『熱門』, in the past we do not have a direct measurement of reading time. Now that we are recording read time, we can move away from appreciations/Likes, which does not have any cost for the actor and signifies many different things such as friendship, support or greetings, and move towards read time and donation, the former being a direct measurement of reading and the later with cost and therefore resilient to spams. We can also start recording impressions, which are the times an article card appear to our user, to calculate the efficiency of ready given a number of impressions.

『熱議』still requires more discussions. A general direction might be more focus on number of participates, number of votes on comments, or different ways of measuring weights of commenters.

To make home page looks better, tag description is required for tags presented in home page.

Based on Protecting Amazon S3 Against Object Deletion, we can:

• Enable versioning
• Add lifecycle rule to delete versioned objects after 7 days
• Cross-region backup

References:

• Versioning

Discussion context: https://mattersnews.slack.com/archives/CF78WGNNM/p1582930152004800

We need a mechanism to reduce re-registration of banned users. We still need to confirm with lawyers for legal regulations, but here's some initial ideas.

Record canvas fingerprint after ban

When a banned user logon, backend record ip, canvas fingerprint and email in blacklist table. Fingerprint can be passed to backend either through a mutation or through a particular header.

In this way, we don't have to track the fingerprint of every user, but only for the banned user.

Inheritance of ban

When requesting verification code during registration, frontend also send canvas fingerprint to backend. If backend finds a match in fingerprint, ip or email, it adds the other two to blacklist and decline sending verification code.

In this way, a banned user is likely to inherit his/her banned state across agents. For example, when a banned user use the same browser or ip to register with a new email, verification code is not send and new email is also banned; when he/she changed browser and ip to try again, the email is matched and the new ip and canvas fingerprint is also banned. This makes it harder to crack.

Blacklist table

• id: increments
• uuid: uuid, used to mark the same user across different types
• type: enum(['ip', 'canvas', 'email'])
• value: string
• created_at: timestamp

Current article doesn't record draft id when publishing. We need to backfill these ids before implementing version control of article.

Since we are reshaping our feature from calling Medium API to uploading Medium source files, couple things need to discuss.

📦 Files

The packed files downloaded from Medium is quite big because it has lots of irrelevant files. Below are unpacked files:

├── blocks
│   └── blocked-users-0001.html
│  
├── bookmarks
│   └── bookmarks-0001.html
│  
├── claps
│   └── claps-0001.html
│  
├── highlights
│   └── highlights-0001.html
│  
├── interests
│   ├── publications.html
│   ├── tags.html
│   ├── topics.html
│   └── writers.html
│  
├── ips
│   └── ips-0001.html
│  
├── posts
│   ├── 2018-04-02_-----------Arendt----51bc52c880f3.html
│   ├── 2018-04-12_-----------------3a905851316e.html
│   ├── 2018-04-12_------------1253c94fa6ac.html
│   ├── 2018-05-31_Matters--------------ae9f9aa98249.html
│   ├── 2018-11-10_-Matters--------------70c1ab6d47e2.html
│   ├── 2019-03-22_Matters-------------------6dc72e6753f9.html
│   ├── 2019-03-27_---------------------c4336ab683df.html
│   ├── 2019-04-02_------------------12bdf59fe4a9.html
│   ├── 2019-04-24_----------------------2fd7c25b0934.html
│   └── draft_nn-813be4d2bd80.html
│  
├── profile
│   ├── memberships.html
│   ├── profile.html
│   └── publications.html
│  
├── pubs-following
│   └── pubs-following-0001.html
│  
├── sessions
│   └── sessions-0001.html
│  
├── topics-following
│   └── topics-following-0001.html
│  
└── users-following
    ├── users-following-0001.html
    └── users-following-0002.html

As you see, there are some user information and settings. All we need is posts folder. Comments are considered as posts from Medium view, so comments are also packed in posts folder. Do we want user to upload one package? Or just upload real posts by picking ?

🧑🏻‍🔬 Process flow

Possible process flows are here:

Based on current design, uploading packed files would be the easiest way for user but not for us. Also, some comments' contents will be listed in drafts. In opposite, uploading multi-files would be the simplest way for us and we could get the right uploaded files (real posts), but users might need to drop files couple times.

FYI, editor has an upload button on the right sidebar.

Love to hear you guys ideas 🧑🏻‍💻

Problem

Our pagination is based on offset and limit, but the performance of it will get worse when records accumulated. Because:

• offset always shifts from scratch. (page 1 -> page 2 -> page 3)
• Based on point one, the cost and execution time will increase drastically in tables that we insert frequently.

Take follower as an example:

findFollowers = async (...) =>
  this.knex
    .select()
    .from('action_user')
    .where({ targetId, action: USER_ACTION.follow })
    .orderBy('id', 'desc')
    .offset(offset)
    .limit(limit)

In this example, users can follow multiple users so it accumulates records quickly. Now we have 197,989 records, and CPU usage of the query usually stays on Top 5. 🤦🏻‍♂️

Possible fix

In order to fix this, we need to change how we do pagination. An easier solution is to use id as cursor:

findFollowers = async (...) =>
  this.knex
    .select()
    .from('action_user')
    .where({ targetId, action: USER_ACTION.follow })
    .andWhere('id', '<', id)
    .orderBy('id', 'desc')
    .limit(limit)

In this query, the order of id exactly matches the order of followers. So, we can take advantages of comparing id:

• No more shift from scratch.
• Comparing id (a number) can have more stable and consistent performance than using offset.
• If we try to retrieve pretty old record, the database will utilize id (pk or index) to search reversely.

I've used PG's explain to analyze, and the cost looks ok. Once I commit the new query, we can observe the result. At the same time, we might need to think rest of queries that cannot apply this fix case.

@robertu7 @guoliu any idea?

• Field Protecting: Only authorized users can query or mutate sensitive fields
• Size Limiting
• Query Whitelisting
• Depth Limiting
• Amount Limiting
• Query Cost Analysis

refs:
[1] https://blog.apollographql.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b
[2] https://codeburst.io/use-custom-directives-to-protect-your-graphql-apis-a78cbbe17355

As LikeCoin's requests, we will pass X-LIKECOIN-USER-AGENT in HTTP header while calling the LikeCoin API

thematters/matters-web#1556

In one of new user tasks, there will be two new feed types popular tags and selected tags for new registered users to follow.

Logics:

• Popular tags: List top 60 tags that has over 8 articles, and more followers in 2 months.
• Selected tags: List tags that selected by team.

https://mattersnews.slack.com/archives/G88CK7Q7L/p1544592953080700

Is your feature request related to a problem? Please describe.
It's better to highlight the selected tags

Describe the solution you'd like
Selected Tags (with green background) should appear at the front of the list in article detail page

Our GraphQL schema has grown very large, maintenance and optimization are needed. With a better partition between public data and private data, we should be able to fit the need of JAMstack pattern on frontend, simplify private cache pattern on backend, make it easier for developers to start using after we open source, better support future iterations on follow page, and much more.

We can separate public and private data into different types. For example, each Node type can have a viewer field, which holds the corresponding type for private/viewer data. Therefore Article type can be:

Article {
  ...
  viewer: ViewerArticle
}

ViewerArticle {
  isBookmarked
  appreciationCount
  appreciationLeft
  ...
}

User type can be:

User {
  ...
  viewer: ViewerUser
}

ViewerUser {
  isFollower
  isFollowee
  isBlocked
  ...
}

Comment type can be:

Comment {
  ...
  viewer: ViewerComment
}

ViewerComment {
  isCollapsed
  ...
}

In this way, we do not need to keep a special keyword for CSR on frontend as proposed in thematters/matters-web#1051 (comment), but need to assemble Viewer${NodeType} fragments with client side query. This could be a cleaner logic, and improves cache hit rate and share rate.

We can also separate private and public data under different root fields, so that we can apply different auth and cache patterns. For example, we can group all private data under viewer and all public data under system, and the schema could look like:

query: {
  system: { 
    node(input: {
      id
    }): Node
    article(input: {
      mediaHash
      dataHash
    }): Article
    user(input: {
      userName
    }): User
    feeds: {
      icymi: ArticleConnection
      hottest: ArticleConnection
      ...
    }
  },

  viewer: {  
    // followers feed
    feeds {
      // follower publish feed
      articles: ArticleConnection
      // follower comment feed, group by article and user
      discussions: { 
        ...
        edges { 
          // comment on which article
          article: Article
          // the grouped comments
          comments: CommentConnections
          cursor: String
        }
      }
      // follower donation feed, group by article
      donations: {     
        ...
        edges { 
          article: Article
          users: UserConnection
          cursor: String
        }
      }
    }
    setting {   
      language
      ...
    }
    status {
      ...
    }
  }
}

Visitors and SSR would only need to query system root field. If we want to be safe and strict, we can even enforce on the backend that queries of type Viewer${NodeType} and viewer root field only return when fetched from client.

There should also be other optimization patterns we can apply.

Is your feature request related to a problem? Please describe.

We are currently using Knex.js without an ORM. This has provided flexibility in the beginning, but as our database schema grows more and more complex, we need a cleaner model for database objects.

Describe the solution you'd like

We can migrate to Prisma, which has matured in the past few years. It automates most of the mapping between GraphQL schema and database schema, which will make our codebase much cleaner.

However, Prisma Migrate for database migration is still experimental. We can take some risk and try it on, or keep knex-migrate for migration and then do introspection separately (see example).

Since Knex is a query builder and Prisma is similar to an ORM, there need to be a change in design pattern. We need to decide what migration method we want to use, and what would be the easiest path switching to Prisma.

Additional context
Related to #897

RT

some articles about it:
https://matters.news/@gonghei88/%E6%AA%A2%E8%A8%8E%E6%88%91%E7%9A%84-%E9%80%8F%E9%81%8Elikecoin%E5%92%8Cmatters%E6%8E%A8%E8%A1%8C%E6%8F%9B%E6%9B%B8-%E9%80%81%E6%9B%B8-%E8%A8%88%E5%8A%83-bafyreihkxgv4ijjd6jer2ywysfpic3fzqpnwrk5nxdes6c4n6vysogcpoa

This issue involves:

• Create data structure for storing info
• Redesign or merge current table
• Revise logic of store limits

Describe the bug
Under certain condition, user can appreciate more than 5 times.

Expected behavior
User should not be able to appreciate more than 5 times.

Screenshots

Additional context
We are currently updating appreciation record to database directly. But we should use queue instead to avoid concurrency, and perform database checking before updating, similar to donation and withdraw.

After checking queries listed in card, there are some difficulties on tuning cache. For instance:

query {
   user {
     articles {
       title
       isSubscribed
     }
   }
}

Most fields in the query could be public, but personalized data isSubscribed makes entire response private. Besides that, our digest components like ArticleDigest, UserDigest and Comment more or less include personalized data. More examples:

query {
  comment {
    author {
      name
      isBlocking
    }
  }
}

and

query {
  user {
    name
    isFollower
  }
}

As you see, it's quite hard to separate data like Author from Article, Comment and Response (Article | Comment) in queries we have now. And it also a little bit conflicts GQL philosophy if we try to separate those fields. 🤔

Probably, increase TTL might be one temporarily solution for now ?

@robertu7 @guoliu any idea?

We will implement article edit functionality on the frontend. On the backend, we need to implement a minimal version control. The idea is using draft table as versions, and article table as pointer pointing to the newest version.

We need to reject certain operations if the frequency is higher than given threshold. This might not be useful for preventing spam in general, but is still good practice to mitigate attacks.

Operations currently under discussion include:

• comment, 2 per minute
• appreciate, 5 (transaction) per minute (need confirmation)
• publish, 10 per 2 hours

• global rate limit for mutation
• use redis to record operation log

Very curious!

We have been delivering one single version of SSR webpages on CDN, and certain user group refetch data for A/B test. This has slow response time. We can instead write user group in cookie, differentiate user group by cookie in CDN, and implement A/B test behind GraphQL resolvers.

• write group to cookie: https://github.com/thematters/matters-server/blob/develop/src/common/utils/cookie.ts#L22
• separate cache by cookie.group on CDN for certain pages (currently only homepage)
• read group from cookie on server: https://github.com/thematters/matters-server/blob/develop/src/common/utils/getViewer.ts#L31
• add new ranking migration and update naming convention: #1490
• resolve to different ranking views according to user group in recommendation.hottest resolver

Since we're refactoring structure of draft and article data, we have to reorganize and cleanup their assets.

https://github.com/facebook/dataloader#clearing-cache

Currently we are caching translation result for 10 days. This is wasting API calls, since we only need to call detect language once for each article, and call translation once for each language of each article.

We also have the issue of high volume concurrency. If we update cache key schema or cache service, we will have a high volume of translation API calls, which result in many (403) User Rate Limit Exceeded errors. Although we haven't surpass GCP quotas, it looks like GCP have some hard limit in API call frequency peak. Since we also query Article.language to determine whether we should show translation button or not, it also slows down SSR when hitting rate limit.

A better long term strategy is that we store language in database, Translation.title and Translation.content in database or even s3.

We can probably progress in several steps according to our need:

• add a timeout for Article.language, so that query returns null and do not block SSR, but still fires API call and fill cache storage
• store language and translation to database or s3 after API call, and serve from database or s3 if possible
• after publishing article, store language and translation to database, and randomly store language and translation for older articles

Here are flows for preventing concurrent transactions to Postgres:

Couple things to be clarified since flows are in sync style:

• Pending transaction are always returned, which means client side need to revise feedback message. Client get notices when transaction state has been updated.
• Transaction history must includes pending transaction.

Any supplementation to those flows? @robertu7 @guoliu

cc @gyuetong

It's better if we merge our changes for cache plugin to apollo official repo, so we don't have to maintain and keep track. Related discussions: apollographql/apollo-server#3228 apollographql/apollo-server#2437

We might also want to separate cache directives into a separate repo.

Is your feature request related to a problem? Please describe.
Server cannot be decoupled from ElasticSearch with this error.

Describe the solution you'd like
As title.

https://stackoverflow.com/questions/36728899/knex-js-auto-update-trigger

In the new design of comment section, 2nd level comments are bundled together based on reply relationships.

We can view the newly added structure as sections within subthreads, or as subthreads of subthreads that are flattened into the same level (level 3 flattened into level 2).

The structure on the left has subthreads with section, so subthreads are lists of comment list. It is more similar with the UI layout.

The structure on the right is fractal, with subthreads having their subthreads. It is more similar with the actually relationship of comments, which is a directed acyclic graph.

With the mental model on the right, we won't need to update our API, since Comment type has comments field. But we need to either resolve in API all remaining comments at level 3, or recursively call child comments of comments on frontend util no more comments are returned.

They both have pros and cons, but I think the right one is more concise and closer to the actual relationship of data.

Currently, tags are presented in tag owner's profile page. To improve user experience, tags that user is helping on maintaining will be displayed in profile tag feed as well.

@proformatters reported that transaction page displays duplicate transaction with different state.

Current Workflow

TODO

• Build & deploy templates with CI/CD
• Separate to different templates for different languages
• Separate different environments

SendGrid?

Pros

• More developer-friendly than MailChimp: Template Engine Support & Easy to Use API
• Reduce Server Load: Rendering & Network Costs
• Sender Reputation: To avoid emails being in spam folder
• Statistics

Cons

• Handlebars Custom Helpers isn't supported
• Higher Cost than AWS SES

We need to display certain data visualizations for current and potential users, and need to evaluate if it is secure to embed metabase public dashboard as iframe. Another option is to display visualization as static image, which is secure but will involve manual updates.

After first glance of current open security issues on metabase, it seems that none is related to public dashboard, but further evaluation is still needed.

Some measures we can take:

• Use other domains to proxy to dashboard url (for example, data.matters.news/about and data.matters.news/community ?)
• NGINX stop public dashboard other than the ones in whitelist
• Setup CDN with very long TTL for dashboard
• See if cloudfront can keep alive when origin dies

As title.

Is your feature request related to a problem? Please describe.
Display (human-readable) texts for OAuth scope are hard coding at client now. It's hard to maintain.

Describe the solution you'd like
Move to matters-server and use field-level directive or a single file to declare related texts.

DataServices such as userService.ts and articleService.ts have a lot of code in a single file, and as our business logic grows, they become difficult to maintain.

Currently, Tag only support Article:

type Tag {
  text: String
  count: Int
  articles: [Article]
}

Background

We have lots of images uploaded by users: avatars, profile covers, article embedded images, and etc. Based on Lighthouse Report, images have big negative impact for performance score:

In general, there are three sides to be optimzed:

Source

• Compressing
• Resizing: different sizes fit different needs
• Formats: WebP, JPEG 2000, etc.
• Progressive

Application

• Lazy Loading Images: thematters/matters-web#1159
• Responsive Images

Proxy

• CDN
• Cache Policy ^[1]

Solutions

Currently, we will do simple image processing (compressing & resizing) in connectors/aws, while image uploading. But there are cons:

1. It's synchronous, uploading is blocked by processing;
2. Growing complexity, we need add more and more codes for above needs;

Lambda To Rescue!

With AWS Lambda, processing image will be asynchronously and separately. There are two ways to implement:

1) Lazy processing

Use Serverless Image Handler, process image on client requests, and cached by CDN.

Pro & Cons:

• Lower S3 cost, only store raw images;
• Higher CDN cost by low hit rate;
• Longer response time, process on-demand;

2) Post-processing

1. The client calls the API to upload image, server forward it to AWS S3 directly, now raw image is accessible.
2. AWS Lambda post-process the raw image from AWS S3, asynchronously, now optimized images are accessible.

Steps

1. Formating: WebP
2. Resizing
   • avatar: raw, 144w
   • embed raw, 1080w, 540w, 360w, 144w
   • profileCover: raw, 1080w, 540w
3. Compressing

Results

# AWS S3 
/matters-server-stage
├── 1080w
│   ├── uuid.jpeg
│   └── uuid.webp
├── 540w
│   ├── uuid.jpeg
│   └── uuid.webp
├── 360w
│   ├── uuid.jpeg
│   └── uuid.webp
├── 144w
│   ├── uuid.jpeg
│   └── uuid.webp
└── uuid.jpeg

Usage

<!-- <ArticleDetail.Content> -->
<figure>
  <picture>
    <source type="image/webp" media="(min-width: 768px)" srcset="https://xxx.cloudfront.net/embed/1080w/uuid.webp" alt="...">
    <source type="image/webp" srcset="https://xxx.cloudfront.net/embed/540w/uuid.webp" alt="...">
    <source media="(min-width: 768px)" srcset="https://xxx.cloudfront.net/embed/1080w/uuid.jpeg" alt="...">
    <img src="https://xxx.cloudfront.net/embed/540w/uuid.jpeg" alt="...">
  </picture>
  <figcaption>...</figcaption>
</figure>

<!-- <ArticleDigest.Cover>, View Mode = default -->
<picture>
  <source type="image/webp" media="(min-width: 768px)" srcset="https://xxx.cloudfront.net/embed/1080w/uuid.webp" alt="...">
  <source type="image/webp" srcset="https://xxx.cloudfront.net/embed/540w/uuid.webp" alt="...">
  <source media="(min-width: 768px)" srcset="https://xxx.cloudfront.net/embed/1080w/uuid.jpeg" alt="...">
  <img src="https://xxx.cloudfront.net/embed/540w/uuid.jpeg" alt="...">
</picture>

<!-- <ArticleDigest.Cover>, View Mode = compact -->
<picture>
  <source type="image/webp" media="(min-width: 768px)" srcset="https://xxx.cloudfront.net/embed/360w/uuid.webp" alt="...">
  <source type="image/webp" srcset="https://xxx.cloudfront.net/embed/144w/uuid.webp" alt="...">
  <source media="(min-width: 768px)" srcset="https://xxx.cloudfront.net/embed/360w/uuid.jpeg" alt="...">
  <img src="https://xxx.cloudfront.net/embed/144w/uuid.jpeg" alt="...">
</picture>

<!-- <UserProfile.Cover> -->
<picture>
  <source type="image/webp" media="(min-width: 768px)" srcset="https://xxx.cloudfront.net/profileCover/1080w/uuid.webp" alt="...">
  <source type="image/webp" srcset="https://xxx.cloudfront.net/profileCover/540w/uuid.webp" alt="...">
  <source media="(min-width: 768px)" srcset="https://xxx.cloudfront.net/profileCover/1080w/uuid.jpeg" alt="...">
  <img src="https://xxx.cloudfront.net/profileCover/540w/uuid.jpeg" alt="...">
</picture>

<!-- <Avatar> -->
<picture>
  <source type="image/webp" srcset="https://xxx.cloudfront.net/avatar/144w/uuid.webp" alt="...">
  <img src="https://xxx.cloudfront.net/profileCover/144w/uuid.jpeg" alt="...">
</picture>

^[1] We do had set a long cache TTL in CloudFront, but LightHouse doesn't think so.
^[2] https://css-tricks.com/responsive-images-css/
^[3] https://dev.to/jsco/a-comprehensive-guide-to-responsive-images-picture-srcset-source-etc-4adj
^[4] https://css-tricks.com/using-webp-images/#article-header-id-3