giseldo/neodataset huggingface dataset:
Onboarding Wizard - Channel Tagging does not tag channels

### Summary

Onboarding Wizard when you choose your preferred hashtags, those hashtags are not used to tag your channel. This will also help in getting channels to register hashtags for the initial channel search to be more effective.

### Steps to reproduce

1. Register a new channel
2. Select hashtags in the onboarding wizard
3. Only updates your preferred hashtags

### Platform information 

Browser

### What is the current *bug* behavior?

Only updates your preferred search hashtags

### What is the expected *correct* behavior?

Should update you channel profile hashtags as well. 

### Relevant logs and/or screenshots

![update_channel_tags](/uploads/69e2f2be09964c4c334f254dd44bc2e9/update_channel_tags.mp4)

- [ ] new onboarding should tag the user's channel with their selected channels
- [ ] new onboarding should populate their feed selectors (already working, but just to verify that it's doing what it's supposed to)

Story points: 2.0
Unable to delete or edit old blogs

1. Go to old blog circa 2014
2. Attempt to edit it 
3. Give up and try to delete it both from the blog itself and the blog list on channels https://www.minds.com/ottman/blogs
4. End up here https://www.minds.com/blog/owner
5. Run away
![blogerror](/uploads/85305ad57e254ef103ad6b4efaf8fac1/blogerror.PNG)

Story points: 4.0
Banned and Blocked Channels appearing in suggested search results

### Summary

Banned channels are suggested under search results. Likely related to https://gitlab.com/minds/front/issues/2136

### Steps to reproduce

eg. search for `@ottman`

### Platform information 

browser

### What is the current *bug* behavior?

Banned channels with offensive names are listed

### What is the expected *correct* behavior?

banned channels should not be listed.

### Relevant logs and/or screenshots

![banned_channels_in_search_suggestions](/uploads/1426bf24dffead75a4c87ff7d4e624aa/banned_channels_in_search_suggestions.PNG)

### Possible fixes

A scheduled script that cleans banned channels from search caching.

Story points: 2.0
Remove constraint of deleting a group that still has members

It should be possible to delete a group without having to first remove all of its members.

Current behavior:

- Given the user has permissions to delete a channel (e.g. is an Admin),
- and the group has members,
- and the user is viewing the group,
- and the user clicks the gear icon at the top of the group,
- when the user clicks "Delete group"
- then a toaster message appears that says "You cannot delete a group that has members."
- and the group is not deleted.

![image](/uploads/954648083961316c8baa8260679accc2/image.png)

Desired behavior:

- ...when the user clicks "Delete group",
- then a confirmation modal appears and the user can confirm deletion of the group without having to remove all members first.

![image](/uploads/0acee79a49888b451d94d73b04e66a0d/image.png)

Story points: 1.0
Investigate Oddities and improve existing Boost Feed API functionality

I refactored the feed functionality out of the API request code and into `Core\Boost\Feed` abstract class and implemented `Core\Boost\Feeds\Boost` concrete class.
In the review site the feed request response exactly matches the pre-refactored response (tested web only, need to capture a mobile request).

Example web request:
`/api/v2/boost/feed?rating=2&rotator=1&sync=1&limit=150&as_activities=0&from_timestamp`

The functionality appears limited, oddities found so far...
**(Checkbox Indicates Resolved)**

- [x]  `limit` in request is not honoured
- [ ]  `rotator=1` is requested but not used anywhere
- [x]  `sync=1` is requested but not used anywhere
 
- [x]  Iterator makes a request for *X* boosts, if *Y* of those boosts are invalid or can not be resolved the iterator will return *X* - *Y* boosts, requiring additional requests to cycle the iterator (which could return few or no results again)
- [ ]  It is not implicit that boosts are always returned in ascending timestamp order
- [x]  It is not clear what a boost 'rating' is
- [x]  We ignore the offset requested from the iterator and instead override with the timestamp of the last boost in list with no explanation why we don't trust the iterator

Story points: 4.0
Users should not be allowed to boost scheduled content

People are sometimes boosting a post that is scheduled and has not been posted yet. When it is boosted, you can see the indication that it is scheduled to be posted at a later date. We should just not allow scheduled posts to be boosted.

![Screen_Shot_2019-10-22_at_11.42.13_AM](/uploads/9cffd8ccbb9408642fc86001471ca62d/Screen_Shot_2019-10-22_at_11.42.13_AM.png)

Story points: 1.0
Ensure NSFW filters carry through to Pro sites

- [ ] If channel is NSFW, only pay out in BTC or ETH or Minds Tokens, depending on preference, to comply with terms of payment processors

- [ ] If logged-in to minds, NSFW filters should still apply

- [ ] If logged out, the modal should make clear that it is an nsfw site in the login and that they are 18

Added two hours to validate the functionality on pro sites. If we run into issues with any of the three checks, then let's create separate cards to dig down into each of them.

