## General
- `setting.List`: returns full creator settings. Requires signature (i.e. you own the channel)
- `setting.Get`: returns a public subset of the creator settings. No signature required, and it is mainly used by the GUI to determine the constraints of a channel (e.g. comments enabled? min tip requirements? etc.). Does not include private settings like "blocked words list".
`doFetchCreatorSettings` will handle both of these. Clients that uses the stashed results (`settingsByChannelId`) just needs to be aware the result might not contain everything, depending on whether you own the channel or not.
## Misc Related Changes
- Finally fix the reducer for COMMENT_FETCH_SETTINGS_COMPLETED to not purge the data on each call.
- Change `doFetchCreatorSettings` to operate on a single channel instead of multiple. We ended up not using the multple mode anyway, so it was wasteful code trying to batch the promises.
- `commentsDisabledChannelIds` is no longer needed. Previously, this was created just to differentiate between Creator (full) and Channel (subset) settings. It's cleaner to just use one object, so eliminated this.
- Remove unused 'commentingEnabled'.
## Aside
- There are now 2 ways to know if a channel has disabled comments: (1) from `comment.list` and `setting.Get|List`. Both of them updates `settingsByChannelId`, so it'll still be a single place for the GUI to check against.
## Issue
Closes 6490
Embeds in https://lbry.com/news/2002dtf was crashing in incognito
## Change
Ensure localStorage is available before using it. Jessop warned me before...
## Changes
- Change to canonical_url (with ':').
- The old format of 'claimName/claimId' needs to be supported still, since we shipped with it.
## Notes
- It would be nice to use regex instead of 2 separate paths, but I couldn't figure out how to make the koa variables work.
## Issue
3779 RSS feed for channels
## Initial implementation details
- RSS only (not atom)
- Grabs latest 10 entries (Beamer have concerns)
## Credit
Referenced the community version mentioned in 3779
While Lighthouse allows looser searching like "Tom from LBRY", it doesn't show the expected results when direct channel name with partial ID is entered to disambiguate.
## Issue
6236 Add context menu to file page
## Notes
The download button actually handles a lot of things -- generating 'streamingUrl', differences between Web and Desktop, download progress for Desktop, etc. A simpler fix would be to put something else (maybe "Share") into the overflow menu instead.
Anyway, went ahead to do it per 6236, but retained the item for Desktop since we need a progress label.
wip
wip - everything but publish, autoplay, and styling
collection publishing
add channel to collection publish
cleanup
wip
bump
clear mass add after success
move collection item management controls
redirect replace to published collection id
bump
playlist selector on create
bump
use new collection add ui element
bump
wip
gitignore
add content json
wip
bump
context add to playlist
basic collections page style pass wip
wip: edits, buttons, styles...
change fileAuthor to claimAuthor
update, pending bugfixes, delete modal progress, collection header, other bugfixes
bump
cleaning
show page bugfix
builtin collection headers
no playlists, no grid title
wip
style tweaks
use normal looking claim previews for collection tiles
add collection changes
style library previews
collection menulist for delete/view on library
delete modal works for unpublished
rearrange collection publish tabs
clean up collection publishing and items
show on odysee
begin collectoin edit header and css renaming
better thumbnails
bump
fix collection publish redirect
view collection in menu does something
copy and thumbs
list previews, pending, context menus, list page
enter to add collection, lists page empty state
playable lists only, delete feature, bump
put fileListDownloaded back
better collection titles
improve collection claim details
fix horiz more icon
fix up channel page
style, copy, bump
refactor preview overlay properties,
fix reposts showing as floppydisk
add watch later toast,
small overlay properties on wunderbar results,
fix collection actions buttons
bump
cleanup
cleaning, refactoring
bump
preview thumb styling, cleanup
support discover page lists search
sync, bump
bump, fix sync more
enforce builtin order for now
new lists page empty state
try to indicate unpublished edits in lists
bump
fix autoplay and linting
consts, fix autoplay
bugs
fixes
cleanup
fix, bump
lists experimental ui, fixes
refactor listIndex out
hack in collection fallback thumb
bump
* own comments show first in controversial / best #5905
* workaround to place my recent comment at the top
* only most recent comment
* lint fix
Co-authored-by: Thomas Zarebczan <thomas.zarebczan@gmail.com>
- This change makes it work for both Desktop and Odysee. When merging back to Odysee, just take the file from `master` (barring any changes from someone else).
- Given that we'll be opening up the search filter for Odysee, the only "simple site" customization that was back-ported is `free_only=true`.
- SUPPORTED_SUB_LANGUAGE_CODES[] that I introduced was pretty redundant when SUPPORTED_LANGUAGES[] already hold the information. The logic to ignore sub-languages (i.e. reduce the locale's "en-GB" to "en" is now located in getDefaultLanguage()).
- SUPPORTED_BROWSER_LANGUAGES[] and SUPPORTED_LANGUAGES[] look so similar and hard to tell what the former is for at first glance. The functionality to map 'zh-CN' to 'zh-Hans' is now handled by resolveLanguageAlias(), which makes the intention clearer.
This leaves us with a single list -- SUPPORTED_LANGUAGES[], whose key also tells us the desired language code to use.
Also, clients now need to call `resolveLanguageAlias` to map any language code aliases, as they differ depending on how it is queried (e.g. `navigator.language` vs. `app.getLocal()` uses different standards).
I think we no longer need to explicitly migrate existing user's 'zh-CN' into 'zh-Hans' because the rest of the system will always use the desired language code as long as 'resolveLanguageAlias' is called appropriately. e.g. the system uses `selectLanguage` and `selectLanguage` calls `resolveLanguageAlias`.
* initial support for block/mute
* hide blocked + muted content everywhere
* add info message for blocked/muted characteristics
* sort blocked list by most recent block first
* add 'blocked' message on channel page for channels that you have blocked
* cleanup
* delete unused files
* always pass mute/block list to claim_search on homepage
* PR cleanup
'Copy' is always disabled for the case of Claim previews since no text is selected. User cannot select text anyway since a left-up event would invoke the Claim's `click` event. 'Copy' is there simply because of re-using `openContextMenu`.
## Issue
Closes 5523: timestamps not interpreted in some cases
## Notes
`remark-breaks` previously kept repeating the same index in the loop, causing some corner-cases to be parsed oddly. I added code to address that.
Later, `remark-breaks` fixed the problem and we recently just bumped up the componnent version. My hack is no longer necesary.
## Issue
- The previous regex uses lookback (I think ES2018?) which Safari has yet to implement.
- There were a few bugs in the previous regex too, like missing out multiple timestamps in a line, or parsing "62:02" as "2:02" (although YT does this as well).
- The previous method searched too deep (matchAll) on each 'locate' call, which was wasteful.
## Issue
Fixes 4665 `Translated strings with trailing spaces not shown correctly`
## Changes
While there are other strings with trailing spaces, "Trending for " was the only one that mattered. The rest are standalone paragragphs or used in a single line, so it doesn't matter if the translation included the space or not.
