Change to Script Rules for HTML Site

[Bassiliya]

I know it's been said before, but I think another thing that I think needs to be addressed by the devs is how this would cripple mobile-only users. There is a good deal of phone, tablet, iPad, smart-device only people who play the game. Their recruitment ability is basically zilch without a system that creates auto-filled links.

Why do you say that? We introduced Telegram Templates specifically so that manual recruiters wouldn't need to repeatedly type out the same message (or copy and paste it).

Because recruiting on a phone or a tablet is a nightmare, normally. It's not just templates; it's tapping on the nation, scrolling down to the telegram box, opening it, pasting, sending, and then going back. It's a lot of work on a computer; on a phone or mobile device, it's really difficult. I know people who, when this change first was presented, said they would have to quit recruiting because they don't have the time and/or desire to flip-flop between pages. Recruitment is hard enough and returns little enough that adding the element of trying to do it on a phone just makes it pointless.

[Diarcesia]

If I understand this correctly, can we create scripts that perform restricted actions (in my case, auto-generating a forum post for a maintenance thread) if it performs exactly one action per one instance of user input?

Bumping, since I don't have a clear answer yet.

[Mark]

If I'm reading this right, then you wouldn't be able to call https://m.nationstates.net/page=compose ... =Markanite and then have the recruiter fill in the boxes manually. They'd have to go to the main nation page, click the telegram box and then populate the boxes?

Correct, as sending "?tgto=<TARGET>" to the telegrams HTML page triggers an interaction, prepopulating the recipient box.

Thanks for getting back to me so quickly.

I think I concur with the others in the thread that this might make manual recruiting even more difficult than it currently is.

[Riemstagrad]

Is there a plan on how to enforce such rule-changes?

Is there a way admin can see the difference between a player CTR+V a telegram-text or a script pasting that same text?
If not, i don't expect people to stop using those scripts. The only thing that will change is that scripters will no longer share their scripts and will operate in silence. Keeping the advantage only to themselves. Those scripts going underground might trigger players with very limited scripting skills to create their own thing, without the current peer control to filter out the errors. Might even increase bots going rampant.
People will always try to make their interaction with the game more comfortable. That's a universal thing.

I understand that a change is needed and i also understand that there is very limited admin-time but i don't believe that such hard restrictions for scripts on the html-site are a good solution.

The only reason card players are using scripts on the html-site and disturbing the issues-part of the game is because the only way to generate card-packs is to do issues on the html-site. A button with a timer on the cards-page, maybe also accessible through he api, would solve both problems.

[Phydios]

Is there a plan on how to enforce such rule-changes?

Is there a way admin can see the difference between a player CTR+V a telegram-text or a script pasting that same text?
If not, i don't expect people to stop using those scripts. The only thing that will change is that scripters will no longer share their scripts and will operate in silence. Keeping the advantage only to themselves. Those scripts going underground might trigger players with very limited scripting skills to create their own thing, without the current peer control to filter out the errors. Might even increase bots going rampant.
People will always try to make their interaction with the game more comfortable. That's a universal thing.

If these scripts weren't having an effect that admin could track, why would they care about them?

[Riemstagrad]

If these scripts weren't having an effect that admin could track, why would they care about them?

Just asking. I guess URL's with a payload are easy to spot, but how would admin know if a telegram-box is filled by a user pressing CRT+V or by a browser-script? I think this is a valid question because such scripts are banned in the new rules.

[Giraffeton]

If I understand this correctly, can we create scripts that perform restricted actions (in my case, auto-generating a forum post for a maintenance thread) if it performs exactly one action per one instance of user input?

what about scripts for prohibited actions?

[Cerb]

I want to follow up and confirm my understanding, with specific reference to the "To" field of the telegram.

In our current recruitment system we load the site in an iframe and the recruiter is presented with the nations page.
The recruiter then needs to read the nation page, determine where the nation is, and whether the nation is a good fit for the region.

The recruiter then has two buttons on the site that contains the iframe. A "Recruit" button and a "remove unsuitable nation" button. If the recruiter clicks the "Recruit" button the iframe reloads to the telegram page, and the nation name is part of the URL query string and is then brought into the "To" field. By the definition of the new rule would seem to ban this, even though any manual site user can add a nation into the URL query string.
In fact our "Recruit" button is exactly the same behavior as clicking the "Write telegram" link. The only purpose of the button is to register the action of recruitment.

The number of steps to do the recruitment are identical as a purely manual effort, with the only exception that our tool manually collects the information of who the recruiter interacted with.
No scripting occurs on the HTML site at all.

Can we reconsider the to field as anyone, be they manual recruiter or just someone wanting to send a telegram, can add a nation name as part of a query string and go to:
https://m.nationstates.net/page=compose ... ?tgto=Cerb

Pretty please?

[Durm]

Does this ban ad blockers? If it does, many players will quit.

[WayNeacTia]

Does this ban ad blockers? If it does, many players will quit.

Why would it?

[Vylixan]

