giseldo/neodataset huggingface dataset:
Discovery tag widget overlaps back button on discovery search results

<!---
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
--->
Make it so tag widget doesn't overlap the back button in discovery search results.

It appears to be happening only in the "latest" tab. 

### Broken
 ![image](/uploads/5631fc8d32ee6f71adaeb7000d40a200/image.png)


### Should always be like this
 ![image](/uploads/e25694ac7d163392d62ec726f01a27e1/image.png)


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Make it so the tag widget doesn't ever overlap the back button

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Discovery feeds for hashtag searches

## 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

## Personas

<!---
Who does this user impact and why (optional)
--->
Searching users

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
None

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] No overlap of tag widget on back button within discovery feed

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Visual design update (compose button on navigation)

<!---
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
--->

- Bring out the primary action of the sidebar/homepage in a way that is very clear visually, and follows the Minds brand. 
- 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- update to the sidebar navigation component in Figma (web).

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->


Link to figma - https://www.figma.com/file/tHjd7fqgBiiTHRTNq5Ltfp/Web---Composer-and-Sidebar-updates?node-id=64%3A6509


![mob-web-sidebar-nav](/uploads/59a7bef70faaf3dddf770bc406e53c0e/mob-web-sidebar-nav.png)

![hover](/uploads/1d51fd1677c6a8f4e9e86f713e6e0cfa/hover.png)

![image](/uploads/797d041fcc32d9f13873f31f07400372/image.png)

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

