giseldo/neodataset huggingface dataset:
SPIKE: Design System for 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

<!---
Clearly outline the goal of the issue and why we are doing it
--->

Technical analysis for the implementation of https://gitlab.com/groups/minds/-/epics/290

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Technical analysis for the implementation of https://gitlab.com/groups/minds/-/epics/290

## 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.
--->

Work with design will be required @mwrobs 

## Personas

<!---
Who does this user impact and why (optional)
--->

Mobile developers

## 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] technical analysis presented on the epic - [doc](https://docs.google.com/document/d/14bDCfruoq0pRHSDGAFnmdJ5M1K4LSaIeUC92N0wujE4/edit#heading=h.d19yxmw4vw27)
- [x] future tasks built out

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
App crashes on Android

### Summary

App is crashing after launch on Android. 

### Steps to reproduce

1. Launch the app on S22 on browserstack and wait. 
2. App never opens. 

### Platform information 

4.29 RC - S22 - Browserstack

### What is the current *bug* behavior?

App crashes immediately

### What is the expected *correct* behavior?

App should launch successfully

### Relevant logs and/or screenshots

![AppNotLaunching](/uploads/b641861897ca2e9b488adecc8b4561ab/AppNotLaunching.mov)

Story points: 3.0
Create gherkin smoke test cases for mobile automation

<!---
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
--->


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->


## QA

Create test cases in gherkin format.

<!---
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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Crash: Opening wallet screen crashes the app

<!---
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

 Opening wallet screen crashes the app

### Steps to reproduce

Open wallet screen

### Platform information 

All

### What is the current *bug* behavior?

crash

### What is the expected *correct* behavior?

no crash

### Relevant logs and/or screenshots

N/A

### Possible fixes

TBD

Story points: 2.0
Supermind console: See latest prompt should use feed filters

<!---
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

