pr0gramm is an imageboard, and its new frontend pr0.app uses the same public
api. every upload is a single image or a video, served over plain cdn urls
(img./vid./thumb.pr0gramm.com) that need no login for sfw items.
the extractor reads the item from the public api and picks what the site itself
offers:
- videos exist as h264 (mp4, always with audio) and vp9 (webm, usually
without audio), in several height classes; videoQuality caps the height
- subtitles (.vtt) are attached for uploads that have audio
- items without any video variant are images, and are proxied
the media path pr0gramm reports isn't always up to date: an item that was
converted after its upload keeps the old path in `fullsize` (a `.png` that is
really served as `.jpg`), and a video without any variant has only its `image`
path. rather than trusting whichever field is filled, the reachable candidate
is probed. reviewers who prefer not to make HEAD requests here can simply keep
the `fullsize || image` order instead.
item links from both pr0gramm.com and pr0.app are accepted (/top/<id>,
/new/<id>, /user/<user>/<id>, ... -- the item id is always the last path
segment), and pr0.app is canonicalized to pr0gramm.com.
the media is served with `access-control-allow-origin: https://pr0.app` and
without referer checks, so a plain redirect response works for both the api and
the web ui and no local processing is needed.
this change was written with Hermes Agent and reviewed by me before submitting.
since the data should be side-effect free, this should
be fine for now, but maybe it might be a good idea to look
into a proper sandboxed environment in the future.
* the android client now also needs a valid device_identifier, but already generated access_tokens work fine
* you can also get them from a rooted device by mitm'ing the device while starting vimeo for the first time or going into its data directory and searching for the token in shared_prefs/
