BitClout Promoted Posts -- Brought to you By CloutCast (CloutCast Frontent Integration)

[Zyther]

One-Line Description

A [near] direct implementation of BitClout's "Sponsored Posts" white paper bullet point.

Explanation and Motivation

CloutCast originally started seeking to execute upon the notion of "Sponsored Posts" on BitClout. CloutCast offers BitClout users means to promote their posts as Casts, placing them in a marketplace for other BitClout users to earn money by engaging with said casts, thus creating a self-sustaining eco-system of higher quality promotional content.

Motivation:
To further execute on the original vision of BitClout, and to highlight "Targeted Sponsored Posts"

Our long term plan was to have CloutCast integrated wherever a BitClout feed were to exist, and what better place than the BitClout frontend -- providing any node operator a way for their users to promote their content, and others to get paid to do so -- all at no cost, or effort to the node operator.

Specification

The initial specification of this change is 100% frontend at this time:

• a new menu item on the sidebar "Casts" (with a new sidebar list component object for our own notifications)
• A page with two route definitions. (/casts, and /casts/:castID) -- one for the master list of casts, one for the cast detail/execution of cast
• A modal for users to create posts (wired into feed-post's actions)
• The addition of a couple globalVar level functions to initialize the notification count of your "Inbox" Casts/
• A new angular service to handle communicating with CloutCasts APIs
• An additional function added to page initialization to get the count of notifications for loggedIn publicKey

Data Storage Change

There are a couple of JWTs that will be loaded in browser memory, assuming the viewer is a loggedInUser with a valid PublicKeyBase58Check

Backwards Compatibility

100% compatible with latest, and stable.

Security Considerations

We request a JWT from the identityService to verify with our backend that the publicKey that is transacting with us is who they say they are. We require nothing more than this trust (user is public key) to transact. No other data, or transacting power whatsoever is needed by CloutCast's APIs.

Alternate designs considered

• We thought of proxying requests through the backend
• We also may consider a feature flag to disable casts

Acknowledgements

SUPER HUGE THANKS TO @maebeam @diamondhands0 @tijno @jsondevlin @silly-hack and all of the core team, community devs, and all of BitClout for supporting us all throughout!

[Zyther]

deso-protocol/frontend#436