giseldo/neodataset huggingface dataset:
Backend support for accepting InAppPurchases for Minds+/Minds Pro

<!---
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 comply with Google and Apple's terms of service, we are required to integrate in app payments for Minds+ and Minds Pro

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
See https://developer.android.com/google/play/billing/subscriptions#renewals

## 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
--->

Note: The scope of the ticket is only in regards to Android's Minds+ and Minds Pro in-app purchases. Apple's in-app purchases will be implemented as part of a separate ticket TBC.

- [ ] Minds+ and Minds Pro can be be purchased and renewed
- [ ] Backend should be aware that a Minds+ subscription is via inapp purchases. Use the 'plus_method'.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
Attribute payments from Minds+ posts to the post owner

<!---
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
--->
If a customer signs up for Minds+ by unlocking someone else's Minds+ post, and there are no referral cookies present, attribute the post owner as the affiliate. 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
See AC

## 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
--->

- [ ] Attribute the post owner as the affiliate

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Calculate affiliate earnings

<!---
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
--->
Following from https://gitlab.com/minds/engine/-/issues/2543, we should issue the affiliate earnings to their partner earnings account.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
- A daily job that will read from https://gitlab.com/minds/engine/-/issues/2543 and calculate the aggregated deposit amount to make, similar to how Boost Partners work
- Affiliates will receive 45%, net of fees
- The referrer of the affiliate will earn 5% of what the affiliates has earned. This amount will come out of the Minds balance.

Affiliate revenue: Net spend * 0.45

Referrer revenue: (Net spend * 0.45) * 0.05

## 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
--->

- [ ] Add deposits to Minds Commissions
- [ ] Validate the attribution percentage are as above

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Record affiliate transactions in a Vitess

<!---
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 attribute affiliate earnings efficiently, we should store these transactions in Vitess.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- Agree on a data model
- Store payment related information and their success/failure status

### Payments tables

Consider recording ALL payments in a table and having a column of who the affiliate was

### How the affiliate attribution works

- Referral cookie takes precedence
- If there is no referral cookie, fallback to User Entity -> Referrer field. If the Customer is greater than one year old, do not attribute the affiliate. 

## 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
--->

- [ ] Agree on schemas to use
- [ ] We should know what payments should be attributed to which affiliate
- [ ] Respect the referrer cookie or user->referrer attribute values
- [ ] Boost, Minds Pay (Plus/Pro) should write the transactions

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
Created time wrongly updated when edit a post

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

The created time of a post get wrongly updated when the post is edited. Even when a timestamp in the past is provided, it will be overwrite with current timestamp.

### Steps to reproduce

post to `api/v3/newsfeed/activity/{guid}` with a payload object containing 
```
{
...
  time_created: <timestamp>,
}
```

### Platform information 

Mobile

### What is the current *bug* behavior?

The created time of a post get wrongly updated when the post is edited and a timestamp is provided. 
The timestamp received is ignored and the created time will be overwrite with current timestamp.

### What is the expected *correct* behavior?

The created time should not be updated no matter the payload received unless scheduled.

### Relevant logs and/or screenshots

logs, and code as it's very hard to read otherwise.)

### Possible fixes

Mobile issue fixed #4828 by removing the `time_created` from payload.

Story points: 2.0
BlockchainRestrictions integration test failure

<!---
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

BlockchainRestrictions integration test failure

### Steps to reproduce

Open your logs, then on an account you do not mind being banned - go to:

`/api/v3/rewards/check/0x890099E17BfD3f49d8E5fe302B564997440d9079`

See it times out.

### Platform information 

CI, may happen in prod too though the ban will still work so it's effectively the same end result.

### What is the current *bug* behavior?

Request hangs

### What is the expected *correct* behavior?

Request should not hang.

### Relevant logs and/or screenshots

N/A

### Possible fixes


Looks like it may be an issue with a hanging of the SQS call in here:

```
            $this->banManager
                ->setUser($user)
                ->ban('1.4');
```

Should dig deeper though.

Story points: 2.0
Live comments are not working


### Summary

Live comments are not working. See screenshot.

### Steps to reproduce

1. Navigate to a post with comments
2. Notice the error message

### Platform information 

All - Prod

### What is the current *bug* behavior?

Live comments error message appears

### What is the expected *correct* behavior?

- [ ] Remove error message when sockets don't connect. It's ugly and alerts many smaller to medium-sized users to a problem they're not likely to notice or care about.
- [ ] Let DevOps room know if there is actually an issue with sockets.

### Relevant logs and/or screenshots

