giseldo/neodataset huggingface dataset:
Mob: Update wallet UI to reflect newly introduced product commissions

<!---
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 communicate to users how much they're earning with the Boost Partners, Minds Pro Referrals, and Minds+ Referrals revshare so that they're satisfied to be part of the program.

## What needs to be done

Add Boost Partners, Minds Pro Referrals, and Minds+ Referrals revenue to the Wallet.

![image](/uploads/87a7f11b7a2c2873f7bf4665e62cfada/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.
--->


[Figma](https://www.figma.com/file/tBOvE8yIILW49vECySCLpZ/Earnings?node-id=124%3A571&t=y4yadJzpQl5tt9Es-1)

**Addition of three new lines to Earnings on both Cash and Tokens that are titled "Minds Pro Referrals", "Minds+ Referrals, and "Boost Partners".**

**Web**

![Earnings_Cash](/uploads/404a7c5d358075defcd3c918d4a8d063/Earnings_Cash.png)

![Earnings_Tokens](/uploads/13f38837221e6994bfd3725e329b99b6/Earnings_Tokens.png)

**Mobile**

![Earnings_Mobile](/uploads/8a480bc1ca13981dd62cb261bf9cb4dd/Earnings_Mobile.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.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

* [ ] Web UX & visuals for the user story (described above)
* [ ] Mobile UX & visuals for the user story
* [ ] 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: 2.0
QA: Support custom codepush

<!---
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 QA's job easier to test custom builds.
- Allow team members to provide feedback to a custom deployment before the code being available on staging or prod
- 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- Support a `mindsapp://codepush/DEPLOYMENT_KEY` deeplink that changes the codepush deployment
- Show a custom deployment warning on the app and have a button to revert to production

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

- make sure u can use a custom codepush link and u can revert back

## 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)
--->

QA, team members

## 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
--->

- [ ] Support a `mindsapp://codepush/DEPLOYMENT_KEY` deeplink that changes the codepush deployment
- [ ] Show a custom deployment warning on the app and have a button to revert to production

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Create an in-feed notice promoting Boost Partners

<!---
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
--->

Clearly communicate to users of Boost Partners through the use of an in-feed notice that prompts them to join Boost Partners.

## What needs to be done

Create an in-feed notice for Boost Partners.

Read more links to: https://www.minds.com/info/blog/introducing-boost-partners-program-1477787849246904328

Settings links to Boost settings.

## 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.
--->

[Figma ](https://www.figma.com/file/W2xIag64EdbWUlGAQOpVHE/Boost-Update?node-id=846%3A19064&t=6dPYn7qWCP7cjdH8-1)

![In-feed_notice](/uploads/f25c6738db59a1bfe37bd38042c0b378/In-feed_notice.png)

![In-feed_notice](/uploads/d346d5d9948afa3f330b7e4cc0aa803e/In-feed_notice.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.
--->


## 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
Show Keyboard in comments when no comments exists

<!---
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

Show Keyboard in comments when no comments exists

(Summarize the bug encountered concisely)

### Steps to reproduce

Go on comment on any post with no existing comments. The screen is blank and no keyboard.

(How one can reproduce the issue - this is very important)

### Platform information 

(Browser, device, system stats, screen size)
all

### What is the current *bug* behavior?

When in the comments screen of a post with no comments, the keyboard is not visible.

(What actually happens)

### What is the expected *correct* behavior?

When in the comments screen of a post with no comments, the keyboard should be visible so the user can start typing.

(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: 3.0
Error when restaring the app due to deprecated method



### Summary

The app crash when it resets (Main app component is unmounted) due to a deprecated method

It affects mostly development since it happens when the app is unmounted

### Platform information 

Both

### What is the current *bug* behavior?

It throws an error when the app is remounted

### What is the expected *correct* behavior?

It should unmount without errors

### Relevant logs and/or screenshots

-

### Possible fixes

Remove the removeListener method calls

Story points: 2.0
Adding error boundary in screen 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

- Adding error boundary in screen component 

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## 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.
--->

## 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

Automated version bump

Story points: 5.0
Boost service is injecting malformed entities into the feed



### Summary

The boost service is injecting malformed entities into the feed\

I presume that it is the cause of the getAvatarSource missing function errors

### Steps to reproduce

- Load the feed
- Boosted posts are rendered empty and showing a wrong date error

### Platform information 

both

### What is the current *bug* behavior?

Boost not rendered correctly

### What is the expected *correct* behavior?

Boots should be shown

### Relevant logs and/or screenshots

-

### Possible fixes

TBD

Story points: 3.0
Mobile component (Boost Rotator)

<!---
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
--->

To design a native like mobile component for our in-feed boost rotator. 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- To design a mobile version of the in-feed boost rotator, with a carousel / swipe interaction. 
- Note - The carousel wraps around, so the last post will, upon a users' swipe surface the first boosted post in the rotator feed again.
- To ensure some parity between web and mobile, **tapping onto a boosted post will take the user to the specific SEP**, instead of a full screen/moments like carousel.  
- suggestion: use reanimated/snap carousel 
- use suggested height or adjust based on device screen height.

## 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.
--->

-swipe interaction on mobile, similar to Instagram

link - https://www.figma.com/file/zheu8ANcXw49YL6kSfSmlh/Boost---In-feed-rotator-(Settings)?node-id=274%3A19642

![mobile-boost-rotator-proto](/uploads/e209651fc175d9b7d282ce265d9f8267/mobile-boost-rotator-proto.mov)


![mobile-boost-rot-fixed](/uploads/d1453ff92384b59ea897f0dc056ed025/mobile-boost-rot-fixed.png)

##### Updated designs with fixed height container 

![image](/uploads/ce5460b306cbe3608493ce19844e5c63/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.
--->


## 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
- [x] UX/Design
- [ ] Personas
- [ ] Experiments

Design

Story points: 8.0
Refactor developer options feature flags section

<!---
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

Refactor the devopt feature flags section to limit only to those which are present in the app.

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done

- export existing  ff from ExperimentsProvider
- only list those in devopts

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->


## QA

- in devopts only limited FF should exists
<!---
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
--->

- [ ] Check that only the FF in ExperimentsProvider are present

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Refactor general error screen with app restart button

<!---
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

Make sure that users can restart the app in the case of a major error intercepted by the error boundary. Currently the error screen allows only to copy the error stack trace but the user is stuck. 
<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done
- Implement an error screen with options to copy the stack trace and a button to restart the app.
<!---
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
--->
- need to implement a way to trigger an exception to be caught by the new error boundary.

work included in: https://gitlab.com/minds/mobile-native/-/merge_requests/2185

[Merge request 2217](https://gitlab.com/minds/mobile-native/-/merge_requests/2217)

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->
- @mwrobs it would be nice to have a designed screen with a nice copy if you have time, but not blocking. We'll implement it with a text and a restart button on the bottom of the screen.

## 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
--->

- [ ] On exception the screen is present
- [ ] Can copy the stack trace
- [ ] Can restart the app at the button click

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
Add boosts to story swiper

## Goal

Increase Boost impressions.

---

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 Boost slot to the mobile story swiper.

## 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.
--->

[Figma](https://www.figma.com/file/W2xIag64EdbWUlGAQOpVHE/Boost-Update?node-id=755%3A18187&t=0SXJFqBrQKqxdiqo-1)

We will be increasing boost inventory space by placing boosted posts in between moments similar to how Instagram does sponsored posts in between stories. 

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 user's moments will continue to be used. 

**Start of Boosted Moment**

![Boosted_Moment_Start_20_Secs](/uploads/5deda1ec8e909e4763557a60ecfa4cdf/Boosted_Moment_Start_20_Secs.png)

**End of Boosted Moment**

![Boosted_Moment_End_20_Secs](/uploads/e34aa2d78f451f8ca7735beee55ff582/Boosted_Moment_End_20_Secs.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.
--->


## Acceptance Criteria

* [ ] Web UX & visuals for the user story (described above)
* [ ] Mobile UX & visuals for the user story
* [ ] 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: 8.0
Update Minds Chat app on minds.com/mobile

<!---
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

Get users who sideload the Android app onto the latest version of Minds Chat.

## What needs to be done

Make the latest version of Minds Chat for Android available at:

https://www.minds.com/mobile

Provide the right link to the FE team to update the site.

## 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
Implement new colors and themes for design v2



## Goal

Implement the new themes and colors for the new TAMAGUI components



## What needs to be done

Implement the colors

https://design.minds.com/3d3fe81da/p/379be4-colors/b/14679d

https://gitlab.com/minds/front/-/blob/design-system-v2.0.0/src/stylesheets/themes.scss

## QA

TBD


## UX/Design

https://design.minds.com/3d3fe81da/p/379be4-colors/b/14679d

https://gitlab.com/minds/front/-/blob/design-system-v2.0.0/src/stylesheets/themes.scss

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] All the colors should be present on both themes
- [ ] A colors screen should be added to the storybook screens

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
CodePush release - 4.32.2

<!---
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.2


## 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.

## 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