Remove commenting, loving and faving functionality

[Chiroyce1]

• It is already against Scratch's Terms of Use
• Most people don't use it, unlike the cloud variable features which are used a lot!
• Even if people do use it, it's probably for bad a reasons like spamming.

[Sid72020123]

Ok. I will think over it. React the above Chiroyce's comment with "thumbs up" or "thumbs down". Let's see how many people want that feature to be removed...

[webdev03]

Thumbs up is "remove it" thumbs down is "don't remove it" right?

[webdev03]

If you remove commenting, also remove love, favourite, follow,

[Chiroyce1]

If you remove commenting, also remove love, favourite, follow,

Yes, we also don't need these. We need this library to be useful for people who want to make cool projects, and not for those who want to spam comments or use follow bots.

[Sid72020123]

Ok. I will remove those features soon. But it may take a long time as my school started and I'm in higher school now. I am busy now... BTW what do you think of adding a limit. Such as which stops commenting twice on a user's profile and can't comment again until next hour? But he/she can comment on other user's profile only once per hour. I may do the same for loves, faves, and follows...

[Sid72020123]

Thumbs up is "remove it" thumbs down is "don't remove it" right?

Yes.

[Mbrick2]

When you remove it keep the code in a separate repo so the code is still there in case of someone needing some code for that

[Sid72020123]

But then people will still see the code and make bots... Ok. I will keep the code in a separate repo.

[Sid72020123]

But people can still download earlier versions and make those spam bots...

[Chiroyce1]

When you remove it keep the code in a separate repo so the code is still there in case of someone needing some code for that

It will still be there in the git history - a separate repo is not required.

[Sid72020123]

Ok.

[Sid72020123]

Oh. It looks like there are more votes to remove the feature. Ok. I will wait for a week and see what the people say. Then I will surely remove the feature when I get time...

[CubeyTheCube]

When you remove it keep the code in a separate repo so the code is still there in case of someone needing some code for that

It will still be there in the git history - a separate repo is not required.

What is the point of this in the first place, then? Anyone interested in making a bot would simply look in the history of the repository and see the code.

[Chiroyce1]

What is the point of this in the first place, then? Anyone interested in making a bot would simply look in the history of the repository and see the code.

Firstly, AFAIK these users directly download from PyPI via pip . Secondly it is unlikely that they go back through the git history on the website itself, since it isn't very straightforward here (you need to find the specific file with the comment function and then view it's commits)... this should help at least a bit. I think we can discuss this further...

[Sid72020123]

Wait. I think I can delete the previous versions on pypi. Is there any way to delete git history?

[Chiroyce1]

Nope, unless you create a new repository. Is that ok? You will then have to delete this, and upload it in a new repository called scratchconnect. Then you will lose all stars, watches, forks, releases and previous commits.

[Sid72020123]

No. I won't delete this... Let me see if I can delete git history...

[webdev03]

Removing the git history would need everyone to re-clone right? What about the contributor list (depends on author emails)?

Chiroyce there is a way to remove history (delete .git and add the remote, then force push), but it has one problem, the commit hash like abcdef will still work, so deleting the repo is the only way to remove the hashes. Anyways people will just use a different library or someone will code it themselves. Still it would be one way to reduce the spamming.

We also need to consider the people who download it once and never update too, it would go on for a while, and please don't add a killswitch into your program.

[Sid72020123]

Ok. So do you think that I should not delete this repo's history?

[Sid72020123]

I will only delete the old versions on pypi and update the code here to remove user actions. Is it ok? But the spammers can use other libraries like scratchclient and scratch2py.

[Mbrick2]

If people are spamming they could just make there own requests using the request library. Its not rocket science (for comments at least. Cloud is very complex though)

[Sid72020123]

Yes. So should I remove this feature or no?

[Chiroyce1]

If people are spamming they could just make there own requests using the request library. Its not rocket science (for comments at least. Cloud is very complex though)

This makes it a lot more easier. This will definitely reduce the amount of spam. But sadly we have a huge problem in front of us, most people use the older version and will not update.... so this is sort of pointless... BUT it will prevent any new spammers from rising..

[Sid72020123]

Yes. But if they are making bots, the code must be stored somewhere on the server. So during runtime, the library will be downloaded again to latest version, if the user has not given any version argument. I can delete all the previous versions on pypi. So, the previous versions will not get downloaded. But if the user has stored the library's code on the server and doesn't require installation, then that user might be able to make spam bots.

[Chiroyce1]

So during runtime, the library will be downloaded again to latest version, if the user has not given any version argument.

