giseldo/neodataset huggingface dataset:
Supermind and Payment History should link to the receipt urls

<!---
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
--->

Supermind and Payment History items should have a link to the stripe receipt. 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Stripe Payments include a field called `receipt_url`. When present (failed payments to do not have this field), display a link that a user can click on (open in new tab). 

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Should be functional

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

Supermind will need to be able to show this link. @mwrobs to provide simple mockup.

![Settings](/uploads/d7fd2a6f646b3336ad542e7e18bed4cd/Settings.png)
![Payment_History](/uploads/da43850c9d42a28a4bfb947f2f74abb3/Payment_History.png)
![Console-_Outbound__Accepted-Receipt_](/uploads/3b65010c2d44234fa58913f3f9194c53/Console-_Outbound__Accepted-Receipt_.png)

## Personas

<!---
Who does this user impact and why (optional)
--->

Spenders


## 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
--->

- [ ] A receipt link is clickable

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Implement Stripe Checkout when adding cards

<!---
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 reduce friction with our current card component (and so that we can drop support for checkout.minds.com), we want to implement Stripe Checkout. 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

See https://stripe.com/docs/api/checkout/sessions/create?lang=php for how to generate the session. We are only interested in the 'setup' phase at this moment. 

The complicated part is going to be the redirect logic. Stripe Connect can **not** be placed into an iFrame. 

### Proposed Flow (via /settings/payments/payment-methods)

1) User clicks 'Add new card'
2) Redirect to /api/v3/stripe/checkout/setup
3) `success_url` and `cancel_url` should be `/settings/payments/payment-methods`

### Proposed Flow (via Payment Methods (modals)

1) User select 'Add new card' from the dropdown selector
2) New card modal still loads and open `/api/v3/stripe/checkout/setup` in a new tab
3) card modal continues to poll for callback logic (use either cookies or cache)
4) `success_url` and `cancel_url` should be `/api/v3/stripe/checkout/inline-complete`
5) card modal will update after the callback

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

The above flow works. Sandboxes should now be able to be easily supported. 

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

See flow above

## Personas

<!---
Who does this user impact and why (optional)
--->

Spenders


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

Yes


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [x] The flows mentioned above are implemented
- [x] E2E tests may be difficult here so can be optional
- [x] Experiment flag

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
Display a list of all card payments under Settings > Payments > Card Payments

<!---
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
--->

Display a list of payments (along with the payment status) to the user

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

The backend API will need to be created, it should support pagination. 

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

A list of payments should be visible

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

Simple table using existing UI components. 

https://gitlab.com/minds/front/uploads/da43850c9d42a28a4bfb947f2f74abb3/Payment_History.png

## Personas

<!---
Who does this user impact and why (optional)
--->

Spenders

## 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
--->

- [ ] Backend api with pagination support
- [ ] Frontend scrollable list with payment states
- [ ] Display in reverse chronological order

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Quote post dropdown not visible in fixed height boost rotator

<!---
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

Quote post dropdown is hidden out of frame (see image below)

### Steps to reproduce

Click remind button on fixed height boost in rotator.

### Platform information 

Web

### What is the current *bug* behavior?

Cannot remind or quote properly because menu is hidden

### What is the expected *correct* behavior?

Menu should appear above 

### Relevant logs and/or screenshots