Does this ban ad blockers? If it does, many players will quit.

Why would it?

Because ad blockers interact with the HTML site. Otherwise they would be rather shitty ad blockers.

[Onionist Randosia]

Why would it?

Because ad blockers interact with the HTML site. Otherwise they would be rather shitty ad blockers.

I thought the proposed rules still allowed cosmetic changes to a page, wouldn’t adblockers fall under that?

[Giraffeton]

I thought the proposed rules still allowed cosmetic changes to a page, wouldn’t adblockers fall under that?

nope, i believe the rules ban any script that interacts with the issue html

[Phydios]

I thought the proposed rules still allowed cosmetic changes to a page, wouldn’t adblockers fall under that?

nope, i believe the rules ban any script that interacts with the issue html

From the very beginning of the proposed ruleset:

1. Only Perform Acceptable Actions

It is acceptable to use a tool that merely modifies how pages look. For example, a script may legally add particular buttons when viewing other people's nation pages. Similarly, any kind of information-gathering script is acceptable, subject to the Rate Limits described below.

[Racoda]

From the very beginning of the proposed ruleset:

1. Only Perform Acceptable Actions

It is acceptable to use a tool that merely modifies how pages look. For example, a script may legally add particular buttons when viewing other people's nation pages. Similarly, any kind of information-gathering script is acceptable, subject to the Rate Limits described below.

Literally the next paragraph (underlined and coloured it for ya in orange):

1. Only Perform Acceptable Actions

It is acceptable to use a tool that merely modifies how pages look. For example, a script may legally add particular buttons when viewing other people's nation pages. Similarly, any kind of information-gathering script is acceptable, subject to the Rate Limits described below.

A tool may never perform a "prohibited action" via the HTML site. Prohibited actions should instead be performed via the NationStates API. A tool is performing a prohibited action if it interacts with the HTML site in any way during the execution of the action, including pre-filling form fields and auto-generating HTML links containing embedded information. For example, it is illegal for a tool to generate links that, when clicked, take a user straight to their Telegrams page with recipient names and message content auto-filled-in. Prohibited actions are:

• sending a telegram
• answering / dismissing an issue

A tool may not independently perform a "restricted action" via the HTML site. […]

[Onionist Randosia]

From the very beginning of the proposed ruleset:

Literally the next paragraph (underlined and coloured it for ya in orange):

1. Only Perform Acceptable Actions

It is acceptable to use a tool that merely modifies how pages look. For example, a script may legally add particular buttons when viewing other people's nation pages. Similarly, any kind of information-gathering script is acceptable, subject to the Rate Limits described below.

A tool may never perform a "prohibited action" via the HTML site. Prohibited actions should instead be performed via the NationStates API. A tool is performing a prohibited action if it interacts with the HTML site in any way during the execution of the action, including pre-filling form fields and auto-generating HTML links containing embedded information. For example, it is illegal for a tool to generate links that, when clicked, take a user straight to their Telegrams page with recipient names and message content auto-filled-in. Prohibited actions are:

• sending a telegram
• answering / dismissing an issue

A tool may not independently perform a "restricted action" via the HTML site. […]

Just covering up adds falls under 'cosmetic changes' and would probably not necessitate interaction with the HTML site. According to those 'button' rules, you could technically add a button that pressed the little 'x' thing in the corner of the add (because you can do that anyways) and then covered over the 'report add | Why this add?' thing that you get after you do that. Also, ads on NS (at least for me) aren't a huge problem because they don't actually stop you from doing anything, they just appear in a sidebar. You can still continue doing what you were doing. I suspect if you did have to wait for ads to be over, it would screw up R and D gameplay.

...Actually, now there's an idea... allowing players to post advertisements as a way of recruiting...
(like on Politics and War)

[WayNeacTia]

...Actually, now there's an idea... allowing players to post advertisements as a way of recruiting...
(like on Politics and War)

It's been done.

[United Calanworie]

Literally the next paragraph (underlined and coloured it for ya in orange):

Just covering up adds falls under 'cosmetic changes' and would probably not necessitate interaction with the HTML site. According to those 'button' rules, you could technically add a button that pressed the little 'x' thing in the corner of the add (because you can do that anyways) and then covered over the 'report add | Why this add?' thing that you get after you do that. Also, ads on NS (at least for me) aren't a huge problem because they don't actually stop you from doing anything, they just appear in a sidebar. You can still continue doing what you were doing. I suspect if you did have to wait for ads to be over, it would screw up R and D gameplay.

...Actually, now there's an idea... allowing players to post advertisements as a way of recruiting...
(like on Politics and War)

Adblockers interact with the HTML site. It's not a "cosmetic change," it's changing elements on the page.

[Onionist Randosia]

...Actually, now there's an idea... allowing players to post advertisements as a way of recruiting...
(like on Politics and War)

It's been done.

Interesting.

[Sweeze]

heya, want some quick clarification- would setting a region's welcome telegram count as "sending a telegram" and thus a prohibited action in this instance, or would it just be a restricted one?

