I believe these are unintentional items from d54976e461 because:
- feels irrelevant to the change.
- the env doesn't have correct values anyway (looks like for dev).
That change was causing the env to be copied over to `/web` and appear as an untracked file in git.
## Issues
- The current version of the link handler doesn't seem able to control the livestream player's position.
- The "live" position is always 0:00 and everything behind it is a negative timestamp. The current timestamp parser doesn't handle negative values.
* adding functionality to detect user download speed
* calculating bandwidth speed more intelligently
* saving download speed and updating it every 30s
* all the functionality should be done needs testing
* fix linting
* use a 1mb file for calculating bandwidth
* add optional chaining plugin to babel and get bitrate from texttrack
* allow optional chaining for flow
* ignore flow error
* disable bandwidth checking functionality
* fix flow error
## Issue
Part of `7166 improve search metadata`
## Notes
This is an experiment to influence the Sitelinks in our search results. Our current sitemap only consists of claims, so claims appear in Sitelinks more often. We (Julian) want categories to have higher priority, if possible.
For now, the sitemap will be defined in Google Console instead of robots.txt.
If it works, the file should be uploaded to sitemap.odysee.com, alongside the claim list sitemap.
## Issue
Category cards are showing up as "odysee.com" cards in Facebook.
## Change
- `og:url` is supposed to be the canonical URL. It was hardcoded to "odysee.com", so every category was being redirected when the card is being generated.
- Removed `twitter:url`. The documentation says it will fall back to `og:url`, so there is not need to define both if it's the same.
Since the redux slice is set up based on content or channel ID (for Channel Discussion page), re-use the channel ID for the case of "own comments". We always clear each ID when fetching page-0, so no worries of conflict when actually browsing the Channel Discussion page.
This reduces one lookup as clients will always have the claimID ready, but might not have the full URI.
It was using URI previously just to match the other APIs.
- Switch from 'author' to 'creator' to disambiguate between comment author and content author. For comment author, we'll use 'commenter' from now on.
- Corrected 'commenterClaimId' to 'creatorClaimId' (just a typo, no functional change).
* Add option to pass in url-search params.
Impetus: allow linked comment ID and setting the discussion tab when clicking on the `ClaimPreview`.
* comment.list: fix typos and renamed variables
- Switch from 'author' to 'creator' to disambiguate between comment author and content author. For comment author, we'll use 'commenter' from now on.
- Corrected 'commenterClaimId' to 'creatorClaimId' (just a typo, no functional change).
* doCommentReset: change param from uri to claimId
This reduces one lookup as clients will always have the claimID ready, but might not have the full URI.
It was using URI previously just to match the other APIs.
* Add doCommentListOwn -- command to fetch own comments
Since the redux slice is set up based on content or channel ID (for Channel Discussion page), re-use the channel ID for the case of "own comments". We always clear each ID when fetching page-0, so no worries of conflict when actually browsing the Channel Discussion page.
* Comment: add option to hide the actions section
* Implement own-comments page
* Use new param to remove sort-pins-first.
comment.List currently always pushes pins to the top to support pagination. This new param removes this behavior.
- A side-quest from "7166 improve search metadata".
- The favicon must be from the same domain as the homepage, so the CDN URL couldn't be used, hence the additional upload.
- The favicon also needs to be multiples of 48x48 and above.
- Wanted to use SVG for the smallest size possible, but seems like Safari does not fully support it. Got Dejan to give me a reasonably-sized PNG.
## Reference
https://developers.google.com/search/docs/advanced/appearance/favicon-in-search#guidelines
## Issue
7166 improve search metadata
Depending on the search term and timing, Google extracts data from the sidebar or page content to use as the search-result description.
## Change
Defined `description` (on top of the existing `og:description` and `twitter:description`.
While I couldn't find a definitive doc saying that this is the solution, this is present in all other sites (and matches their description in a Google Search results).
I think this the best solution so far, at the expense of a slight delay in scrolling if the network call stalls.
- Added "fetching by ID" state so that we don't need to use the ugly N-retries method.
- `scrollIntoView` doesn't work if the element is already in the viewport, and the `scrollBy` adjustment doesn't take into account the y-position restoration that we perform on certain type of pages. Use `window.scrollTo` instead and taking into account current scroll position.
## Issue
.../archives/C02FQBM00Q0/p1633044695010600
## Changes
When querying a search key, it has to be an exact match. This was broken by the insertion of `free_only` in the fetch.
Added a function to generate the options, so that all clients stay in sync.
