giseldo/neodataset huggingface dataset:
Unlock premium content without page refresh after subscribing to Minds+

<!---
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

Improve the experience of signing up for Minds+.

## What needs to be done

- Given a user clicks to `Unlock Post` on a piece of premium content
- and the Minds+ subscription modal appears
- and the user subscribes to Minds+
- when the Minds+ subscription modal closes
- then the premium content they originally clicked is unlocked without them having to refresh the page.

![image](/uploads/a172b643b3067d8fd7e09ec2562596f3/image.png)

## 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
--->

- [ ] The bug is resolved and a refresh is not required.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Add option to report Minds+ content for violating content policy

<!---
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

Enable the community to contribute in moderating the quality of Minds+ premium content.

## What needs to be done

- Add an option to the list of Report Reasons: Violates Premium Content policy
- Display the option when reporting content that is Premium Content

![IMG_459C75614CA1-1](/uploads/4b89addce84da029375c013aca4ff607/IMG_459C75614CA1-1.jpeg)

![image](/uploads/454c05ce8155c2174aa2938659550f54/image.png)

## 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
--->

- [ ] Accepted reports de-monetize the content
- [ ] Accepted reports generate a strike
- [ ] If a user receives 3 strikes then they can no longer post to Minds+

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Introduce Rate Limiting for Nostr Relay

<!---
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

