giseldo/neodataset huggingface dataset:
Support Querying Delegated Nostr Events (NIP-26)

<!---
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 for Minds to sign Nostr events on behalf of a Nostr user, we need to implement support for querying [NIP-26](https://github.com/Minds/nostr-nips/blob/minds-nip-26/26.md) signed events.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Upon requesting events for a designated public key, we should also query for delegated events signed on behalf of the requested author.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

We can query for Nostr events based on the delegate token w/ a client.

## 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)
--->

Digital nomad

## 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
--->

- [ ] Delegated events are included in `REQ` queries for an author's public key
- [ ] Spec tests and integration tests

## 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
Modify the application fee referrer splits

<!---
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
--->

Split the application fee 50/50 with the referrer. Currently the referrer get 100%.


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- Remove logic that attributes referral based on ownership of page you came through
- Make the commission 5% to Minds and 5% to referrer if there is a referrals code (Otherwise 10% to Minds)
- In order to be eligible, referrer must be onboarded to Stripe


## 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
--->

- [x] Remove logic that attributes referral based on ownership of page you came through
- [ ] Make the commission 5% to Minds and 5% to referrer if there is a referrals code (Otherwise 10% to Minds)

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Ban channels when connecting or sending from an OFAC sanctioned ETH address

<!---
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 be complaint with OFAC, we should ban channels when connecting or sending from an OFAC sanctioned ETH address

## 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
--->

May be tricky to QA this, but should be easy enough to have integration tests for. 

## 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)
--->

Crypto

## 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
--->

- [ ] When connecting a wallet to Minds, check the OFAC sanctions list
- [ ] When someone sends an onchain wire, check the OFAC sanctions list
- [ ] Ban the user if match on the list
- [ ] Find best method of obtaining OFAC sanctions list
- [ ] Considering the size of the list, copy into Cassandra
- [ ] Integration teest 

## 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: 5.0
Metrics endpoint response error

<!---
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 metrics endpoint is returning a string instead of a json for its response and the middlewares aren't happy about it

https://sentry.io/organizations/minds-inc/issues/3340278369/?environment=production&query=is%3Aunresolved

### Steps to reproduce

happens all the time

### Platform information 

engine

### What is the current *bug* behavior?

read summary

### What is the expected *correct* behavior?

should return a json

### Relevant logs and/or screenshots

https://sentry.io/organizations/minds-inc/issues/3340278369/?environment=production&query=is%3Aunresolved

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
Pseudo ID cookie is expiring after every session. Persist.

<!---
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
--->

Pseudo ID cookie is expiring after every session. Persist.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Have a very high expiry time.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Check expiry date of cookie

## 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)
--->

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
--->

- [x] Ensure minds_pseudoid cookie does not expire every session

## 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: 1.0
Allow comment parents to delete child comments

<!---
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 "delete" option was visible for comment parents to delete children comments made by other users. But when they click delete, the comment is not deleted. 

![image](/uploads/0e296df0a1a172b9fffc3eb712735c04/image.png)

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
If we want comment parents to be able to delete child comments, the backend should allow this to happen.

We also should add the delete option back to the dropdown menu in the front end (aka put the green line back into the comment component).
![image](/uploads/bc7823b9d4f70fd32fd7a3bf5bfc4398/image.png)

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
The comment should actually be deleted.

## 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)
--->
comment owners who want to curate their responses

## 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
--->

- [ ] comment parents can delete their child comments
- [ ] comment parents can see the delete option on the child comment drop downs

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Introduce Backend API testing framework

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->

We need backend API tests.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Implement https://codeception.com/docs/10-APITesting and configure backend tests to work against local and sandbox environments to begin with.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Pipeline passes.


## 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)
--->

:nerd: 

## 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
--->

- [ ] Implement codeception (https://codeception.com/docs/10-APITesting)
- [ ] Create an example API test (ie. authentication, registration)
- [ ] Setup the CI Pipeline to run Post review deploy

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 8.0
See Latest Posts button not scrolling back to top of newsfeed

<!---
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

(Summarize the bug encountered concisely)

See Latest post button is not scrolling to the top of the newsfeed when clicked.

![Screen_Recording_2022-07-28_at_12.23.22_PM](/uploads/41e38118127d55f01f2564d7a59fc26d/Screen_Recording_2022-07-28_at_12.23.22_PM.mov)

### Steps to reproduce

(How one can reproduce the issue - this is very important)

1. Scroll deep in newsfeed with active subscriptions
2. Wait until there are latest posts to load
3. Click see latest posts and see where the scroll takes you.

### Platform information 

(Browser, device, system stats, screen size)

iOS, macbook, brave browser

### What is the current *bug* behavior?

(What actually happens)

See summary

### What is the expected *correct* behavior?

(What you should see instead)

See latest posts button should always take you to very top of newsfeed with new posts loaded

### 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: 2.0
Do not issue reward if a payout_tx already exists

<!---
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
--->

Kubernetes jobs unreliably restart and have caused rewards to be paid out twice (or multiple times).

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

If a 'payout_tx' column exists on the token_rewards table, **DO NOT** payout again. 

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Rerun token rewards job and note no additional payouts

## 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)
--->

Crypto

## 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
--->

- [ ] If a 'payout_tx' column exists on the token_rewards table, **DO NOT** payout again. 
- [ ] Log an error
- [ ] Spec test

## 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: 2.0
Support collecting avatars from Nostr KIND 0 events

<!---
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
--->

Pull in avatars with Nostr Metadata update events.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Nostr provides a url for avatars. We need to scrape this and pass through to our avatar service. 

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Avatar changes should pull into Minds.


## 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)
--->

Nomads

## 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
--->

- [ ] Nostr KIND 0 avatar/profile pic changes are reflected on Minds
- [ ] Ensure we only scrape external urls. Security.
- [ ] Spec tests

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 3.0
Implement NIP-09 for Event Deletion

<!---
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
--->

[NIP-09](https://github.com/nostr-protocol/nips/blob/master/09.md) describes a fifth event kind for deleting posts. In order to allow users to delete their posts from our relay, we should implement this NIP.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

1. Implement support in the relay project for sending kind 5 events to the engine.
2. Expose an endpoint on the engine for deleting Nostr events when supplied a list of events in a kind 5 payload.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

We can test by creating and deleting posts with a test account.

## 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
--->

- [ ] Events can be deleted by sending a kind 5 event payload to the Minds Nostr relay.

## 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: 5.0
Mobile triggering 500s trigger when updating tags on an image

<!---
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

Mobile triggering 500s trigger when updating tags on an image

### Steps to reproduce

1. Post image
2. Edit it to add tags
3. On save, see 500

### Platform information 

Looks like it is engine side affecting mobile.

Replicated S10 / Android

### What is the current *bug* behavior?

500 error, cannot save

### What is the expected *correct* behavior?

Should allow save

### Relevant logs and/or screenshots

Given timing - may relate into either or both of:
 
- https://sentry.io/organizations/minds-inc/issues/3354328885/?query=is%3Aunresolved
- https://sentry.io/organizations/minds-inc/issues/3411694851/?query=is%3Aunresolved

[bashy-tag-bug](/uploads/6e35d05a7aa84801ceedbe1f79215c65/bashy-tag-bug)

### Possible fixes

See Sentry

Story points: 2.0
Implement 10% Minds cut + processing fees

<!---
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
--->

Increase Minds Fee

## 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.
--->


## 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
--->

- [ ] Increase stripe application fee from 5% to 10%
- [ ] Update reference to fee in relevant places

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0