Unlikely - if they do a pip install scratchconnect for scratchconnect, it won't be updated unless they manually run pip install --upgrade scratchconnect

[Sid72020123]

Yes. I know. But we can request them to install the latest version...

[webdev03]

Some people don't like auto-updating open source software. Sometimes they believe it is not FLOSS software if it has auto updating mandatory.

[Chiroyce1]

Some people don't like auto-updating open source software. Sometimes they believe it is not FLOSS software if it has auto updating mandatory.

We can't even enforce it - we have to give a reason for why they should update. And if we tell them the actual reason, they'd obviously not want to update (the spammers)

[webdev03]

The solution seems very empty, easily bypassed, also they'll all switch to scratchclient. I think all of the library makers should work together then. Also what if they are using DevTools Console?

[Chiroyce1]

Everyone, the point of this is not to completely stop spammers, but to discourage them from doing so. If we remove the functionality from this, then they'll have to make their own (either by referring the older commits or on their own), so they might feel like it's too much work and decide to stop spamming.

[Sid72020123]

Ok. Then I will remove those features. What about follow/unfollow?

[kccuber-scratch]

replit's poetry thing already updates modules. also remove the reporting functionality

[Chiroyce1]

replit's poetry thing already updates modules. also remove the reporting functionality

thats a good idea - people using replit for spamming can not do so after the update, and reporting should definitely be removed as well.

[Sid72020123]

Oh. So reporting also causes spam? What about unfollowing?

[CubeyTheCube]

Everyone, the point of this is not to completely stop spammers, but to discourage them from doing so. If we remove the functionality from this, then they'll have to make their own (either by referring the older commits or on their own), so they might feel like it's too much work and decide to stop spamming.

No spammer that would spam enough to become annoying would stop after being discouraged. All this does is curb functionality due to a few bad actors. Of course commenting using scripts is against the rules, but there are legitimate reasons that you could do so (it's not against the rules if you don't get caught) and what this does is discourage genuine creativity in favor of (possibly) mildly annoying some spammers. FWIW, I doubt any decent bot uses Python anyway because async in Python is weird, so it's pretty likely that this will have no effect on spammers. I don't think personal sentiment is a good tool to decide what gets removed from software.

[Chiroyce1]

After some thoughtful consideration, I feel like we should not remove this. The bots spamming aren't our problem, and the ST has shutdown a lot of them in the past 2-3 days. So technically instead of use trying to discourage the spammers, it's better if the ST bans them altogether.

[Sid72020123]

Ok. So, should I keep those commenting and other functionalities? No need for removing them?

[webdev03]

It's not allowed to spam or bot @Chiroyce1

[Chiroyce1]

It's not allowed to spam or bot @Chiroyce1

That would be a very weird restriction, and it'll still be able to spam others.

[webdev03]

It's not allowed to spam or bot @Chiroyce1

That would be a very weird restriction, and it'll still be able to spam others.

You said "it's better if the ST bans them altogether." but the ST already bans the spammers/botters?

[Sid72020123]

And ST deletes the spammed content. Right?

[Chiroyce1]

And ST deletes the spammed content. Right?

They do, but only after a few hours. And not all of them. Spam comments from 5 days ago are still out there.

[Sid72020123]

Oh. The ST should have the way to delete all the spammed content.

[Sid72020123]

BTW @Chiroyce1 can also disallow commenting on his profile...

[Chiroyce1]

BTW @Chiroyce1 can also disallow commenting on his profile...

That's not how the spam is going on. They're abusing the reply function to reply to ghost comments on other people's profiles, so I get a notification for a reply to a comment I never even made.

[Sid72020123]

Oh :(

[Quantum-Codes]

How about a new update where a reply automatically pings the parent commenter? This will eliminate ghost pings. Just idk what to do of people using older versions of the package.

dumb idea: ask ST to require some other unnecessary piece of data which will break older versions of commenting

[Sid72020123]

Oh. Let me think of that... I think I will remove the whole commenting feature... Also, I can see that there is a tie in the votes... Ok. Now, I need to remove the following (Tell me if I can remove anything else or keep it):

• commenting: user, studio, project
• report
• follow/unfollow
• love a project
• fave a project

Anything else?

[Sid72020123]

Oh. Now I can see that there are "6" votes for not removing that feature and "5" votes for removing it. I think not removing wins. But I will wait for today...

[Sid72020123]

What about adding a time limit in which a user can only post comments on the same profile only once per hour? But can comment on other's profile only once per hour.