Social action reporter blocks [SOLUTION]

ScratchUser139

Before you say it's rejected, look here:

I know this is rejected:

Za-Chary wrote:
1.4 Social action reporter blocks
This block could be used, for example, to obtain the current number of loves of the project. However, project creators can easily use these blocks to prevent Scratchers from playing unless the project is given enough loves. If a user presses the love button on a project, it should be because they enjoyed the project, not because they are trying to reach some sort of goal. Social actions are not intended to be a way to interact with a Scratch project.

This suggestion extends to all social actions, including views, loves, favorites, remixes, comments, and followers. It also extends to boolean blocks which involve social actions.
(number of [loves v] :: sensing)

We still propose a solution which stops this from being an issue but still allows for positive and meaningful use of social action information by Scratchers.

To satisfy the Scratch Team's needs, we suggest the following restrictions:
1. Read-Only Data (No Boolean Conditions)
The reporter block should yield numeric values (e.g., the number of loves or favorites) rather than a Boolean (true/false) value.
This prevents Scratchers from withholding access to content based on whether a project has been favorited or loved.

2. Delayed Data Updates (Prevents Sudden Checking)
The block must update only every 10 minutes per project session.
This prevents projects from constantly checking for new loves/favorites and dynamically locking or unlocking content based on current user actions.

3. No Direct Player Interaction Restrictions
The block should not allow conditional access to gameplay or content on the basis of its value.
To implement this, the block's value should only be accessible within the Stage and never in If-Else.
Example: A project might display “This project has 100 loves!” but never “If loves > 50, unlock secret level.”

4. Limited to Non-Intrusive Data (Only Loves & Favorites, Not Views or Comments)
The block should only transmit the number of loves and favorites so as not to track too much.
It should not transmit views, comments, remixes, or followers because those can be used for tracking individual users.

Why This Works:
✅ Encourages Healthy Engagement – Scratchers can design projects that acknowledge their accomplishment (e.g., “Thanks for 100 loves!”) without forcing users to love projects.
✅ Prevents Abuse – The constraints keep social activity voluntary and not as a prerequisite to play.
✅ Prolongs Scratch's Original Values – Folks will keep loving projects because they love them, not because they have to.

With these safeguards in place, social action reporter blocks can be useful and ethical. We hope the Scratch Team will change their mind regarding rejecting this feature with these safeguards in place.

cake__5

ok i want there to be social action reporter blocks but not like this.

first of all, here is what it should track:
loves, favorites, remixes, views, comments, follows of ____, ____ loving?, ____ favoriting?, ____ commented?, ____ status?
it should be updated every instantly, and be allowed anywhere.

and honestly i dislike the fact that you made this post because this is the version ST will most likely implement, and i JUST WISH THAT ITS MY VERSION INSTEAD

ScratchUser139

Za-Chary wrote:
1.4 Social action reporter blocks
This block could be used, for example, to obtain the current number of loves of the project. However, project creators can easily use these blocks to prevent Scratchers from playing unless the project is given enough loves. If a user presses the love button on a project, it should be because they enjoyed the project, not because they are trying to reach some sort of goal. Social actions are not intended to be a way to interact with a Scratch project.

This suggestion extends to all social actions, including views, loves, favorites, remixes, comments, and followers. It also extends to boolean blocks which involve social actions.
(number of [loves v] :: sensing)

Last edited by ScratchUser139 (Today 15:07:42)

gilbert_given_189

ScratchUser139 wrote:
1. Read-Only Data (No Boolean Conditions)
The reporter block should yield numeric values (e.g., the number of loves or favorites) rather than a Boolean (true/false) value.
This prevents Scratchers from withholding access to content based on whether a project has been favorited or loved.

Yet the example that you give seems to output a numeric value. Not a good counterreason.

Just saying, your topics seems to set on a specific format, which makes my text discriminator tingle… Please tell me if I'm wrong.

cake__5

ScratchUser139 wrote:
Za-Chary wrote:
1.4 Social action reporter blocks
This block could be used, for example, to obtain the current number of loves of the project. However, project creators can easily use these blocks to prevent Scratchers from playing unless the project is given enough loves. If a user presses the love button on a project, it should be because they enjoyed the project, not because they are trying to reach some sort of goal. Social actions are not intended to be a way to interact with a Scratch project.

This suggestion extends to all social actions, including views, loves, favorites, remixes, comments, and followers. It also extends to boolean blocks which involve social actions.
(number of [loves v] :: sensing)

you already saiddd thatttttt

ScratchUser139

cake__5 wrote:
ok i want there to be social action reporter blocks but not like this.

first of all, here is what it should track:
loves, favorites, remixes, views, comments, follows of ____, ____ loving?, ____ favoriting?, ____ commented?, ____ status?
it should be updated every instantly, and be allowed anywhere.

and honestly i dislike the fact that you made this post because this is the version ST will most likely implement, and i JUST WISH THAT ITS MY VERSION INSTEAD

Discuss Scratch