Story points: 2.0
Clean up the unleash client and implement the strategies

- unleash-client-php!1: This merge request includes all the work done by @brianhatchet, complete with a psr compliant caching interface.
- unleash-client-php!2: Clean up and strategies implementation

---

We want to make it Unleash compliant, but for our purposes we can focus on the gitlab version

https://docs.gitlab.com/ee/user/project/operations/feature_flags.html

Specifically, we need to implement the strategies section

https://docs.gitlab.com/ee/user/project/operations/feature_flags.html#feature-flag-strategies



Story points: 12.0
TypeError: Return value of Minds\Core\Permissions\Delegates\ChannelRoleCalculator::getChannelForEntity() mus...

Sentry Issue: [ENGINE-EN](https://sentry.io/organizations/minds-inc/issues/1254945802/?referrer=gitlab_integration)

```
TypeError: Return value of Minds\Core\Permissions\Delegates\ChannelRoleCalculator::getChannelForEntity() must be an instance of Minds\Entities\User, null returned
  File "/Core/Permissions/Delegates/ChannelRoleCalculator.php", line 72, in Minds\Core\Permissions\Delegates\ChannelRoleCalculator::getChannelForEntity
    return $this->entitiesBuilder->single($entity->getOwnerGuid());
  File "/Core/Permissions/Delegates/ChannelRoleCalculator.php", line 43, in Minds\Core\Permissions\Delegates\ChannelRoleCalculator::calculate
    $channel = $this->getChannelForEntity($entity);
  File "/Core/Permissions/Permissions.php", line 101, in Minds\Core\Permissions\Permissions::getRoleForEntity
    $role = $this->channelRoleCalculator->calculate($entity);
  File "/Core/Permissions/Permissions.php", line 79, in Minds\Core\Permissions\Permissions::calculate
    $this->entities[$entity->getGuid()] = $this->getRoleForEntity($entity);
  File "/Core/Permissions/Manager.php", line 64, in Minds\Core\Permissions\Manager::getList
    $permissions->calculate($entities);
...
(7 additional frame(s) were not displayed)
```

Story points: 1.0
Media from groups should not go to media sidebar

<!---
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

It appears as if when the user makes a blog in a private group, an entry is also created in the blogs of their channel.

### Steps to reproduce

1. Post a blog in a private group
2. Go to your channel, and look at your blogs side widget, the post appears there.

### Platform information 

Cross platform web. Repicated Chromium/Ubuntu 18.04.

### What is the current *bug* behavior?

Blog appears in the widget when it should be private, same may be happening for other entities.

### What is the expected *correct* behavior?

Blog should NOT be accessible from there, or by link if not in the group.

### 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)

/label ~"T \- Bug" ~"S \- Triage:new" 


Story points: 2.0
(bug): onboarding is not displaying steps

<!---
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.
--->


### Steps to reproduce

Create a new channel and try to do a full channel setup. 

### Platform information 

Chrome, iOS

### What is the current *bug* behavior?

When you create a new channel, you are not given the steps to select hashtags or subscribe to channels. It skips immediately to the profile setup screen. 

If you try to set an avatar, display name and description, only the avatar appears correctly when you land on your channel. You have to refresh your browser in order to see your display name and your description. Very unintuitive and should not require a refresh.

The channel shows onboarding is only 83% complete even though I only did the channel set up screen and joined the rewards program.


### What is the expected *correct* behavior?

I should see all onboarding screens.

I should see all my updates reflected on my channel without a refresh.

Percentage of onboarding completion seems broken. 1) Hashtags 2) Channels 3) Design 4) Rewards = 100% setup. If you have not done a step, it should decrease your % complete and if you click to complete setup it needs to take you to only the steps you have not done.

### Relevant logs and/or screenshots



### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0
Gifs uploaded as avatar are not cropped and cause issues throughout the site.

Example of issue ![Screen_Shot_2019-09-30_at_9.53.01_PM](/uploads/a1d79255bce745cd880a36bae1613706/Screen_Shot_2019-09-30_at_9.53.01_PM.png).

Small - https://cdn.minds.com/icon/870387733137203205/small/1569815035
Master - https://cdn.minds.com/icon/870387733137203205/master/1569815035

Story points: 1.0
Add 'seen_entities' to 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
--->

We should add 'seen_entities' to vitess in order to better query our clustered recommendations. Redis can only store the last 1 hour due to bandwidth constraints. 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

One record per pseudo_id and entity_guid with a timestamp of last viewed. 

## 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.
--->

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
--->

- [x] A new table in vitess
- [x] Add 'seen_entities' to vitess, as we do with Redis. 
- [ ] ~Consider using an EventStream for seen_entities and batching results into Vitess (scaling)~
- [x] 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: 5.0
Support Querying by Nostr Event 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

