giseldo/neodataset huggingface dataset:
As a user, I should be able to see new dynamic boosts in the rotator and in-feed slots and sidebar slots

<!---
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 user, I should be able to see new dynamic boosts in the rotator and in-feed slots

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
When the feature flag is on, point to the new boost v3 endpoints instead of the v2 ones. 

## 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.
--->


## 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.
--->
Use the epic flag

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Implement rule Boost-19 - "Activity boosts will only ever go to newsfeed slots. Channel boosts will only even go to sidebar slots. Other entity types are not supported"
- [ ] Implement rule Boost-16 - "Safe boosts will be delivered to users who have opted to see Open boosts. Open boosts will Never be delivered to users who have opted to see safe boosts."

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
When I block someone via their post, the post should immediately disappear

<!---
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
--->

Post should immediately hide from view when user blocked in dropdown.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Just make it not require a refresh. Should disappear live. 


## 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.
--->


## 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
--->

- [ ] From feeds such as top discovery, blocking someone should remove the feed
- [ ] Integration test

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Update slider behaviour for cash boost 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

Slider behavior is currently a bit trickier to use and adjust, we need to improve the feel and allow selection of differing amounts

## What needs to be done

----
@markryansallee to confirm behavior and remove this block. Questions:

1. What if a user wants to select a value outside of the ranges, such as $11 - is that not going to be possible? **DO NOT ALLOW $11 if it is not a segment provided from the backend.**.
2. Do we want the sliders to snap to the different values? **Yes, they should snap to values from the backend**.
---

Modify the slider such that the behavior matches the below:

![image](/uploads/e8f7c24d757018eb87549f030a2ccef6/image.png)

## QA

Test sliders

## UX/Design

See https://gitlab.com/minds/design/-/issues/69

## Personas

Boosting users

## Experiments

No direct experiment but is indirectly under the cash boost flag already.

## Acceptance Criteria

- [ ] Assess whether the native HTML input meets the criteria or if we should use something like https://angular-slider.github.io/ngx-slider/docs/classes/\_options\_.options.html
- [ ] Match amount sliders for cash and tokens to the behavior specified under the `What needs to be done` header above.
- [ ] Make sure we have "thumbs" above the slider than show the value on drag.
- [ ] Update E2E & Unit tests.

## 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
Add confirmation modal for cash boosts

<!---
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 indicate that a user is about to boost for cash to alleviate confusion and accidental spending in the cash tab of the new boost modal designs.

## What needs to be done

Add a confirmation modal like this upon submitting a cash boost.

![image](/uploads/1ec1f8250535f5f989809ed62963de29/image.png)

## QA

Text that confirmation modal appears when making a cash boost.

## UX/Design

Agreeing to use existing components, and that this does not need a design spec.

## Personas

Boosting users.

## Experiments

Indirectly covered by the cash boost experiment, but no individual flag is needed for this.

## Acceptance Criteria

- [ ] Add confirmation modal that only appears when submitting a cash boost (NOT TOKEN)
- [ ] Confirm the text to be within the modal - minor adjustments will be needed
- [ ] Check E2E tests don't need quickly updating - if they do it might be better to create a new Fragment for the confirmation modal, that can be used within the BoostMOdal fragment on hitting post for cash.  
- [ ] Fix any broken unit tests

## 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: 2.0
Cleanup guest mode and reimplement

<!---
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
--->

- Improve traffic to homepage
- Lower bounce rate
- Better understand logged out users

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
- [x] Pick feed(s) : discovery
- [x] Track logged out traffic over time -- retroactive, no action needed

HIDE
- [x] Discovery "Your tags" tab
- [x] Discovery content settings menu (contains social compass survey)
- [x] Referrals link in more menu
- [x] Minds+ upgrade banner at top of feed
- [x] Extraneous border in trends feed
- [x]  Extraneous border on discovery trend page

PROMPT AUTH MODAL
- [x] Supermind button - already prompts auth modal, no change made

OTHER
- [x] Leave in deployment notes: Pick A/B test - enable 'discovery-homepage' 50/50 
- [x] Upvote and downvote buttons - prevent wiggle animation 
- [x] Make SEP metrics unclickable for guests
- [x] Auth modal checkboxes need vertical spacing 
- [x] Remove the padding on discovery guest mode - not replicable, no changes made

## 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.
--->


## 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
--->

- [ ] Everything in list above has been addressed
- [ ] Run experiment in 50/50 on in production 

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
UX&D: Clarify expectations with Twitter connection for Supermind

## 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.)

## Personas

Creators

## UX Design


