Port link resolver responses to JSON

[leon-richardt]

This issue is intended to gather feedback and implementation ideas.

Currently, responses by the link resolver are raw HTML which is sent to clients with the intent to be rendered directly without any additional logic performed by the Chatterino client. This approach has pros and cons.

Pros & Cons

Pros:

1. New providers can be added without the need for user interaction (i.e., only requiring a server-side update).
2. Existing providers can be changed without the need for user interaction (i.e., only requiring a server-side update).

Cons:

1. Clients have little control over the rendering of the information. This hinders ideas such as Add option for embedded inline link previews chatterino2#4695 from being implemented.
2. Using the link information for purposes other than rendering is very hard (the only option would be parsing the HTML response which is generally unstructured and error-prone). One can imagine use cases for which easy access to the link info is useful, e.g., imagine a filter or search predicate for YouTube videos from a certain channel.

(I probably missed some important aspects in this section, feel free to expand on these in the comments.)

Migration

1. Ideally, we would like to migrate without crippling older versions. The easiest approach would probably be serving the new responses over a separate API endpoint.
   a. How does this impact caching of responses in the database?
   b. Can we share cached responses between both endpoints?
   c. Would it even be a problem to duplicate the data during the migration period?

2. How can we share JSON schemas between the server and clients in a reliable manner?
   a. Do we even want to?
   b. Can we share schemas for the possible link info responses via an API endpoint as well?

3. At the client, "views" for the different response types must be implemented.
   a. What would be a good approach to keep code duplication and boilerplate to a minimum?
   b. Can we even provide a rendering information via the API as well (e.g. by exposing QML over a separate endpoint)? If implemented properly, this might allow us to provide link info for new providers without user interaction.

Migrating to JSON responses would require us to impose stricter requirements on the response schemas than what was necessary for HTML responses. Specification of such guidelines would be a good first step towards the implementation.

[KararTY]

Doing this would make the project into, although Twitch-flavored, a general purpose link resolver. 😍 A very dank resolver.

Also opens the repo for use in projects other than Chatterino (inb4 braize becomes paid API, because why host one on my own? )

[leon-richardt]

Also opens the repo for use in projects other than Chatterino (inb4 braize becomes paid API, because why host one on my own? )

In theory, this is possible already by parsing the returned HTML responses. But a change to JSON would certainly make it easier for other projects to consume the API. Whether that's a good thing or not, I'm not entirely sure yet. It would be interesting to hear from stakeholders (i.e., people hosting well-known c2/api instances or developers that might want to consume the APIs) on this issue.

I can think of @pajlada, @zneix and @Leppunen on the server side. Possible consumers include @flex3r and @rod41732.

[pajlada]

A JSON response endpoints (maybe controlled by headers? idk) is fine by me.

Ideally, we should not see this as a port or a migration, we should see it as adding another way for clients to get information about links, now in JSON instead of HTML.

[leon-richardt]

Ideally, we should not see this as a port or a migration, we should see it as adding another way for clients to get information about links, now in JSON instead of HTML.

I'm a little concerned about the maintenance overhead in this case (having to indefinitely support both formats). Also, what use case would HTML responses address once the C2 client makes use of JSON responses?

[pajlada]

I'm not necessarily saying we need to indefinitely support both formats, but more that there should be a lot of time inbetween JSON support being implemented & considering HTML deprecation

The overhead shouldn't need to be big, HTML outputs on a per-resolver level right now is a HTML tooltip:

	youtubeChannelTooltip = `<div style="text-align: left;">
<b>{{.Title}}</b>
<br><b>Joined Date:</b> {{.JoinedDate}}
<br><b>Subscribers:</b> {{.Subscribers}}
<br><b>Views:</b> {{.Views}}
</div>
`

with the struct containing that data. In a world where we output JSON, I imagine for youtube channels we'd want to output something close to

{
  ...,
  "fields": [
    {
      "label": "Joined Date",
      "value": "RFC-COMPLIANT_DATE",
      "type": "this is an rfc-compliant date, parse it as such",
    }
  ]
}

so the work of transforming the HTML template to support whatever underlying struct shouldn't be too big, nor should it require much maintenance afterwards