[[violet]]

I understand the exemption for "merely changes how pages look" can appear to collide with the proposed prohibition on scripts "interacting with the HTML site in any way" when the user is sending telegrams and answering issues.

In general, we aren't concerned with themes, ad blockers, or any other kind of standard quality-of-life tool common to the internet. We are concerned with scripts, bots, and pre-generated URLs that contain payloads. It can be difficult to draw a hard line here, because there's a wide and ever-evolving range of tech, from simple browser plug-ins to server-hosted bots, and their resulting HTML can be very similar, or even identical. But the idea is not to target simple/blind/dumb styling and theming. Rather, we want to address scripts and bots that specifically target the telegrams & issues pages.

[Flanderlion]

I understand the exemption for "merely changes how pages look" can appear to collide with the proposed prohibition on scripts "interacting with the HTML site in any way" when the user is sending telegrams and answering issues.

In general, we aren't concerned with themes, ad blockers, or any other kind of standard quality-of-life tool common to the internet. We are concerned with scripts, bots, and pre-generated URLs that contain payloads. It can be difficult to draw a hard line here, because there's a wide and ever-evolving range of tech, from simple browser plug-ins to server-hosted bots, and their resulting HTML can be very similar, or even identical. But the idea is not to target simple/blind/dumb styling and theming. Rather, we want to address scripts and bots that specifically target the telegrams & issues pages.

The better way to address scripts and bots specifically targeting the telegrams and issues pages is to remove the 'need'. Card farmers use the issues page because the game design funnels them into using that page, and it's the most efficient route of gaining cards. Solutions have already been proposed prior. Similarly with manual TGs.

[Twertis]

Second, we want to make it explicit that bots that generate special URLs containing embedded information to pre-fill form fields are indeed considered to be interacting with the HTML site as described above. That is, we want it to be clear that a bot cannot legally craft URLs that, when clicked by a human, will take them to the HTML telegrams interface and automatically fill out fields like "To:" and the message content. There are several of these bots around, and we understand they've been perceived as legal because they don't do anything automatically -- a human has to click the link for anything to happen. We want to explicitly address this in the rules, and make it clear that it's not permissible on the HTML site -- again, you can do it via the API -- when sending telegrams or answering issues.

The playerbase seems to be near-unanimously agreed that one of the most major factors in the perceived decline in gameplay activity — the slow growth and lack of power in UCRs — is in part a result of the difficulty to recruit nations out of the feeders. This would only exacerbate the problem.

If you implement this change without first addressing the issue of recruitment, you might risk alienating your players even more.

But I really don't see why you have to. Embedding parameters in links is a minor quality of life change accessible to anyone willing to spend a few hours learning Python, or who can get it from someone else. This aspect of NS is stable and seems to be free of any real cheating (unless admin has evidence to the contrary). I feel as though we may be fixing a problem that's not really there.

[Onionist Randosia]

I do hope that the API rate limit is buffed to 90 seconds. With the changes to manual recruitment more people will probably look to the API.

[Bassiliya]

I understand the exemption for "merely changes how pages look" can appear to collide with the proposed prohibition on scripts "interacting with the HTML site in any way" when the user is sending telegrams and answering issues.

In general, we aren't concerned with themes, ad blockers, or any other kind of standard quality-of-life tool common to the internet. We are concerned with scripts, bots, and pre-generated URLs that contain payloads. It can be difficult to draw a hard line here, because there's a wide and ever-evolving range of tech, from simple browser plug-ins to server-hosted bots, and their resulting HTML can be very similar, or even identical. But the idea is not to target simple/blind/dumb styling and theming. Rather, we want to address scripts and bots that specifically target the telegrams & issues pages.

If this is the case, perhaps an alternate wording should be given to "interacting with the HTML site in any way" and be a lot more specific about what you mean. If "interacting with the HTML site in any way" means "having a pre-gen URL" (which really makes no sense as to why, since there's no interaction but simple use of the existing infrastructure that makes no calls) but not "changing the literal code of the HTML site for a theme or adblocker", then that should probably be specified.

On that topic, I've yet to receive a clear response regarding whether or not all pre-gen'd telegrams are banned from use or if it is specifically targeted toward recruitment telegrams. If the former, that would cut out people who make use of their coding knowledge to generate regional endorsement campaigns. Why should that be removed? It's only giving an advantage to regions that will take the time to learn a few minutes of code. It's hardly inaccessible knowledge, nor is it overly complicated to figure out (despite what some people make it sound like). If it is the latter, why are you targeting manual recruiters for restrictions when we all know that manual is by far the most detrimentally broken form of recruitment? Like, if you're wanting people to "keep manual manual", good to know that this game is incapable of evolving to catch up with the changing times and increased availability of scripts and script-creators. Why punish those who take a few hours to learn how to code a tool like this? Furthermore, why create a false sense of scarcity of these publicly available tools? Why not just come out and say "we really just want people to use more stamps"? This feels much less like a forward development and far more like a very great leap backwards.