![image](/uploads/3ed13961c1943f3202531aef80b5e616/image.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0
Visually differentiate Supermind offers

## Goal

Improve the value prop of Supermind offers by making Supermind offers stand out in feeds.

## What needs to be done

Update the visual design of Supermind offer posts.

Indicate...

- The post is a Supermind offer
- Who is the target of the offer

## QA



## UX/Design

[Web Figma File](https://www.figma.com/file/thrGepQAxmcMGB7MoEEckM/Supermind-%5B*%5D?node-id=2584%3A29348)

Mobile version has issues with margin spacing on current mobile production. Currently playing around with ideas for mobile and spoke with Jack and Ryan on the topic already, but my suggestion would be to test it out on web first and then move to mobile if received well. I will be following up with the mobile devs to get their opinion on the matter, but it brings up the topic of giving more attention to aligning mobile and web design practices and screens.

![Supermind_Offer__Text_Post____Pending_Reply](/uploads/a7fb08c651947f92c45c887f9e175e05/Supermind_Offer__Text_Post____Pending_Reply.png)
![Supermind_Offer__Text_Post____Reply](/uploads/33123da50d24466772fdf0e95628d923/Supermind_Offer__Text_Post____Reply.png)
![Supermind_Offer__Quote_Post____Pending_Reply](/uploads/7e0e1b17940679d3b3e9bc13619f1ddb/Supermind_Offer__Quote_Post____Pending_Reply.png)
![Supermind_Offer__Quote_Post____Reply](/uploads/69184d9aad6520734cef1448146ab750/Supermind_Offer__Quote_Post____Reply.png)

## Personas

Core Minds users

## Experiments

n/a

## Acceptance Criteria

- [ ] When a Supermind offer is posted, it is visually differentiated from regular posts in whichever feeds it appears

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Deleted Posts Remains In Feed Until Page Is Refreshed

<!---
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
Deleted posts remains displayed within channel and group feed until the page is refreshed (feeds are not immediately updated after posts are deleted).

### Steps to reproduce
Create a post in either a channel or group and then delete said post.

### Platform information 
Platform neutral (browser interface).

Story points: 3.0
Throw toast message upon posting a Supermind reply

## Goal

More clearly communicate to the user that their Supermind reply was posted.

## What needs to be done

Throw a toast message to confirm that a Supermind reply was successfully posted.

> Your Supermind reply was posted, and you’ve collected the offer.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

Use the positive-looking toast message.

![image](/uploads/41c73a16eb45a88e96bab7decaf7f5ee/image.png)

## Personas

- Creators

## Experiments

n/a

## Acceptance Criteria

- [ ] When successfully posting a Supermind reply, throw a toast message that confirms.
- [ ] Use message above in `What needs to be done`

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Validate receiver minimum thresholds on Supermind creation

<!---
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

Enforce validation of Supermind receiver minimum amounts.

## What needs to be done

Grab the minimum amounts from the sender objects and ensure an amount less than that cannot be submitted.

## QA

Test minimum amounts - change them via settings and try making another Supermind.

## UX/Design

N/A

## Personas

Users interacting with the Supermind feature. 

## Experiments

N/A

## Acceptance Criteria

- Minimum amounts for senders should be respected - values below the sender minimum should not be submittable.
  - Engine side validation
  - Front-end validation

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [x] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 3.0
Add more information to Supermind activity posts

<!---
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
--->

It isn't obvious enough what a Supermind is from the tag and highlight we currently have. 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Add a description somewhere that says: "A Supermind is a paid reply. It is not an endorsement."


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

We could simply display a tooltip on hover/tap as shown here. (https://www.figma.com/file/thrGepQAxmcMGB7MoEEckM/Supermind?node-id=1821%3A21242
![w_tooltip](/uploads/e48d95c5e587925f49061568c0c62471/w_tooltip.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
- [ ] Experiments8

Story points: 3.0
Playwright Automation: Nightly Staging Jobs

<!---
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

Update cypress jobs to run playwright tests instead. Might need tagging support for non-prod tests. 


## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Playwright Automation: Maintain a Green light

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done

Maintain a green light on CI for playwright tests.

<!---
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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Existing Group Administrators Unable To Delete Group Based Posts

<!---
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

Existing (that were assigned prior to the recent feed changes) and newly assigned group administrators, as well as newly assigned moderators and possibly existing group moderators are unable to delete posts that other users have published to the corresponding groups due to omission of the "delete" option within the post drop-down menu

I have tested existing and newly assigned administrator access, and existing moderators access but I am unable to verify the existing moderators access. 

### Steps to reproduce

As a group administrator or moderator, try to delete another users posts from your group.

### Platform information 

Platform neutral (browser interface).

### What is the current *bug* behavior?

No option is available to delete another users posts in a group that you are an administrator or moderator of.

### What is the expected *correct* behavior?

Should be able to delete another users posts in a group that you are an administrator or moderator of.

### 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
Signature verification failure on wallet connection

<!---
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

Signatures are being rejected by the engine on production when connecting a wallet. Testing the params passed to engine locally against MW3, this SHOULD work fine.

```sh
node index.js verifyMessage --message="{\"user_guid\":\"1033785333306630163\",\"unix_ts\":1663270583}" --signature="~my signed message~"
```

Two possibilities 

1. Something is messed up with our signer in prod - maybe it's not up to date with what my local stack has or has uncommited changes
2. The message is being escaped server side and passed in wrong - I did this accidentally when copying and it will result in incorrect output

### Steps to reproduce

Try to connect a wallet for rewards - DO NOT DO THIS ON YOUR MAIN ACCOUNT / AN ACCOUNT YOU ARE COLLECTING REWARDS ON

### Platform information 

Web

### What is the current *bug* behavior?

Cannot connect wallet

### What is the expected *correct* behavior?

Should be able to connect wallet

### Relevant logs and/or screenshots

```
{"errors":[],"status":"error","message":"Signature could not be verified","errorId":"Minds::Exceptions::UserErrorException"}
```

Thrown from here https://gitlab.com/minds/engine/-/blob/a0f6924941c3f8454694c833efddbf16d94f5d2c/Core/Blockchain/Wallets/OnChain/UniqueOnChain/Manager.php

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 3.0
(bug): Dark mode in blog meta information messed up

<!---
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.
--->

![image](/uploads/fb8c353e3e785736b85a9d95be851bdf/image.png)

Firefox

Story points: 1.0
Default to Dialpad when entering phone numbers

Default the mobile keypad to number layout when prompted for 2-factor authentication.

We should use the newly available "inputmode" attribute that is gaining acceptance across all modern browsers. It should downgrade nicely to a conventional input 

https://css-tricks.com/finger-friendly-numerical-inputs-with-inputmode/

https://caniuse.com/#search=inputmode

- [ ] Refactor our phone number inputs into one component 
- [x] Phone number input for onboarding, dial pad for small resolutions
- [ ] Phone number input for wallet, dial pad for small resolutions
- [x] Phone number input for 2FA, dial pad for small resolutions
- [ ] Unit tests
- [ ] E2E tests

Story points: 6.0
Long comments are getting cut off (even ones from long ago) and users are not being informed when their comments surpass the character limit.

### Summary

Long comments are getting cut off (even ones from long ago) and users are not being informed when their comments surpass the character limit. Also, they are allowed to post a comment even if it exceeds the character limit. This causes the comment to get cut off with "..." at the point where the character limit was reached.

I suggest making the character limit much longer (like 5000), adding a "See More" button after a certain number of characters (like 500) and informing users that their comments have surpassed the character limit by turning the text red and adding a negative number in red (for the number of characters which surpass the character limit) to the bottom right corner of the comment input field plus showing an error message if users try to post a comment which surpasses the character limit.

### Steps to reproduce

1. Post a really long comment, one which exceeds the current character count for comments (whatever it is)

### Platform information 

Chrome/Win10

### What is the current *bug* behavior?

Long comments are getting cut off (even ones from long ago) and users are not being informed when their comments surpass the character limit. Also, they are allowed to post a comment even if it exceeds the character limit. This causes the comment to get cut off with "..." at the point where the character limit was reached.

### What is the expected *correct* behavior?

I suggest making the character limit much longer (like 5000), adding a "See More" button after a certain number of characters (like 500) and informing users that their comments have surpassed the character limit by turning the text red and adding a negative number in red (for the number of characters which surpass the character limit) to the bottom right corner of the comment input field plus showing an error message if users try to post a comment which surpasses the character limit.

### Relevant logs and/or screenshots

![11](/uploads/30fafa8ad3e10778c9cef08db6122e55/11.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0