NOTE: This issue should be converted to a discussion when discussions are available. At the moment, they are locked.
cip: To be assigned
title: Sources field for SUBMIT_POST transactions
author: Hunter Paulson [@HPaulson](https://github.com/HPaulson)
discussions-url: To be added
created: 2021-07-07
Note: This is a CIP duplication of bitclout/core #32
One-Line Description
Add a new Sources field added to SUBMIT_POST transaction types to allow applications to specify where a post is meant to display.
Explanation and Motivation
Provide a simple explanation of the CIP.
As the BitClout ecosystem expands, and many new applications are built on top of the protocol, having a standard for node-specific content will become vital. For example, if an engineer wanted to create an app built on top of the protocol which only displayed posts meant for that app (For example, if you wanted to make a Reddit-like app, it wouldn't make sense to display all posts from all subreddits on one twitter-like feed), the app could formulate a field like such in the request: Sources: ["myApp.com"]. BitClout.com, and any other nodes looking to display all content, could use the "Default" source to signify it displays regular content not specific to an application type. Those nodes could filter by this source. This could allow engineers to display posts only allowed for their source, without doing anything too hacky.
I think for the long-term success of BitClout we need many types of applications built on top of the protocol, and additions like this would be very very helpful in accomplishing such.
In addition, the backend may want to add a conditional to check if a post is meant for itself -- though this would be up to the discretion of the node operator. A possible solution is adding a backend flag that designates what such node uses as its source. For example, --source bitclout.com would active such a conditional to only return posts which include bitclout.com in its Sources array, where no flag would include all posts regardless of its Sources.
Core
The CreateSubmitPostTxn function should be updated to accept the Sources data as a parameter. The Source field should also be added to the SubmitPostMetadata struct with its appropriate []byte type. Finally, the usages of SubmitPostMetadata should be updated: Main, Test
Frontend
The SubmitPost method should be updated to include Sources: Array<string> as an parameter, and should include such as an argument when calling the Api post function. Additionally, the submitPost method should be updated accordingly, including Sources: ["bitclout.com"] in it's call to SubmitPost().
Other Solutions
While methods for accomplishing such a task already exist, for example hiding a post by default and making use of PostExtraData to identify the source application & if the post is actually hidden or not, however, I think having a standard method of doing such would be a much better, and long-lasting, solution.
NOTE: This issue should be converted to a discussion when discussions are available. At the moment, they are locked.
cip: To be assigned title:
Sourcesfield forSUBMIT_POSTtransactions author: Hunter Paulson [@HPaulson](https://github.com/HPaulson) discussions-url: To be added created: 2021-07-07 Note: This is a CIP duplication of bitclout/core #32One-Line Description
Add a new
Sourcesfield added toSUBMIT_POSTtransaction types to allow applications to specify where a post is meant to display.Explanation and Motivation
Provide a simple explanation of the CIP.
As the BitClout ecosystem expands, and many new applications are built on top of the protocol, having a standard for node-specific content will become vital. For example, if an engineer wanted to create an app built on top of the protocol which only displayed posts meant for that app (For example, if you wanted to make a Reddit-like app, it wouldn't make sense to display all posts from all subreddits on one twitter-like feed), the app could formulate a field like such in the request:
Sources: ["myApp.com"]. BitClout.com, and any other nodes looking to display all content, could use the"Default"source to signify it displays regular content not specific to an application type. Those nodes could filter by this source. This could allow engineers to display posts only allowed for their source, without doing anything too hacky.I think for the long-term success of BitClout we need many types of applications built on top of the protocol, and additions like this would be very very helpful in accomplishing such.
Specification
Backend
The new field,
Sources: []string, should be added to typings for bothPostEntryResponseandSubmitPostRequest. Additionally, theSubmitPostfunction should be updated to include the data fromSourcesin its call toCreateSubmitPostTxn`.In addition, the backend may want to add a conditional to check if a post is meant for itself -- though this would be up to the discretion of the node operator. A possible solution is adding a backend flag that designates what such node uses as its source. For example,
--source bitclout.comwould active such a conditional to only return posts which includebitclout.comin itsSourcesarray, where no flag would include all posts regardless of itsSources.Core
The
CreateSubmitPostTxnfunction should be updated to accept theSourcesdata as a parameter. TheSourcefield should also be added to theSubmitPostMetadatastruct with its appropriate[]bytetype. Finally, the usages ofSubmitPostMetadatashould be updated: Main, TestFrontend
The
SubmitPostmethod should be updated to includeSources: Array<string>as an parameter, and should include such as an argument when calling theApi post function. Additionally, thesubmitPostmethod should be updated accordingly, includingSources: ["bitclout.com"]in it's call toSubmitPost().Other Solutions
While methods for accomplishing such a task already exist, for example hiding a post by default and making use of
PostExtraDatato identify the source application & if the post is actually hidden or not, however, I think having a standard method of doing such would be a much better, and long-lasting, solution.Backwards Compatibility
There are no issues with backward compatability
Test Cases
The only required test should be an update to
TestSerializeSubmitPost, as described above.Security Considerations
None.