The "See latest prompt" in supermind console is currently not using the [feed filters](https://gitlab.com/minds/mobile-native/-/issues/4481). It should

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Make sure "See latest" takes filters into account

## 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)
--->

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
--->

**Background **
Given I'm in the supermind console screen

- [ ] Given I select a filter
  - When a new post was added in that filter
  - Then I'll see the "See latest prompt" increase according to the number of post in that filter

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Add the profile item in the app menu

<!---
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

Add the profile item in the menu list as per the screens attached.

## What needs to be done

A new item called profile should be added in the menu list which will navigate to profile details as tapping on avatar.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

![image](/uploads/842e4e32bd9ac3a54c7cff895599aad7/image.png)
![image](/uploads/8d41081b621858c6421e302963ff86a6/image.png)

## Personas

Users

## Experiments

N/A

## Acceptance Criteria

GIVEN that I'm in the menu screen
WHEN I tap on the Profile item
THEN I should navigate to profile screen (same as tapping on Avatar)

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Video playback issue in feeds

### Summary

When playing video on mobile within a feed, the audio from other videos can at times play over the video being watched.

### Steps to reproduce

* Find a video in a feed (Vid A), with another video in the post underneath (Vid B).
* Tap to full screen and plat Vid A. Rotate the phone to watch in landscape mode.
* The audio of Vid B to start to play and overlap that of Vid A.

### Platform information 

iOS 16 - v 4.29.0

### What is the current *bug* behavior?

Described above.

### What is the expected *correct* behavior?

Only the audio of the video within view should be audible.

### 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
Find ways to increase the app store rating score

<!---
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

Find ways to increase the app store rating score. Now we're on 3.2.


## What needs to be done

1. investigate how to build a campaign to boost ratings in store.
2. consider adding in-app rating support and think of the frequency of asking that (every 3 posts if the rating was not provided yet)
3. add the rating flag to the user profile and send it to backend
4. consider other types of campaigns (email, maybe) to boost rating

## 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

Developers


## 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
Prompt users to connect a bank account when accepting cash Supermind offer

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

As Minds, I want to send cash Supermind offers to creators, regardless of whether or not they've previously connected a bank account.

As a user, I want to accept a cash Supermind offer and collect the offer.

## What needs to be done

Handle cash Supermind offer charges when the recipient has not already connected a bank account. https://gitlab.com/minds/minds/-/issues/3409

Add a step into the Supermind reply flow when the offer is for cash and the recipient has not previously connected to a bank account.

1. View Supermind console
2. Click accept on a cash offer
3. `New`: Prompt to connect a bank account
4. On connect, open the stripe web page in internal browser and complete enrollment
4. On success, compose the reply
5. On failure to connect prompt again

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

In the Supermind console, show a toast message when a user attempts to accept a cash Supermind offer and they have not yet connected their account:

> `To accept this offer, you must first add your bank information.`

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Given a recipient has not previously connected a bank account, and they've received a cash Supermind offer, when they click to accept the offer, then they are prompted to connect their bank account via toast error message
- [ ] Given the Stripe connect account has been connected, then the recipient can continue to compose a Supermind reply.
- [ ] Given that the user has no connected bank account, then open the stripe web page in internal browser
- [ ] Given that the user complete the connected bank account in stripe web site, then he can dismiss the browser and continue to compose Supermind
- [ ] Given that the user does not complete the connected bank account in stripe web site, when he dismiss the browser then he'll be prompted to add a new bank account.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
UX: in-app user verification - upload verification data

<!---
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

Upload verification data using API call
- the sensors data will be sent as a payload
- device id and activation code will be sent as payload
- the video and image will be sent as multipart form data

## What needs to be done

The device sends the verification status, 4 seconds of sensor data, compressed 4-second video, compressed flash photo to server, using API

related to https://gitlab.com/minds/mobile-native/-/issues/4472

## QA

N/A

## UX/Design

N/A

## Acceptance Criteria

- [ ] Call API to upload the verification status, 4 seconds of sensor data, compressed 4-second video, compressed flash image (last frame)

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
UX: in-app user verification - record video when camera is on

<!---
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

Implement scanning logic with device camera.

## What needs to be done

While in camera mode, recording video and freezes video after a while and takes a flash photo, then temporary store the compressed video and the last frame as image.

## QA

N/A

## UX/Design

N/A

## Acceptance Criteria

- [ ] Record video when camera is on
- [ ] Freeze the video after a while (later to be replaced with OCR detection)
- [ ] Clip video to latest 4sec
- [ ] Store the last frame as an image

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
UX: in-app user verification - OCR handwritten digits using camera

<!---
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

Implement OCR handwritten digits using camera

related to https://gitlab.com/minds/mobile-native/-/issues/4472

## What needs to be done

Whilst user is camera screen perform OCR for the handwritten digits in the outline rectangle

## QA

N/A

## UX/Design

N/A

## Acceptance Criteria

- [ ] OCR written digits

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
UX: in-app user verification - Record device gyroscope and accelerometer data

<!---
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

Record 4sec of device gyroscope and accelerometer data

## What needs to be done

Whilst user is in camera mode in verification, record device gyroscope and accelerometer data

## QA

N/A

## UX/Design

N/A

## Acceptance Criteria

- [ ] Record and store 4sec device gyroscope and accelerometer data

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
UX: in-app user verification - send device identification

<!---
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

Send device identification with API call 

## What needs to be done

1. Application sends device identifying information along with code request to back end
1. Application receive success 200 OK
2. Device receives push notification with registration code

## QA

N/A

## UX/Design

N/A

## 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

- [ ] Call verification API after Continue on Verification Code screee
- [ ] Call verification API on Resend code in Capture Code camera widget
- [ ] Call verification API on Try again in Timeout camera widget

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
UX: in-app user verification - Check if user completed verification

<!---
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

Add API call when to check if user completed in-app verifications and if not, render the verification widget.

## What needs to be done

- Add API call on home screen focus to check in-app verification code.
- The verification should be deferred if the in-app verification process was already done.
- Add condition along the feature flag

## QA

N/A

## UX/Design

N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Render widget if API call return false on in-app validation
- [ ] Hide widget if API call return true on in-app validation

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
UX: in-app user verification - Camera Capture

<!---
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

Minds in-app user-registration on completion of the code request, the camera will popup to capture the code written on paper.
The screen will have a guidance on the preferred area to fit the written code.

related to https://gitlab.com/minds/mobile-native/-/issues/4472

## What needs to be done

- Open the camera with a white outlined rectangle rendered on screen center
- Add support for bottom area for instructions and messages and action button

## QA

As per UIb

## UX/Design

![image](/uploads/15ff47500fa8f2ebb3eae3369e08ff2e/image.png)
![image](/uploads/17a2d8c2620be8c8f9f5d3d663738c87/image.png)
![image](/uploads/d0f30e265cf708f6ac62243a340e00c0/image.png)
![image](/uploads/95efb36c9effb04fa7351e7794930d95/image.png)
![image](/uploads/529bfec8d2dfffd1b61361e72dbfcf5e/image.png)
![image](/uploads/697f8adb0d2a9394c3a6f6c4aec7858f/image.png)
![image](/uploads/a9710c83c990db3e781275cea51221de/image.png)
![image](/uploads/82e3a942fdb0e326efe8638a12b3a8cc/image.png)

## Acceptance Criteria

- [ ] Show the camera with outline rectangle
- [ ] Ask for camera permission if not yet granted
- [ ] Render the Capture code message on the bottom
- [ ] Render the Timeout message on the bottom
- [ ] Render the Success message on the bottom
- [ ] Render the Wrong code message on the bottom

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
UX: in-app user verification - UI Screens

<!---
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

Implement the in-app mobile phone user verification 

## What needs to be done

1. User requests registration in the user interface
2. Simulate API call to check if user was verified and render alert component
3. Application verifies that it is not running in an emulator and that the device has a camera and gyro/accelerator sensors
4. Application opens a modal that explains the process
5. User agrees to terms and requests a registration code
6. Add all behind a feature flag

Note: the widget will open a new module navigator with its own stack.

## QA

As per screenshots

## UX/Design

![image](/uploads/20d8a81825b60f70be8fe84608bf9d68/image.png)
![image](/uploads/3fc12fd9c4cd21e13b56e9a70891d090/image.png)
![image](/uploads/a6d347ca31fb84ebc4023d1812010d16/image.png)
![image](/uploads/48e87500d3694f4e64e2d5a3c038ccad/image.png)
![image](/uploads/447d295efe20a637027393d749813068/image.png)
![image](/uploads/815c48b87d7310c70e67dd43209e8380/image.png)

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Replicate the screen flow as above
- [ ] Make the necessary HWD checks (camera, sensors, real device)
- [ ] Ensure user agrees with T&C

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0