<!---
Clearly outline the goal of the issue and why we are doing it
--->

We currently only support retrieving Nostr events using a user's public key. In order to support real-world Nostr clients, we should support querying based on all of the filters described here:

https://github.com/nostr-protocol/nips/blob/master/01.md

***Note***: Reminder to support `e` and `p` tags for replies and mentions respectively

https://github.com/nostr-protocol/nips/blob/master/01.md#other-notes

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Refactor the Nostr endpoint to support querying for entities based upon the above filters.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

We can test with a client like [Damus](https://damus.io/) which has global feeds which depend upon this functionality.

## 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
--->

- [ ] Endpoint is updated to allow for querying entities using the NIP-01 filters

## Definition of Ready Checklist

- [X] Definition Of Done (DoD)
- [X] Acceptance criteria
- [ ] Weighted
- [X] QA
- [X] UX/Design
- [X] Personas
- [X] Experiments

Story points: 5.0
Regression: Cannot delete comments -  "G.delete is not a function"

### Summary

Cannot delete a comment. 

### Steps to reproduce
1. Open minds web.
2. Comment on any post.
3. Delete your comment.
4. Nothing happens.

### Platform information 

All staging, canary & Prod
All browsers

### What is the current *bug* behavior?

Nothing happens - console error "G.delete is not a function"

### What is the expected *correct* behavior?

Comment should be deleted

### Relevant logs and/or screenshots

![image](/uploads/2b8e4f17404300f54ff5c103b019343c/image.png)

Story points: 2.0
Enable engine to pull in Nostr events and transform into Minds entities

<!---
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 are now able to send events out to nostr. Now we want to be able to pull in events too.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

The scope of this task is simply to be able to transform a nostr event into a Minds entity. These entities **should** be stored like other Minds entities and **should** have owners like other entities. We also **must** ensure that there is only one Minds entity per nostr event.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

API.

## 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
--->

- [ ] Given a Nostr hash, translate to a Minds entity and save
- [ ] Ensure there is only **one** entity per nostr hash
- [ ] If a User is an imported Nostr event, do not do any signing logic
- [ ] Only allow from 'trusted' users which can call the endpoint

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
SKALE - Private key generation and token transfers

<!---
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

Create a means of transferring tokens between custodial wallets associated with users. If there are any obstacles, identify them and propose solutions.

## What needs to be done

- [x] See if we can use Nostr private keys to act as a user's custodial wallet for the site.
- [ ] If we cannot, find an alternative system of private key generation for users.
- [x] Check wallets can be imported in Metamask and tokens can be sent between wallets.
- [x] Build out a CLI endpoint that can be used to wire tokens between the wallets of two users.
- [x] CLI endpoint should print TX hash (as when implemented fully, we will want to pass this to the front-end.
 
## QA

- [ ]  Test CLI endpoint works for users pre-seeded with testnet tokens.

## UX/Design

N/A - though if any future UX considerations come up, we should consider it.

## Personas

For now, developers, in future, users of the offchain system as outlined in https://gitlab.com/groups/minds/-/epics/256

## Experiments

N/A - this should NOT be exposed yet or accessible from existing API endpoints thus should not YET need a feature flag.

## Acceptance Criteria

- [x] SKALE compatible private keys associated with user accounts.
- [x] Figure out sFuel distribution.
- [x] CLI endpoint to transfer tokens between two users by user guid - should print TX hash.
- [x] CLI endpoint for checking the balance of a wallet by address or user guid.
- [x] CLI endpoint for sending sFuel to a wallet by address or user guid (should be the same as sending Ether).
- [x] Unit 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: 13.0
Fix static analysis

<!---
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
--->

phpstan is failing

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Fix errors

## 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.
--->

N/A

## Personas

<!---
Who does this user impact and why (optional)
--->

Devs

## 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
--->

- [ ] Green light static analysis

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Fix PHP

Story points: 1.0
Forgot password broken for users without locale

<!---
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

Forgot password broken for users without locales

### Steps to reproduce

Presumably set your locale to null - see Sentry

### Platform information 

Web and mob

### What is the current *bug* behavior?

Cannot send password reset email

### What is the expected *correct* behavior?

Default locale to an EN one?

### Relevant logs and/or screenshots

https://sentry.io/organizations/minds-inc/issues/1723668477/?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
TwitterSync for videos

<!---
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

Sync videos on Twitter when synced to Minds

## What needs to be done

- Explore whether possible/feasible.
- Update the twitter sync job to also parse videos.

## QA

Test Twitter Sync

## UX/Design

N/A

## Personas

Twitter Sync users.

## Experiments

N/A

## Acceptance Criteria

- [ ] Rich embed twitter videos
- [ ] Bonus if you can figure out how to transcode the videos
- [ ] For image posts, capture the dimensions and save to the entities

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 5.0