Data doesn't include a top level 'type'

[wilsonpage]

It would be nice to add some clarity about types. Right now the service just spits out whatever it could extract from the page. IMO we should agree on the high level types and have the service decide on a type for each given URL.

A type could be derived from the OpenGraph type or specific known type (twitter, playstore) with a fallback default type (website)

Example of possible types (inc. og):

• website
• video
• music
• image
• twitter (specific)
• playstore (specific)

The client will then expect there to be a key matching the type containing type specific data:

{
  type: 'video',
  icon: ...,
  title: ...,
  description: ...,
  url: ...,

  video: {
    duration: ...,
    poster_image: ...
  }
}

{
  type: 'twitter',
  icon: ...,
  title: ...,
  description: ...,
  url: ...,

  twitter: {
    type: 'tweet',
    username: 'wilsonpage',
    content: 'this is a tweet',
    timestamp: ...
  }
}

{
  type: 'playstore',
  icon: ...,
  title: ...,
  description: ...,
  url: ...,

  playstore: {
    appId: 'com.whatsapp',
    name: ...,
    short_name: ...
    icon: ...,
    description: ...,
    rating: ...,
    developer: ...
  }
}

This isn't that different from what we have now, but I wanted to get this documented so that we're all on the same page :)

It's important that we only apply specific type parsing for specific pages under a domain. For example, we only want to give playstore 'app' urls special treatment, not other pages (like the homepage). For twitter we may want to treat all pages other than profile pages as website until we have the required support.

Types allows clients to easily map the data returned to specific view representation without having check the returned data for specific keys etc.

[wilsonpage]

@arcturus @samgiles let's discuss :)

[wilsonpage]

I just noticed that OG has a type of profile. This is useful as we can have a base ProfileTileView that we could extend for specific known profiles (eg. TwitterProfileTileView).

[wilsonpage]

Ah so just found out Facebook and Twitter profiles have zero metadata, probably because they want to serve all content through their official API. As these are two prime use-cases we should probably make an effort to make a custom solutions for each. Although this is brittle, we could also explore getting content through the official APIs.

[wilsonpage]

FYI even iframely doesn't provide content for Facebook and Twitter profile URLs. Iframely seems to only support pages that have oembed meta, which our service can already cope with.

[samgiles]

A strawman based on the original post:

An example resource would look like the following?

{
  "type": "audio",
  "subtype": "music.playlist",
  "description": "Lead heavy metal tracks of the 1920s",
  "title": "Metal 20s",
  "url": "https://playlister.ly/id/20smetal",
  "music.playlist": {
    "songs": [ "uri", "uri" ],
    "creator": [ "uri" ]
  },
  "embed": {
    "html": "some html for an embed-able widget",
    "preferred_height": "css compatible units",
    "preferred_width":  "css compatible units"
  },
  "manifest": { ... },
  "icon": {
     ...
   }
}

A resource must have a type field with one of:

• website
• image
• video
• audio
• profile
• article
• app
• survey

Each type may have extra information about it in another field named subtype.

For example, a Spotify playlist would be:

{
  "type": "audio",
  "subtype": "music.playlist"
}

A response must have one description field, one title field, and one url field, describing the URL for this resource.

.. TBC :see_no_evil:

[wilsonpage]

Now we are using oembed to handle anything dynamic. So this issue is no longer relevant.