## 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
> 5459 Add setting for changing your comment server. Visible on desktop (and possibly defaulting to Odysee URL), hidden on odysee.
## Comments
Not sure how this would actually work properly without the user recompiling the app to handle server differences. For example, even when we use our own server but switch between v1 and v2, some code changes are need to handle the differences. At that point, it seems easier for the user to just change the .env file? Anyway...
## Changes
- Added Desktop-only options to define custom server. [Settings > Advanced Settings > "Comment server" section].
## Issue
6366 Recsys Evaluation Telemetry
The recommended list from lighthouse is obtained from `makeSelectRecommendedContentForUri`. This list is further tweaked by the GUI (e.g. move autoplay next item to top, remove blocked content, etc.). Recsys wants the final recommendation list and the clicked index (in exact order), so we need pass these info to the videojs recsys plugin somehow. Also, Recsys wants a recommendation list ID as well as the parent (referrer) ID, we so need to track the clicks and navigation.
## General Approach
- It seems easiest to just spew back the final (displayed) list and all the required info to Redux, and the recsys plugin (or anyone else in the future) can grab it.
- Try to touch few files as possible. The dirty work should all reside in `<RecommendedContent>` only.
## Changes
- `ClaimPreview`: add optional parameters to store an ID of the container that it is in (for this case, it is `ClaimList`) as well as the index within the container.
- When clicked, we store the container ID in the navigation history `state` object.
- For general cases, anyone can check this state from `history.location.state` to know which container referred/navigated to the current page. For the recsys use case, we can use this as the `parentUUID`.
- `ClaimList`: just relay `onClick` and set IDs.
- `RecommendedContent`: now handles the uuid generation (for both parent and child) and stores the data in Redux.
## Issue
Creating Settings suddenly start to stop loading correctly for some of my channels.
## Change
`settings.List` now returns null instead of empty array. Double-checked the Commentron repo and this is indeed the case.
Updated the code to handle null.
If there are no API errors but no reactions returned, consider the requested IDs as "done" and stop requesting again. When a channel is being confirmed, Commentron doesn't return the reaction object.
Also added extra guard in case Commentron does return an object in the future, but an empty one.
In the event that Commentron returned an empty object, we'll end up re-requesting the same IDs again. Haven't seens this happen before, but since we don't know what's causing the spike, we'll just consider failures and "fetched" to stop the loop.
User can always click Refresh to repopulate the values.
## Issue
Closes 6159 "Support Comments Enabled/Disabled for comment.List API"
## New behavior
- `disable-comments` tag will block the comments component entirely.
- `settings.commentsEnabled`:
- When false, will pause comment fetching, posting and replying.
- Any already-fetched comments will stay on screen (unless user reloads/F5).
(1) Due to IAPI/commerce query limit, and also to not pollute the wallet with infinite chargeCodes, we'll only show the last 10 swaps. Beamer mentioned that it's possible to tracked back the past chargeCodes of the user, and potential provide a `list` endpoint to handle disputes.
(2) If a user explicitly removed an entry, don't repopulate that entry even if websocket returned an updated status for it. While it might be useful to handle accidental removals, it looks weird when the list gets repopulated with 'Expired' entries.
(3) Add sanitization when repopulating the chargeCodes from the wallet data (i.e. remove 'null' entries).
(4) Always repopulate the list per wallet data so every instance looks the same.
- For the active swap, switch from polling to websocket. The returned data is now the Charge data from the commerce, so some parsing will be required.
- Allow the user to send other coins that the commerce supports.
- Only save the 'chargeCode' to the wallet. The other data can be repopulated from this.
- Store the receipt currency. I'm not sure if the commerce supports sending bits from various coins. Take the coin that came with the 'COMPLETED' message for now.
- Fix 'lbc' calculation to match IAPI side.
- Allow users to see full detauls from "View Past Swaps".
- String cleanup
- GUI cleanup.
- Users should be able to see the entered and promised amount, otherwise they might forget how much to send over.
- This change also prepares for the future upgrade to support multiple coins.
Initially, the filtered list was done at the component level, and the list was simply a subset of `notifications`. But due to the limit issue explained in 5694, we now query the filtered list instead.
Considerations:
- The filtered list could contain items not listed in the 'All' list. We could add a string at the bottom of 'All' that says "not all items retrieved" if this confuses the user.
- The unseen count needs to be based on 'All' and not the filtered one, so that data needs to be stashed somehow (can't re-use the array).
Use 2 arrays for now instead of trying to accumulate "all" and "filtered" into 1 array.
## Issue:
Closes 5515: All videos marked as read when clicking a single notification from notification list
## Change:
- Augment `doReadNotifications` to only clear the given IDs. If the argument is `null` or is not a valid array (e.g. when used as a click handlers, the click event object is passed in), all notifications will be cleared.
- Augment `NOTIFICATION_READ_COMPLETED` to only clear the given IDs.
## Notes:
- Wasn't sure of the API will fail if the ID is invalid, so I start from `unreadNotifications` first, then only filtering it further with the given ID. Otherwise, we could just skip the `unreadNotifications` filtering.
* 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
## Issue
5308: Ability to choose default play speed and theatre mode or regular playback size
## Comments
Initially, I used the local storage, as per 'muted' and 'volume' -- I thought that would be appropriate.
Later, I saw that Theater Mode is already using Client Settings, so I re-did everything to match that.
Also, there is an accompanying commit in lbyr-redux.