[front-5924-sidebar-v2](https://growthbook.minds.com/features/front-5924-sidebar-v2)

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Include the navigation rounded overlays
- [ ] Setup experiment

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 3.0
Add Controversial toggle to Boost positions

<!---
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

Give users more control over the ads they see, and convert more users into the Controversial audience to ease pressure on that supply.

---

As a registered Minds user, I want to be aware of the Controversial Boost setting and be able to change it from the Newsfeed so that I can better control the content I see.

## What needs to be done

Add a control to Boost positions (rotator, in-feed) that allows a user to toggle on/off Controversial preference for Boosts.


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

See https://gitlab.com/minds/minds/-/issues/3642

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [x] Tooltip to display next to new settings cog on the boost rotator
- [x] Settings cog to link to boost settings
- [x] E2E tests

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Clarify expectations with Twitter connection for Supermind

<!---
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

As a user responding to a Supermind, I want to know why Minds is requesting permission to post on my behalf and know that nothing is being posted just by connecting w/ Twitter oauth.

As a user responding to a Supermind, I want to visualize what will be posted to Twitter before agreeing to it.

## What needs to be done

Spec improvements to the UX of flows related to posting Superminds to Twitter to address the user stories above.

- Flow 1: Connecting to Twitter oauth before responding to a Supermind offer that requires Twitter repost. (Happens once for a user.)
- Flow 2: Reposting a Supermind respond to Twitter. (Can happen multiple times for a user.)


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

See https://gitlab.com/minds/minds/-/issues/3602

## Personas

<!---
Who does this user impact and why (optional)
--->

Creators

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Implement the design changes in https://gitlab.com/minds/minds/-/issues/3602
- [ ] Update E2E tests

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Enable admin to specify boost rejection reason

<!---
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

As an Admin, I want to specify a reason for rejecting a Boost so that that the customer can get a clear & transparent message.

As a Boost customer, I want clear & transparent messaging so that I can understand why my Boost was rejected.

## What needs to be done

- Update messaging in Boost console for customers
- Update messaging in email for customers

![image](/uploads/2c96199c050fa56d296974092c824f8b/image.png)

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

See https://gitlab.com/minds/minds/-/issues/3650


## Personas

- Admins
- Boost customers

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Store the boost rejection reason in vitess
- [ ] Update the rejection notifications and emails to display the rejection reason
- [ ] Display the rejection reason to the user in the boost console
- [ ] Three reasons to be stored as enums:
  - [ ] Wrong audience
  - [ ] Against Minds Boost policy
  - [ ] Against Stripe terms of service
  - [ ] Onchain payment failed

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Deflake E2E tests

<!---
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

Work on testbed flake

### Steps to reproduce

Run CI

### Platform information 

CI

### What is the current *bug* behavior?

Flakey tests

### What is the expected *correct* behavior?

Common known issues should be fixed.

### 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

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0
Boost v3 remove use tokens modal

<!---
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

Reduce UX friction

## What needs to be done

Remove are you sure you want to use tokens modal when switching between budget panels in boost v3 modal

## QA

Modal should not appear - switching between pools should function correctly. E2E should pass.

## UX/Design

N/A

## Personas

Boosting users.

## Experiments

Covered by larger boost v3 flag - no need to touch for this individual change.

## Acceptance Criteria

- [ ] Keep the component (as we may bring it back), but remove the execution of the popup confirmation modal on switch to token budget selection panel
- [ ] Ensure E2E and unit pass (This WILL LIKELY break E2E)

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Front: Implement new boost console (including admin console)

<!---
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
--->
Provide an interface to be able to view your own boosts, and for admin to be able to accept boosts and view historical boosts. 


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Implement designs found in https://gitlab.com/minds/minds/-/issues/3609 and https://gitlab.com/minds/minds/-/issues/3605

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->
See https://gitlab.com/minds/minds/-/issues/3609 and https://gitlab.com/minds/minds/-/issues/3605

## Personas

<!---
Who does this user impact and why (optional)
--->
Boosters and Admin

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
N/A. Should use the existing epic flag. `epic-293-dynamic-boost`

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Implementation of user console
- [ ] Implementation of admin console that is accessible via a toggle
- [ ] Integration tests (for user console only)

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 13.0
Paywall unlock button not opening wire modal

<!---
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
--->
Users should be able to join each other's memberships. Join membership button is just redirecting to SEP and not opening the wire modal.


![__paywall_Screen_Recording_2022-12-14_at_5.59.34_PM](/uploads/fd0c3cd5de0c2d27dbb4a85e15976ede/__paywall_Screen_Recording_2022-12-14_at_5.59.34_PM.mov)


Update: this may be contained to images/rich-embeds/status posts, as I clicked on a minds+ video and it opened the wire modal. Further investigation required.
## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Paywall button should open wire modal

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Posts behind custom membership paywalls, upgrading to minds+ from a minds+ paywalled activity post

## 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

## Personas

<!---
Who does this user impact and why (optional)
--->
Users who want to access paywalled content

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
none

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Paywall button opens wire modal

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
E2E failures around Supermind

<!---
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

Fix issues with E2E

### Steps to reproduce

Run CI pipeline for front

### Platform information 

CI

### What is the current *bug* behavior?

Fails

### What is the expected *correct* behavior?

Passes

### 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

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0
Replace 'm-discovery__trend' page with SEP

<!---
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
--->
Clicking a "trend" post in discovery feeds should open the item's SEP instead of what seems to be an arbitrary interim trend-specific page. (i.e. it should redirect to `/newsfeed/{guid}` instead of `/discovery/plus/trend/{guid}?f=top`)

Previously this component's existence was justified because of its back button, but now that we have implemented a back button on SEPs, this additional component is not necessary.

This will: 
- Match user expectations for what should happen when an activity is clicked in a feed
- Remove redundant trend-specific activity presentation page so we only have to maintain single entity views in one place

![image](/uploads/fcfddc8097859b2f9942aa104d2d451c/image.png)

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
- Clicking a trend item should open the SEP, not the trend page

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Clicking trends in discovery feed should lead to SEPs

## 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

## Personas

<!---
Who does this user impact and why (optional)
--->
Discovery feed consumers, devs

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
n/a

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [x] Clicking a trend item should open the SEP, not the trend page
- [x] `m-discovery__trend` component deleted

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Update boost token switch confirmation modal text

<!---
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

Avoid confusion when using the term "swap tokens" 

## What needs to be done

Update text to match that of the designs specified here https://gitlab.com/minds/design/-/issues/69#note_1200068740

## QA

Check text matches the design.

## UX/Design

See design linked in card https://gitlab.com/minds/design/-/issues/69

## Personas

Users who want to boost with tokens.

## Experiments

Covered indirectly by dynamic boost epic flag.

## Acceptance Criteria

- [ ] Update text to match copy
- [ ] Make sure E2E tests pass

## 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
UI updates for onchain Boost payment process in new dynamic boost system

<!---
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

Allow for onchain boosts to be submitted for the new dynamic boost pricing system

## What needs to be done

Allow selection of the onchain payment method for onchain boosts - tie to backend in https://gitlab.com/minds/engine/-/issues/2475

## QA

Test onchain boosts on testnet.

## UX/Design

Double check nothing different needs doing to the existing designs taken from https://gitlab.com/minds/design/-/issues/69

## Personas

Onchain token holders.

## Experiments

All under the boost epic flag indirectly.

## Acceptance Criteria

- [ ] Add onchain option for front-end in the modal v2 payment method selector - you can uncomment the HTML in the template and handle the integration on submission in the v2 boost service.
- [ ] We need to confirm the balance we want is the linked wallet balance, not necessarily the Metamask connected wallet's balance (this IS how we do it elsewhere).
- [ ] We need to tie submission flow to the new backend functionality integrated in https://gitlab.com/minds/engine/-/issues/2475
- [ ] E2E tests for onchain **will NOT** be feasible. Make sure to unit test to cover this well.

## 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
Uniqueness verification flow for 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
--->
As a web user, I should be forwarded to the mobile verification flow so that I can join the reward program.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Implement the designs from https://gitlab.com/minds/minds/-/issues/3604


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->
https://gitlab.com/minds/minds/-/issues/3604

## Personas

<!---
Who does this user impact and why (optional)
--->
Token users

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
Yes, to be agreed

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Implement designs provided in https://gitlab.com/minds/minds/-/issues/3604
- [ ] Deepliking/Appstore flow working. QR code links to https://www.minds.com/in-app-verification which will either open the app or have a mobile web page with app store links/apk
- [ ] Integration tests

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0