giseldo/neodataset huggingface dataset:
Newsfeed: enable boosts in the top feed

<!---
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
--->

We need to show boosts in the top feed


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Enable boosts in the top feed


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

N/A

## 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.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Boosts should be visible in the top feed

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Mob: Retain referrer for 72h

<!---
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
--->
In order to expand the affiliates program, we wish to be able to use the referral links for logged in users too. The tags can then be used to attribute the referrer. 

In the case of a deeplink with referral, extract the referrer and save it for 72h.
All subsequent API calls will add the referrer as header/member in payload.
Should handle multiuser: referrer sent for all users or bound to the current user who processed the initial deeplink (@markryansallee pls clarify)

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
- extract referrer from deeplink with referral, and save it for 72h.
- add the referrer as header/member in payload for all subsequent API calls.

See AC below

## 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.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [x] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->
Affiliates

## 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
--->

- [ ] Referral param (referrer) will be overwritten by the last referral link visited
- [ ] Referral param (referrer) will expire after 72 hours
- [ ] Referral param (referrer) should work for existing logged in users

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Moments: Timer

## Goal

Improve Moments UX

---

As a Minds, I want to increase Boost inventory supply so that I can better fulfill the demands of customers.

## What needs to be done

Add a 20s timer to moments with an animation in the page indicator

## 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.
--->

[Figma](https://www.figma.com/file/W2xIag64EdbWUlGAQOpVHE/Boost-Update?node-id=755%3A18187&t=0SXJFqBrQKqxdiqo-1)

We will also be putting a 20-second timer on the duration of each moment from now on, both non-boosted and boosted moments. This timer will apply to a progress line above each moment. The normal transition between different users' moments will continue to be used. 

**Start of Boosted Moment**

![Boosted_Moment_Start_20_Secs](/uploads/633c82d87ad68fca76ae0a02bfb5c197/Boosted_Moment_Start_20_Secs.png)

**End of Boosted Moment**

![Boosted_Moment_End_20_Secs](/uploads/608fd706171f00bea46b0616a828ab0e/Boosted_Moment_End_20_Secs.png)

## Personas

<!---
Who does this user impact and why (optional)
--->

Moments 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.
--->


## Acceptance Criteria

* [ ] apply a 20s timer to each moment page
* [ ] long pressing the screen or interacting with the post (comments, share, etc.) should pause the timer
* [ ] the page indicator on top of the moments should fill to show the progress of the timer
* [ ] no progress if the moment timer if it's a video or better mimic the progress with the video progress.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
Mob: Top bar alert component

<!---
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
--->

Introduce a horizontal bar like we have used in the past for full-site alerts for the purpose of educating users about the referral and commission program.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- Create a reusable banner 
- Update text to say "[Refer](https://www.minds.com/settings/other/referrals) sales, fans and creators for cash and token commissions"
- Enable the component to be expandable in the future for other such notices similar to how in-feed notices rotate
- Ensure clicks and dismissals can be tracked

## 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.

None

--->

- Component should stick to the top of the viewport on scroll until dismissed.
- Clicking the underlined text navigates to a specified URL.
- Clicking the underlined text DOES NOT dismiss.
- Clicking the x button dismisses.
- When a banner is dismissed, it stays dismissed until a new banner message is published.

[Figma](https://www.figma.com/file/DQPKf1c2Vxv4EXV1JMyHu5/Top-Bar-Alert?node-id=11-2145)


## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [x] Is Mobile Required?

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
IAP: Implement quantity support for Android in react-native-iap package

<!---
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

Provide quantity support for android product purchase in react-native-iap package.

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done

- add native code to support quantity
- update js code to support quantity arg
- test to see the quantity is being used

<!---
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.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
CodePush release - 4.32.5

<!---
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
--->
CodePush release - v4.32.5


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Run a smoke test and review all already tested tasks from staging environment.

#4820 
#4659
#4824
#4814
#4828  
#4811 
#4658

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
- Base store version: v4.32.1
- Codepush environment: staging

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Videos: Full screen button throws an error on consecutive use

<!---
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

Full screen button throws an error on consecutive use

### Steps to reproduce

1. have 2 consecutive videos on your channel
2. press full screen button on video 1
3. dismiss full screen modal
4. press full screen button on video 2
5. notice the error and that full screen won't work anymore

### Platform information 

tested on iOS, possibly both

### What is the current *bug* behavior?

full screen modal doesn't work

### What is the expected *correct* behavior?

full screen modal should always work

### 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.)

![image](/uploads/e4588149f5c38ddb485ce4e09cb8071b/image.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 3.0
Revert boosted content service changes and verify if it works with the fix of the endpoint



## Goal

Now the endpoint is fixed we should test reverting the changes of the boosted content service

Engine:
https://gitlab.com/minds/engine/-/merge_requests/1269

Mobile: (To be reverted)
https://gitlab.com/minds/mobile-native/-/merge_requests/2160


## What needs to be done

Revert the changes of https://gitlab.com/minds/mobile-native/-/merge_requests/2160
- this problem is related to cache and happens in the second run.


## QA

Boost should be injected into the feed

The original problem was with cached Boosts. 
So in order to test this:
 - Open the app and close it after a few seconds 
 - Open the app again, and check that the boosts are injected into the newsfeed and that they render correctly

## Acceptance Criteria

- [ ] Changes reverted
- [ ] Boost should work as expected

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Revert

Story points: 3.0
IAP: Implement Android refund for boosts + dummy API call

<!---
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

Provide in-app purchase support to app.

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done

- Implement Android refund for boosts
- Add relevant screens and hooks
- Add dummy API call for backend

<!---
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.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
IAP: Add FF to potentially hide cash option for GooglePlay users

<!---
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.
--->

Old title: ~~IAP: Implement Android item payment for boost + dummy API call (optional iOS)~~

## Goal

Provide in-app purchase support to app.

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done

~~- Implement Android item payment for Minds Plus~~
~~- Add relevant screens and hooks~~
~~- Add dummy API call for backend~~
~~- (optional) add iOS support~~

Impossible to have a decent technical solution. The current UI would generate 464 unique products with values from $1 to $9000 to be defined in Google Play In-App Purchases.

Repurposed to 
- keep the boost cash option behind a feature flag (default off) - `mob-4836-iap-no-cash`
- prepare an appeal to be sent to Google following their terms violation warning, arguing that there's no decent technical solution to implement boosts with IAP in absence of quantity thus requiring the implementation of at least 454 distinct products, and also the lack of prepaid product since we cannot bill the users after the service would be provided.

@markryansallee, @ottman, @markharding 


<!---
Clearly detail what needs to be done to achieve the goal set out above
--->


## QA

[MR 2184](https://gitlab.com/minds/mobile-native/-/merge_requests/2184) 

<!---
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.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
IAP: Implement Android subscription for Minds Plus + dummy API call (optional iOS)

<!---
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

Provide in-app purchase support to app.

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done

- Implement Android subscription for Minds Plus
- Add relevant screens and hooks
- Add dummy API call for backend
- (optional) add iOS support

<!---
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.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
IAP: Separate the payment for downloaded app - (include all payments, refunds entry points)

<!---
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

Provide in-app purchase support to app.

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done

- separate the payment for downloaded app - (include all payments, refunds entry points)

<!---
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.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
IAP: Check the requirements for testing in-app purchase (or use test accounts with refunds)

<!---
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

Provide in-app purchase support to app.

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done

- Check the requirements for testing in-app purchase (or use test accounts with refunds)
- Add relevant info to this ticket (No MR).

<!---
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.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0