In order to help mitigate the root cause of our recent outage (caused by a flood of relay traffic), we need to implement rate limiting. We can use Redis for this, possibly w/ a library such as [this](https://www.npmjs.com/package/rate-limiter-flexible).

### Steps to reproduce

Have one socket spam Nostr client with many requests

### Platform information 

Engine

### What is the current *bug* behavior?

Nostr is down

### What is the expected *correct* behavior?

Nostr should be up, we should patch the implementation by rate-limiting requests by Socket ID for now, application-side.

### 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
Mind+ feed frequently is blank

<!---
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 Minds+ feed (https://www.minds.com/discovery/plus/overview) is currently empty. This has happened a number of times in the past ~1 month and warrants finding the root cause.

### Steps to reproduce

- Navigate to the Minds+ feed (https://www.minds.com/discovery/plus/overview)

### Platform information 

- MacOS + Chrome

### What is the current *bug* behavior?

- The `Overview` tab is blank

### What is the expected *correct* behavior?

- The `Overview` tab is NOT blank

### Relevant logs and/or screenshots

![image](/uploads/129bcf5c5acb3cdab26adee2c4607bca/image.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
Boost Partners: Dev spike on revshare

<!---
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
--->

Dev spike to investigate and understand complexity and scope of Boost Partners revshare program.

See: [Application business logic](https://docs.google.com/spreadsheets/d/1kTSD8Av9rjbYOQjE4aH4EotkRcBdPc-9nTkuBpOJpBM/edit#gid=0)

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->


## 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
--->

- [ ] Proof of concept
- [ ] Further tasks built to deliver Boost partners epic

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Dev

Story points: 3.0
Gif Images Not Playing Correctly

<!---
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
--->

Gifs seem to only be presenting the first frame, rather than playing correctly. See the video for example:

[before.mkv](/uploads/2f87afd6cb637fcfe1b25917943ba15d/before.mkv)

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

We should only remove EXIF data for non-gif images to avoid stripping the other frames. Alternatively, we could loop over the frames in the gif to include them in the new image. 

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Test uploading a gif

## 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)
--->

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.
--->

N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Gifs play correctly

## 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: 1.0
When posting links in the comments, the text of the link hides between the thumbnail

<!---
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 posting links in the comments, the text of the link hides between the thumbnail

### Steps to reproduce

1. Choose a post and a link
2. Make a comment on the post, containing the list
3. See that before sending, the preview looks correct
4. Send the comment
5. Notice that the text now is hidden behind the image

### Platform information 

Brave and chrome, win10

### What is the current *bug* behavior?

Link previews text hidden behind image

### What is the expected *correct* behavior?

Link previews should show like they do on feed post (the text should be next to the image)

### Relevant logs and/or screenshots

![image](/uploads/e668dda8b3ef35a4176acf869adfe301/image.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0
Record 'view' events on InFeed notices

<!---
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
--->
Gain insights into the effectiveness of the feed notices by tracking their visibility 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Use the new 'generic' events to trigger a 'view' when the in feed notice is displayed

## 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.
--->
N/A

## Personas

<!---
Who does this user impact and why (optional)
--->
All 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
--->

- [x] Generic view even is recorded when in feed notices are displayed
- [x] Each in feed notice has an appropriate reference

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Channel boost in-feed notice

<!---
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

Test the effectiveness of in-feed notices for promoting channel boosts.

## What needs to be done

Create an in-feed notice that prompts users to Boost their channel.

![image](/uploads/7fdd1d24c020b9fb72e0733aca48407f/image.png)

| Notice            | Description                                                                                      | Dismissable | Position | Sticky | Display priority | Conditions        | Primary action                        | Secondary action                   |
|-------------------|--------------------------------------------------------------------------------------------------|-------------|----------|--------|------------------|-------------------|---------------------------------------|------------------------------------|
| Expand Your Reach | Use Boost to reach new audiences on Minds. Boosted channels get more engagement and subscribers. | Yes         | Top      | No     | 3.1              | Email is verified | Boost Now (opens channel Boost modal) | Learn More (opens minds.com/boost) |

## 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
--->

* [x] An `Expand Your Reach` in-feed notice appears in the Newsfeed for users with verified emails, and no higher-priority notices. (BH: criteria changed - see comments)
* [x] Events are measured to enable the later analysis of which test variant performed best, including:
  * [ ] Views of the notice (bh: not to be handled by this card)
  * [x] Clicks on "Learn more"
  * [x] Clicks on "Boost Now"
  * [ ] Successful Boost purchases (bh: not to be handled by this card)

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Add refund policy checkbox to Boost purchase modal (mobile)

## Goal

Avoid users making cash purchases without knowing, and get agreement on refund policy.

## What needs to be done

Add a checkbox to the cash tab of the boost modal that asks users to agree to the refund policy.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

Add a checkbox to the bottom of the CASH tab in the boost modal with the following text.

> I understand this cash transaction is non-refundable once the boost is approved

![image](/uploads/d9cfb66724dcf3dbbfd6c2e7865971ca/image.png)

![image](/uploads/581f59045c635d79bcab0eba7924393a/image.png)


## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

n/a

## Acceptance Criteria

- [ ] Given the user is on the CASH tab of the boost modal, a checkbox appears with the message spec'd above
- [ ] While the checkbox is disabled, the `Boost Post` button is disabled
- [ ] The checkbox is disabled by default
- [ ] Fix E2E tests that this breaks
- [ ] Unit test

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Various site functions down

<!---
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

- Search does not work
- Notifications don't show
- No trending
- No boost
- No commenting
- No upvoting
- Site is overall slow


### Steps to reproduce

(How one can reproduce the issue - this is very important)

### Platform information 

(Browser, device, system stats, screen size)

### What is the current *bug* behavior?

(What actually happens)

### What is the expected *correct* behavior?

(What you should see instead)

### 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
Update Boost in-app / push notifications

## Goal

Improve Boost in-app / push notifications.

As a customer, I want in-app notifications so that I have confidence about the status of my order. 

## What needs to be done

Automate the delivery of in-app and push notifications to customers, alerting them to the current status of their Boost orders.

![image](/uploads/5ba58cf8fbab89c611b243a178ccb980/image.png)

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

- Use standard in-app notification layout.
- Use Boost icon

| Event               | Subject                    |
|---------------------|----------------------------|
| Boost rejected      | Your Boost was rejected.   |
| Boost start running | Your Boost is now running. |
| Boost completed     | Your Boost is complete.    |

## Personas

Boost customers

## Experiments

n/a

## Acceptance Criteria

- [x] A customer receives a notification when a Boost is rejected.
- [x] A customer receives a notification when a Boost begins running.
- [ ] A customer receives a notification when a Boost order is complete.
- [x] The notifications click through to the Boost console where they manage the Boost order.
- [x] Rejected boosts should link to the activity post/channel
- [x] Non-rejected boost notifications should go to the boost console

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Send Bulk Supermind to all current Minds+ and Pro members monetized on Stripe



## Goal

Thank Minds+ and Pro subscribers.

## What needs to be done

Send Bulk Supermind to all current Minds+ and Pro members monetized on Stripe.

- Originating activity post: https://www.minds.com/newsfeed/1462583221886652417
- Offer amount: $5
- Reply type: Video
- Email title: `Baste Records sent you a $5 Supermind offer`
- Email copy: `As a Minds+ / Pro subscriber, you are eligible to receive cash Supermind offers from various brands on Minds. Baste Records is offering you $5 to answer a question for them. Give them a sub if you want more from them in the future!`
- Recipients: Minds+ / Pro subscribers who are connected to Stripe

---

- We've budgeted for this campaign to generate ~100 responses
- We should roll out to users who meet the recipient criteria above progressively, so that we don't overshoot the budget (assuming the eligible recipients are more than 100 people)
- We can start by sending it out to 100 eligible recipients, based on how recently they signed up for Minds+ / Pro
- As we understand the response rate for that 100, we can send out to the next batch progressively to hit our target.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

n/a

## Personas

Minds+ / Pro customers.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Send a Bulk supermind campaign on day 2

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Update Boost emails

## Goal

Improve Boost email notifications.

As a customer, I want email notifications so that:

- I have confidence about the status of my order. 
- I have confidence about what I ordered. 
- I have confidence about my money.

## What needs to be done

Automate the delivery of emails to customers, explaining the current status of their Boost orders.

![image](/uploads/3c9e096124c04d9266b73bd2fcdd5210/image.png)

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

- [Figma mocks](https://www.figma.com/file/ySQF1fKncYUMqwjBb2OKCx/Boost-emails?node-id=160%3A2382&t=EqGdCRV5ybIMdRzq-4)
- [Email copy (spreadsheet)](https://docs.google.com/spreadsheets/d/1_9_G5MwrmFZ7fVzR_nuLpUKVY8BhAksrCUnaOIHkhqI/edit#gid=0)

![image](/uploads/4db2ee21363570a277ce3af8c0445d41/image.png)

## Personas

Boost customers

## Experiments

n/a

## Acceptance Criteria

- [x] A customer receives an email when a Boost order is made.
- [x] A customer receives an email when a Boost is rejected.
- [x] A customer receives an email when a Boost begins running.
- [x] A customer receives an email when a Boost order is complete.
- [x] The email template contains CTAs to the Boost console where they manage the Boost order.
- [x] The email template contains a summary of the Boosted content to better identify which Boost is being updated.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0