![20D8E903-84CD-4D02-9DEB-DC707F43D370](/uploads/cc8cb3ca124756e46335669a08a96cf6/20D8E903-84CD-4D02-9DEB-DC707F43D370.jpeg)

Story points: 1.0
Create Remote Search Index Dispatcher for Multi DC Support

<!---
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

<!---
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: 1.0
Record 'create' metric in snowplow when a new post is made

<!---
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
--->

Adding 'create' events to snowplow will allow us to see attached contexts about the post.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
See acceptance criteria.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->
N/A

## 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)
--->
Everyone

## 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
--->

- [ ] Composer should send snowplow contexts, consistent with other action events
- [ ] Strip out entity identifying information (guid, owner, etc) until we change our data retention policy
- [ ] Metrics should be sent to both elastic and snowplow

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Going to a boost page via notifications / email does not load Results & CPM data

### Summary

Boost notification /email links take you to the specific boost page but does not load its results and cpm data. Occuring on mobile and web - mob investigation revealed that it is a backend issue (see comments)

### Steps to reproduce

1. Open minds app
2. navigate to a post and boost it
3. wait for boost to be accepted and notification to be thrown
4. tap on push notification
5. takes you to the post but results and cpm field is 0

Also triggerable via web through email links (report by Peggy with screenshots)

### Platform information 

- IPhone 13 Pro - Staging reported for mob.
- Likely platform agnostic.

### What is the current *bug* behavior?

Results and CPM field is 0

### What is the expected *correct* behavior?

Results and CPM values should match as in boost console for that post

### Relevant logs and/or screenshots

![529DCFDD-49DF-42BD-A006-3031A2B78DE6](/uploads/51cdc6c943c6397a5769e9d7dc89fa1f/529DCFDD-49DF-42BD-A006-3031A2B78DE6.jpeg)

![0C089F71-B591-433B-9709-C5661E1876B5](/uploads/5db8facd6b997c3c027e4d5f3fbbf52a/0C089F71-B591-433B-9709-C5661E1876B5.jpeg)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Check the `api/v3/boosts/:GUID` endpoint in the engine to make sure that the views count is happening correctly

Story points: 3.0
500 errors when trying to interact with entities

<!---
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

A 500 error is thrown when trying to interact with posts on discovery. Other pages may be impacted too.

See https://minds-inc.sentry.io/issues/3962878623/?environment=staging&project=1538020&query=is%3Aunresolved&referrer=issue-stream&statsPeriod=14d

### Steps to reproduce

Interact from https://www.minds.com/discovery/top

### Platform information 

Web

### What is the current *bug* behavior?

500 error is thrown.

### What is the expected *correct* behavior?

No error should be thrown. Types should be validated server side and not throw errors to the clients. 

### Relevant logs and/or screenshots

```json
{"client_meta":{"platform":"web","campaign":"urn:activity:1470442537104707599","medium":"feed","source":null,"salt":"","page_token":"","delta":0,"timestamp":1677576602874}}
```

### Possible fixes

Types should be validated server side and not throw errors to the clients.

Story points: 1.0
Cannot reply to Superminds

<!---
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

Cannot reply to Superminds.

### Steps to reproduce

1. Try to reply to a Supermind on a branch with master pulled in - I believe this effects all Superminds but if you need help debugging DM me.

### Platform information 

Web

### What is the current *bug* behavior?

Cannot reply to Superminds. 500 error relating to analytics (see Sentry below)

### What is the expected *correct* behavior?

Should be able to reply to Superminds

### Relevant logs and/or screenshots

https://minds-inc.sentry.io/issues/3961235410/?query=is%3Aunresolved+%2FCore%2FAnalytics%2FMetrics%2FEven&referrer=issue-stream&statsPeriod=14d

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
Boosts on channel pages should respect the users serving configuration

<!---
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
--->
Channel owners should be able to control what kinds of boosts they show on their channel pages

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
The boost endpoint when called from a channel page should join onto the user configurations table and respect the flag that was set in https://gitlab.com/minds/front/-/issues/5917

## 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? (maybe)

## 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.
--->
Yes, boost partners

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Boosts are only delivered in accordance with the "Serve boosts on my channel" option

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Make the Boost estimates dynamic

<!---
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
--->
The current boost system is making use of static values (from a mysql table) in order to provide the estimated reach calculations. We should build a process that will keep these variables up to date to provide near real time estimates. 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Build a cronjob that will calculate CPM's and update the boost_estimates table

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Estimates are more accruate

## 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

## 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.
--->
N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] A cli script that will estimate the boost values
- [ ] Make use of the existing table and update the variables

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0