giseldo/neodataset huggingface dataset:
"Complete to earn tokens" is missing on Newsfeed

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

The "Complete to earn tokens" sidebar component seems to be missing on the Newsfeed. However, it does appear on Discovery.

### Steps to reproduce

- Create a new account
- Navigate to Newsfeed
- Observe that "Complete to earn tokens" component is not in the sidebar
- Navigate to Discovery
- Observe that "Complete to earn tokens" component IS in the sidebar

### Platform information 

- MacOS + Chrome

### What is the current *bug* behavior?

- "Complete to earn tokens" does NOT appear in the Newsfeed sidebar

### What is the expected *correct* behavior?

- "Complete to earn tokens" DOES appear in the Newsfeed sidebar when a user has not previously completed the steps or hidden the component.

### Relevant logs and/or screenshots

Logged in as a new test account (@ mrs_test_apr29_01 ) in Production:

![image](/uploads/b62c457d8e205a02d11fb54a0c2bd609/image.png)

![image](/uploads/a8ef17912f1e337737df6c6affa7d0e0/image.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
Assess Tranfer Bridge MR in full

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done

Assess Tranfer Bridge MR in full

## QA

In itself - a QA task.

## UX/Design

https://www.figma.com/file/vBjOrn7JFnixtyhJJLZY7r/Wallet-Network-Swapping

## Personas

Internally / Dorg developers

## Experiments

N/A

## Acceptance Criteria

- [ ] Merge request review
- [ ] List of defects

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [x] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 3.0
Push Notifs: Brave Error

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

(Summarize the bug encountered concisely)

Can't enable browser push notifs

### Steps to reproduce

(How one can reproduce the issue - this is very important)

Try to turn them on in Brave

### Platform information 

(Browser, device, system stats, screen size)

Macbook pro, brave

### What is the current *bug* behavior?

(What actually happens)

Get something went wrong error

### What is the expected *correct* behavior?

(What you should see instead)

Visual indication of success

### Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)

![Screen_Shot_2022-04-27_at_11.31.10_AM](/uploads/85a6528a31d55c31b98c8c8b5a2646f3/Screen_Shot_2022-04-27_at_11.31.10_AM.png)

![Screen_Shot_2022-04-27_at_11.35.13_AM](/uploads/7d48ef3c6f0a63aaab1e6140bf2542a4/Screen_Shot_2022-04-27_at_11.35.13_AM.png)

![Screen_Shot_2022-04-27_at_11.35.20_AM](/uploads/597fcffae43c123ee9a325ab5a2861a3/Screen_Shot_2022-04-27_at_11.35.20_AM.png)

![Screen_Shot_2022-04-27_at_11.35.24_AM](/uploads/64a86d315f88990cf312d849337cba1b/Screen_Shot_2022-04-27_at_11.35.24_AM.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 3.0
PWA: Icon Inconsistency

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

PWA Icon in iOS gets a black background. This may also happen on some other devices.

### Steps to reproduce

Install the PWA on an iOS device. Notice the icon.

### Platform information 

Noticed on iOS but should be tested on other platforms

### What is the current *bug* behavior?

<img width="300px" src="/uploads/32d2e6511a8c0dc01b17733e640aeb76/Screen_Shot_2022-04-14_at_13.08.55.png" />

### What is the expected *correct* behavior?

The icon should be according to the designs (either get a white bg, or not have a bg)

### Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)

### Possible fixes

We should check the icons in the manifest file and see why iOS is picking up the transparent one and if so why is it giving it a black bg

Story points: 1.0
PWA: Site Theme Inconsistency

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

When opening the installed PWA on a device, the site theme (not the app theme as in the dark/light mode, but the site theme which consists of, mainly, the topbar color) is always in light mode.

### Steps to reproduce

- Install the PWA
- Turn on dark mode
- Quit and relaunch the app
- The navbar color (of whatever OS it's being run) should match the app theme

### Platform information 

- noticed on Windows, iOS, and macOS

### What is the current *bug* behavior?

- light topbar in dark theme on macOS 

<img width="300px" src="/uploads/d58e41d1f66ceca5c8e4e4bf67f4c933/image.png" />

- light topbar in dark theme in iPhone 13

<img width="300px" src="/uploads/e0b25c11240267f9f859df1f4575d445/image.png" />

### What is the expected *correct* behavior?

The navbar color (of whatever OS it's being run) should match the app theme

### Possible fixes

Something should be changed in the ThemeService RE metaData

Story points: 1.0
Payout runner stopped

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

Payouts stopped mid-job and need restarting

### Steps to reproduce

Try re-run payment job

### Platform information 

Runners

### What is the current *bug* behavior?

Users weren't paid out

### What is the expected *correct* behavior?

Users should be paid out.

### Relevant logs and/or screenshots

Some issues with Uniswap in the logs.

### Possible fixes

- Restart runners
- If it fails again see why the Uniswap call failed.

Story points: 2.0
Tidy up transfer bridge MRs such that the changes in there are reflective only of the changes actually made

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

Merge requests should only contain the changes relevant to the MR

Front - https://gitlab.com/minds/front/-/merge_requests/1848
Engine - https://gitlab.com/minds/engine/-/merge_requests/1003

To be handled by Carlos / Fabiola

## What needs to be done

Clean up merge request such that diffs are only reflective of the changes we are making - note updating the epic branch is going to be difficult due to unrelated merge historys. We really should be pointing this at master or at minimum a new fresh epic branch.

## QA

Test transfer bridge functionality.

## UX/Design

https://www.figma.com/file/vBjOrn7JFnixtyhJJLZY7r/Wallet-Network-Swapping?node-id=0%3A1

## Personas

Transfer bridge users

## Experiments

N/A

## Acceptance Criteria

Merge request diffs that are clean and representing the changes made only for:

- [ ] Engine
- [ ] Front
- [ ] 
## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 0.0
Investigate via prototyping against the transfer bridge MR if there will be any unknown obstacles in using the agnostic components for SKALE

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

We need to establish the effort involved in implementing the SKALE side of the bridge, by prototyping integration, adding panels and see how nicely things play 


## What needs to be done

Possibly the creation of fully working parts of integration if everything goes smoothly.
If everything does not, then we need to have follow-up cards created addressing any issues and any components that are going to need creating manually.

## QA

Depends on deliverable - if working components are deliverable then they should be tested but this is more of an investigative card.

## UX/Design

https://www.figma.com/file/vBjOrn7JFnixtyhJJLZY7r/Wallet-Network-Swapping

## Personas

Ultimately, token bridge users.

## Experiments

None

## Acceptance Criteria


Either:
- the creation of fully working parts of integration if everything goes smoothly.
- If everything does not, then we need to have follow-up cards created addressing any issues and any components that are going to need creating manually.

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 3.0
Update report categories (web)

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->

The goal is to streamline the report modal by clarifying categories and removing duplicate and/or unused entries.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Report categories should be updated to reflect the chart in the following section. Below is a list of changes:

**Text-only changes**

1. Change 'pedophilia' to 'sexualization of minors'
2. Change 'Encourages or incites violence' to 'Incitement to violence'
3. Change 'Impersonates' to 'Impersonation'
4. Change 'Copyright' to 'Intellectual Property Violation'
5. Change 'Token manipulation' to 'Inauthentic engagement'
6. Change "Sex trafficking" to "Trafficking"

**Removals**

Remove the following categories:

1. Trademark infringement (because it is merged with IP violation)
2. Incorrect use of hashtags (because it does nothing)

**Modifications**

Under 'Intellectual Property Violations' (formerly 'Copyright') we need to link to the Zendesk DMCA form instead of saying to email to copyright@minds.com.

https://support.minds.com/hc/en-us/requests/new?ticket_form_id=360003221852

![image](/uploads/226280e4ffe04f435275143526c5de09/image.png)

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Minimal QA: make sure reporting under the new labels generates the correct report.

Check emails.

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

...

## Personas

<!---
Who does this user impact and why
--->

This change impacts typical Minds users who make reports.

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

No experiments are needed.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Labels are correctly changed for users on the report modal
- [ ] Labels are correctly changed for admins in the report queue
- [ ] Labels are correct in emails

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Doc process for deploying changes to runners

<!---
Please read this!

The Defintion of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

Document the process of applying changes to runners

## What needs to be done

Add docs to meet the above goal

## QA

Typos / Incorrect information.

## UX/Design

Not applicable.

## Personas

On-team developers

## Experiments

N/A

## Acceptance Criteria

Docs that meet the goal

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [x] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 0.0
Support 'new posts' prompt on latest search tab

<!---
Please read this!

The Defintion of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->

Improve engagement on search latest feeds by introducing the 'new posts' prompt. 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Use the same logic we are using for the newsfeed latest page. 

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

- Make a search, go to latest
- Create a new post and wait 30 seconds for the 'new posts' prompt to display

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

N/A (we already have this on newsfeed)

## Personas

<!---
Who does this user impact and why
--->

N/A

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

Introduce a new experiment

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [x] Introduce to search latest tabs
- [ ] Spec tests
- [x] Experiment setup on growthbook

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [x] Weighted
- [ ] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 5.0
Rich embeds not working for non media links

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

Rich embeds not working for non media links

### Steps to reproduce

1. Go onto staging 
2. Enter minds URL
3. See no preview

### Platform information 

Web replicated Firefox

### What is the current *bug* behavior?

No preview appears

### What is the expected *correct* behavior?

Preview should appear.

### Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)

### Possible fixes

Likely relates into Odysee Rumble preview changes

Story points: 1.0
Channel Recommendations See More section is empty but the top recommendation panel still continues to see new recommendations

### Summary

See More page is empty but I still see new channel recommendations after refreshing the page. 

### Steps to reproduce

1. Open minds + turn on experiment.
1. Navigate to a channel with no post.
1. View the top Recommendations.
1. Tap on See More and subscribe to all until no more see more recommendations.
1. Now, go back to profile after refresh.
1. Notice that three top recommendations are still there as expected.
1. Subscribe to the top 3 recommendations now.
1. Notice that see more is empty still.
1. Go back to profile and refresh.
1. Notice that new top 3 recommendations have showed up which never existed in See more option. This is an inconsistency issue.

### Platform information 

Chrome - All browsers

### What is the current *bug* behavior?

See More is empty but recommendations are still available. 

### What is the expected *correct* behavior?

Data inconsistency issue. We should have channels under see more section if recommendations are still available. 

### Relevant logs and/or screenshots

![ChannelRecBug](/uploads/5ad0ba417f803129672e82ef92c56dce/ChannelRecBug.mov)

Story points: 3.0
Channel Recommendations See More section is empty but the top recommendation panel still continues to see new recommendations

### Summary

See More page is empty but I still see new channel recommendations after refreshing the page. 

### Steps to reproduce

1. Open minds + turn on experiment.
1. Navigate to a channel with no post.
1. View the top Recommendations.
1. Tap on See More and subscribe to all until no more see more recommendations.
1. Now, go back to profile after refresh.
1. Notice that three top recommendations are still there as expected.
1. Subscribe to the top 3 recommendations now.
1. Notice that see more is empty still.
1. Go back to profile and refresh.
1. Notice that new top 3 recommendations have showed up which never existed in See more option. This is an inconsistency issue.

### Platform information 

Chrome - All browsers

### What is the current *bug* behavior?

See More is empty but recommendations are still available. 

### What is the expected *correct* behavior?

Data inconsistency issue. We should have channels under see more section if recommendations are still available. 

### Relevant logs and/or screenshots

![ChannelRecBug](/uploads/9ab96aae32d396ddbb61bfbe5a2d1271/ChannelRecBug.mov)

Story points: 3.0
Activity V2 - Owner Blocks

## Summary
- See codepen proof of concept https://codepen.io/omadrid/pen/VwQjjjO?editors=1100


Remaining owner block issues from the activity V2 MR !1836 

- [ ] Owner blocks in posts need to be stress tested - with long usernames, long handles, lots of badges, etc.
- [ ] Same for owner blocks in comments
- [ ] Same for owner blocks in sidebar

## Acceptance Criteria

- [ ] Spec tests
- [ ] Storybook component to illustrate all the states of an owner block

Story points: 2.0
Enter Tag texbox in Edit Profile does not work

### Summary

Enter Tag textbox is not functional. Cannot type inside it. 

### Steps to reproduce

1. Open minds web.
2. Navigate to your Channel. 
3. Edit your channel. 
4. Choose Hashtags.
5. Notice that you cannot type inside the "Enter Tag" textbox. 

### Platform information 

Firefox - Prod

### What is the current *bug* behavior?

Cannot Type inside the Enter Tag textbox.

### What is the expected *correct* behavior?

Once a user taps the input box, display a toaster notifying they have more than 5 tags already.

### Relevant logs and/or screenshots

![image](/uploads/e146c7d0ba04a9083c3960236e659d67/image.png)

Story points: 1.0
Develop refined and consistent dropdown menu

There seems to be multiple variations of the dropdown menu through the web app. Styles differ from instance to instance as shown below.

![Screenshot_2022-04-08_at_11.10.04](/uploads/24fdf18313e4894acb4233083fd7ff59/Screenshot_2022-04-08_at_11.10.04.png)

See [updated designs](https://www.figma.com/file/EkJej3mKP2lSzmWTLoqlXD/Minds-Design-System?node-id=1179%3A15815) including both light and dark modes.

## Design Notes
* Material icons are optional
* The hover colour is the border colour
* Include a simple transition on hover of 150ms
* Would be nice to quickly fade in/out the menu as it is mounted/unmounted

## Acceptance Criteria

- [ ] Create/Update storybook component
- [ ]  Remove any legacy components and refactor their references
- [ ] Provide steps in MR of every component that has been changed to assist with QA

Story points: 5.0
Do not catch StringLengthValidation errors AND email validation errors.

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

When Activity manager add and update functions throw out StringValidator and Email Verification errors, they're caught and logged at the newsfeed POST endpoint. 

E.g.  https://sentry.io/organizations/minds-inc/issues/2520826688/?project=1538020&query=is%3Aunresolved 

This eats into logs and they should just be errors returned back to the user for consumption.

### Steps to reproduce

Trigger a string length validation error, enter a large post above bounds and see output error is not a StringLengthValidation exception. Look in controller - it is being logged.

### Platform information 

Engine

### What is the current *bug* behavior?

Unneccesary logs

### What is the expected *correct* behavior?

Should not log but should still return error to user - need to check errors are still displayed correctly on web or mob.

### Relevant logs and/or screenshots

```
\Sentry\captureException($e);
return Factory::response([
    'status' => 'error',
    'message' => $e->getMessage()
]);
```

### Possible fixes

We should still log exceptions, so should probably add explicit catch blocks for the exceptions we want to catch and handle differently.

Story points: 1.0
Activity V2 - spacing/font/visibility changes

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

Remaining style issues from the activity V2 MR !1836 

- [x] ensure correct text styles apply to nested `<p>` tags inside in post content description el
- [x] finish translation styles (multiple paragraphs, titles, comments)
- [x] check guest mode comments login notice
- [x] guest mode action buttons styles
- [x] show avatar in modal owner block
- [x] adjust wonky margins in channel recommendations component

- [x] Reduced left-side spacing to 16px
- [x] Reduced right-side spacing to 32
- [x] Reduced font-weight to 400 for time ago and channel handle
- [x] Reduced font-weight for social interaction counts. Previously bold, now medium

Changes have been made to the designs and can be seen here -> https://www.figma.com/proto/oYPYya9Z4G5wqgLvdKDbOB/Revised-Activity-Post?page-id=0%3A1&node-id=3%3A975&viewport=241%2C48%2C0.25&scaling=min-zoom&starting-point-node-id=3%3A975

Story points: 2.0