**Flow 1* [Figma](https://www.figma.com/file/thrGepQAxmcMGB7MoEEckM/Supermind-%5B*%5D?node-id=2811%3A31541&t=4kgNbxP93gHPbgNt-1)*

![Twitter_Permission_Explanation](/uploads/efb12afa9a22d0795ff9bea592957af5/Twitter_Permission_Explanation.png)
![Mobile_Supermind_-_Accept_Confirm](/uploads/f08b1e1e6d6917db06f34497d068f4fa/Mobile_Supermind_-_Accept_Confirm.png)


**Flow 2 [Figma]([Figma](https://www.figma.com/file/thrGepQAxmcMGB7MoEEckM/Supermind-%5B*%5D?node-id=2910%3A31901&t=aNbS7orprXH38kvd-1))**

Web

![Updated_Creator_View_Reply_Confirmation__Twitter_Required_](/uploads/509b64d0caefce97b4e7d41b8e1a4dd1/Updated_Creator_View_Reply_Confirmation__Twitter_Required_.png)

Mobile

![Updated_Creator_View_Reply_Confirmation_Mobile__Twitter_Required_](/uploads/a2f095e307a27efc8a8b4e571d566d2c/Updated_Creator_View_Reply_Confirmation_Mobile__Twitter_Required_.png)

**Placeholder Image**

![Placeholder_Image](/uploads/50ca894cc1a15c0b86c7433927e9f36f/Placeholder_Image.png)


## Acceptance Criteria

* [x] Web UX & visuals for the user story (described above)
* [x] Mobile UX & visuals for the user story
* [x] Developer feedback on feasibility
* [ ] User feedback on usability

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Channel recs descriptions are cut off in mobile 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
--->
![image](/uploads/ce2d747ba7b8385d0135804d8b741fd1/image.png)
The words in the descriptions should be completely visible, not cut off by the subscribe buttons

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Make the description text end before the subscribe button starts

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Channel recs visual testing

## 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)
--->
Feed 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.
--->
n/a

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] descriptions visible in channel recs in mobile web

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Chann

Story points: 1.0
Build out new boost creation flow

<!---
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
--->
Allow for users to create a boost that can run over multiple days

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Build out components and the flow as per the UX mockups and flows. 

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
See flows. 

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->
Mockups provided in https://gitlab.com/minds/design/-/issues/69


## Personas

<!---
Who does this user impact and why (optional)
--->
Boosters

## 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

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Implementation of UI components and flow as per UX mockups
- [ ] Experiment flag is setup 
- [ ] E2E tests

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
Unable to post non-Supermind content

<!---
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

Cannot post anything non-Supermind.

### Steps to reproduce

Try post something non-Supermind.

### Platform information 

Web.

### What is the current *bug* behavior?

Cannot post anything non-Supermind.

### What is the expected *correct* behavior?

Posting should not be blocked.

### 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

https://gitlab.com/minds/front/-/commit/69235a3eaf64dd5ac4068809d8d8de4f66294bc4#3fd109284c102fb50ee477c50db8f0e6233643c8_430_435

Story points: 2.0
Supermind button on own posts should not pre-populate own channel name

### Summary

When clicking a Supermind button on your own post, the Supermind dialog appears and pre-populates the `Target` field with your own channel name.

### Steps to reproduce

- Navigate to an activity post you own
- CLick the Supermind button on the activity post (large button, or activity bar button)

### Platform information 

- Web

### What is the current *bug* behavior?

- The Supermind screen pre-populates my own channel name in the `Target` field

### What is the expected *correct* behavior?

- The `Target` field should be left blank when clicking Supermind buttons from my own posts

### Relevant logs and/or screenshots

![image](/uploads/9d9f7d3a9a23bf8f13cd653ee21ed4f1/image.png)

![image](/uploads/7b89fe172be952fec33409eec8ccef0a/image.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0
Create secondary e2e test user (if it hasn't been created already)

<!---
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
--->
Create secondary generic test user `playwright_tests_user_2` with password shared in bitwarden. To be re-used in situations that require multiple generic users.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
- Register a new account with username `playwright_tests_user_2`
- Share the password in Bitwarden
- Add a reference about it in the e2e/tests .env examples file

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
None

## 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)
--->
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
--->

- [ ] new test user created
- [ ] password is shared on bitwarden
- [ ] reference in .env examples

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Migrate data-cy tags over to data-ref tags

<!---
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

Unify our data tag naming standards between E2E and our data pipelines.

## What needs to be done

Migrate our existing data-cy tags over to data-ref syntax and ensure that we have set rules in place for naming conventions. Some tags WILL need renaming as we must ensure they are relevant for data.

## QA

Tests should green light.

## UX/Design

N/A

## Personas

Developers and Data

## Experiments

N/A

## Acceptance Criteria

- Decide on the syntactic structure of a data-tag name and define it in our E2E docs - maybe reference it in a data docs page
  - Simple example could be `data-ref=block-element`, so for example implemented we could see `data-ref=composer-modal-submit-button`. Anything we can do to improve naming consistancy would be very much appreciated on the data side, so if they could regex out all `submit-button`'s, that'd be ideal. This is not neccesarily something easy to do cleanly but a clear definition helps
  - Bounce the proposal off @michael4tasman and @markryansallee before chiseling the rule into stone.
- Get rid of `data-minds` section of tag name - it's useless
- Update existing Codecept / Playwright E2E tests
- Update existing tags that are not already in use to abide by the convention.
 
# Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 2.0
Remove 'minds-2263-clustered-recs' and 'minds-2933-channelrecs' experiment flag

<!---
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.
--->

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Remove 'minds-2263-clustered-recs' experiment flag and cleanup old code

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
TBD

## 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)
--->
:nerd: 

## 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
--->

- [ ] Remove 'minds-2263-clustered-recs' experiment flag
- [ ] Remove 'minds-2933-channelrecs'
- [ ] Remove 'engine-2364-vitess-clustered-recs'

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0