Draft of new OSRS Script Rules

[Roavin]

• To reiterate my previous question: what has changed since this post? I understand [violet] wants the change, but as others have mentioned, we have still not been informed as to why there is such an insistence, despite community response, precedent, and feasibility/health.

It's difficult to give an exhaustive answer, as there are several layers to this and, as stated before, it's still an open (and active) discussion internally. There's the question on a philosophical level of how much of manual recruitment should be truly manual, the technological question of autofill in general (which touches other aspects than telegrams, though that's the part that is being "yelled" about the loudest), and how that generally fits into paradigms now and going forward.

• Do we have any ETA on when we can expect a conclusion to the internal discussion? This limbo is harmful to community growth, and I expect several regions, mine included, will be finding that out the hard way in the coming days/weeks.

I don't have an ETA, but it'll be resolved before this draft goes live. Note that we didn't disable Dot's recruitment function, but rather Dot's author did; from our perspective, Dot can continue to use autofill while we resolve this and there'll be an appropriate grace period after that no matter how things end up being.

The off-site reception to this particular bit has been poor, especially the portion that (as we've interpreted it) requests we not post at all unless it's a "new argument not made before". Is there a reason the discourse has to be redirected when it relates to the rules draft as it stands, and furthermore, if it has to be redirected, why must all new comments be un-said prior to now? It's particularly restrictive in a situation where so many people/communities will be impacted in similar ways.

It's simply a separation of concerns. This thread is about the new draft for the script rules, which includes so much more than this one aspect. In fact, this thread addresses the issue you raise only insofar as it addresses the underlying technological principle of autofill used by Dot's recruitment feature. These are the things that fall into my purview as Scripting Development Manager. This thread doesn't address telegram recruitment as a feature — that's outside of my area of responsibility (as it falls into UC's portfolio as Gameside Comms Development Manager) and is the topic of the other thread.

That new comments must be unsaid is more of a suggestion from me; ultimately, it's UC's call on how she wants her thread to be operated. I'll edit my post accordingly.

[Onionist Randosia]

As someone who's region's life line is a recruitment API that will get banned if this becomes a rule I see this having a few problems. Though I must apologize for my knowledge on APIs I didn't set the one for my region up. This will kill growth. It's hard enough getting people to join using the API, its even harder getting active users to join, and nobody is the community is willing to spend money on stamps. And for clarity the API we used didn't send telegrams on its own, You would need to send it yourself. Not sure if this last point on telegrams breaks or follows the possible rule.

I don’t think these rules apply to the API, just the actual NS site’s HTML.

[Roavin]

As someone who's region's life line is a recruitment API that will get banned if this becomes a rule I see this having a few problems. Though I must apologize for my knowledge on APIs I didn't set the one for my region up. This will kill growth. It's hard enough getting people to join using the API, its even harder getting active users to join, and nobody is the community is willing to spend money on stamps. And for clarity the API we used didn't send telegrams on its own, You would need to send it yourself. Not sure if this last point on telegrams breaks or follows the possible rule.

Whoops sorry, I missed your post! As Onionist Randosia already stated correctly, the proposed change here doesn't apply to API recruitment which you can continue to do to your heart's content.

I wondered if the script we know as Got-issues. which uses the API to construct an HTML site, to answer issues faster, would be legal under the new rules.

I don't want to rule on GotIssues as a whole, but I can address the specific functionality you described. Generating the link as you stated would no longer be allowed since it's implicitly sending a prohibited action, but the reason here may also related to the manual recruitment telegram issue mentioned in this thread and the resolution to that might impact this, so watch this space.

By the way, GotIssues was updated earlier this year and now simply shows the issue page, while an associated TamperMonkey extension selects a random issue. The former is fine, while the latter isn't because it breaks the "unique input sequence" rule (i.e., it's fine to have buttons 1-4 to select issue answers 1-4, but not to in any way automate the decision, even if it's random, that a tool providing alternate input methods makes).

[Fauzjhia]

As someone who's region's life line is a recruitment API that will get banned if this becomes a rule I see this having a few problems. Though I must apologize for my knowledge on APIs I didn't set the one for my region up. This will kill growth. It's hard enough getting people to join using the API, its even harder getting active users to join, and nobody is the community is willing to spend money on stamps. And for clarity the API we used didn't send telegrams on its own, You would need to send it yourself. Not sure if this last point on telegrams breaks or follows the possible rule.

Whoops sorry, I missed your post! As Onionist Randosia already stated correctly, the proposed change here doesn't apply to API recruitment which you can continue to do to your heart's content.

I wondered if the script we know as Got-issues. which uses the API to construct an HTML site, to answer issues faster, would be legal under the new rules.

I don't want to rule on GotIssues as a whole, but I can address the specific functionality you described. Generating the link as you stated would no longer be allowed since it's implicitly sending a prohibited action, but the reason here may also related to the manual recruitment telegram issue mentioned in this thread and the resolution to that might impact this, so watch this space.

By the way, GotIssues was updated earlier this year and now simply shows the issue page, while an associated TamperMonkey extension selects a random issue. The former is fine, while the latter isn't because it breaks the "unique input sequence" rule (i.e., it's fine to have buttons 1-4 to select issue answers 1-4, but not to in any way automate the decision, even if it's random, that a tool providing alternate input methods makes).

I would be very interested in button to select issues answer.
But I was not aware of the GotIssues updated, and am still using the version that would become illegal.

thanks for answer, time to update it.

[Klaus Devestatorie]

Hello coders, cool rules, nice vscode themes, I hear python is popular at this time of year. Just looking for one specific clarification,

• Answering an issue is now a prohibited action rather than restricted action, since that can be done via the API. But don't panic: your keybind scripts for this purpose are still perfectly okay (so long as they don't programmatically decide which issue to answer).

This feels loopholey to me. Is this specifically only for "deciding which issue to answer", presumably of whatever issues are available to answer, or does it also include which option to choose on an issue? Does it also cover whether or not to dismiss an issue? Would like clarification here as it would affect a private project or two.

[Roavin]

Hello coders, cool rules, nice vscode themes, I hear python is popular at this time of year. Just looking for one specific clarification,

• Answering an issue is now a prohibited action rather than restricted action, since that can be done via the API. But don't panic: your keybind scripts for this purpose are still perfectly okay (so long as they don't programmatically decide which issue to answer).

This feels loopholey to me. Is this specifically only for "deciding which issue to answer", presumably of whatever issues are available to answer, or does it also include which option to choose on an issue? Does it also cover whether or not to dismiss an issue? Would like clarification here as it would affect a private project or two.

Hi there - sorry, I miswrote, I meant to write "which issue option", and dismissing counts as an option. So basically, you can make keybinds for keys 1-4 to answer options 1-4 plus, say, Escape to dismiss the issue, and that's perfectly fine. But having a key "X" that programmatically chooses an option or to dismiss, even if it does so randomly, isn't.

[Klaus Devestatorie]

Hello coders, cool rules, nice vscode themes, I hear python is popular at this time of year. Just looking for one specific clarification,



This feels loopholey to me. Is this specifically only for "deciding which issue to answer", presumably of whatever issues are available to answer, or does it also include which option to choose on an issue? Does it also cover whether or not to dismiss an issue? Would like clarification here as it would affect a private project or two.

Hi there - sorry, I miswrote, I meant to write "which issue option", and dismissing counts as an option. So basically, you can make keybinds for keys 1-4 to answer options 1-4 plus, say, Escape to dismiss the issue, and that's perfectly fine. But having a key "X" that programmatically chooses an option or to dismiss, even if it does so randomly, isn't.

That is unfortunate, but I suppose a human can still do what the script would have done.

[Merni]

[...] it's fine to have buttons 1-4 to select issue answers 1-4, but not to in any way automate the decision, even if it's random, that a tool providing alternate input methods makes).

I hope the Issue Editors are fine with having their option statistics messed up again thanks to people selecting the same option every time.

Honestly, I don't understand any reason (even "philosophical") to ban randomly selection issue options. What possible advantage does it give players over hitting option 1 every time?

[Sedgistan]

I hope the Issue Editors are fine with having their option statistics messed up again thanks to people selecting the same option every time.

Our data is useless already, and it's therefore not a relevant point. For as long as card farming is tied to issue answering, the data is worthless.

[Roavin]

I hope the Issue Editors are fine with having their option statistics messed up again thanks to people selecting the same option every time.

Honestly, I don't understand any reason (even "philosophical") to ban randomly selection issue options. What possible advantage does it give players over hitting option 1 every time?

Answering issues is the most fundamental aspect of playing NationStates, with an appropriate interface for player to read and interact with. For scripts, an API endpoint has existed and been stable for many years now, so just from the view of the Issues game, there's no need to allow tool interaction with page=show_dilemma anymore. The "alternate input method" clause that also applies to prohibited actions is meant for purposes of accessibility and ease-of-use (i.e. things like Breeze++), but not to automate NS to within an inch of its life like some R/D and Cards scripts have done in the past — that's what the API is for!

So the restriction isn't really meant to be a restriction in that sense, but rather an exception to the strict ban of interaction between tools and prohibited actions, and it's somewhat restrictive because otherwise the intended separation between restricted and prohibited actions would be essentially meaningless.

If Cards aren't considered, I think and hope that the above is by and large uncontroversial. With Card generation being tied to the issues game, that's another story, but as Sedge already noted, the data in use by issue editors is currently worthless anyway, not due to selecting the same issue but due to the link between Cards and issues, so in my mind, it makes no difference to make a special exception here afterall.

[Vylixan]

I want to correct a common misconception.

GotIssues does not reconstruct the page, nor does it send it's own requests. It just uses template-overall=none and some custom JavaScript and CSS to make the page as light as possible.
The issue buttons and the associated form are left as they are, albeit unstyled. And thus the request when enacting one of the issue choices is still the native NS one and not a custom one.



Note: I'm not the creator of GotIssues.

[Racoda]

I want to correct a common misconception.

GotIssues does not reconstruct the page, nor does it send it's own requests. It just uses template-overall=none and some custom JavaScript and CSS to make the page as light as possible.
The issue buttons and the associated form are left as they are, albeit unstyled. And thus the request when enacting one of the issue choices is still the native NS one and not a custom one.



Note: I'm not the creator of GotIssues.

That might be true now^[1], but up until this year it would craft links^[2] that when clicked, would answer the issue (and mere clicking of the links from the sheet it generates would have needed to abide by the simultaneity rule^[3]).

[1]: https://github.com/jmikk/gotIssues/blob ... ues.py#L39
[2]: https://github.com/jmikk/gotIssues/blob ... py#L53-L60
[3]: viewtopic.php?p=37657522#p37657522

[Vylixan]

I want to correct a common misconception.

GotIssues does not reconstruct the page, nor does it send it's own requests. It just uses template-overall=none and some custom JavaScript and CSS to make the page as light as possible.
The issue buttons and the associated form are left as they are, albeit unstyled. And thus the request when enacting one of the issue choices is still the native NS one and not a custom one.



Note: I'm not the creator of GotIssues.

That might be true now^[1], but up until this year it would craft links^[2] that when clicked, would answer the issue (and mere clicking of the links from the sheet it generates would have needed to abide by the simultaneity rule^[3]).

[1]: https://github.com/jmikk/gotIssues/blob ... ues.py#L39
[2]: https://github.com/jmikk/gotIssues/blob ... py#L53-L60
[3]: viewtopic.php?p=37657522#p37657522

My post was indeed talking about the current version of GotIssues.

[Roavin]

I have some news about the rules that affect the issue of tool-assisted recruitment as done by Dot etc.; since I'm aware that this thread has garnered significant attention outside of coder circles due to this specific issue, I'll attempt to answer this in a non-technical way.

As Refuge Isle noted, there are two components of the proposed draft that affect how Dot and similar tools handle recruitment.

First, the entire Telegrams interface on the website itself may no longer be interacted with by scripts. This is non-negotiable — the API, which is built deliberately for being interfaced with by scripts, has been available and stable for many years at this point, and scripts interacting with a website user interface rather than with an API deliberately designed for use by scripts is error-prone, risky, and hard to enforce. The specific restrictions surrounding what can be done with the Telegrams API could be changed if there are good arguments for it, but the API is here to stay as the sole option for scripts to send telegrams.

Second, the draft mentions that scripts may not "auto-fill existing form elements" for prohibited page items (such as the Telegrams interface). This refers to things like browser extensions that automatically fill in a text box for a page that is loaded (similar to, say, the auto-complete that pops up when entering your email address on a website). However, this is not what Dot and other tools in question do, and therefore it doesn't apply to them — and in fact, the underlying mechanism of those tools isn't specified at all in the current draft rules!

What these tools do is generate links that the user can click, and these links lead to a page that is loaded with the Telegrams message box prefilled to the content encoded within the generated link. This prefill isn't performed by the browser or by those tools, but rather by NationStates itself. This isn't an intentional feature; rather, it's a side-effect of another feature of NationStates' user interface. On some pages, when the URL to load that page is given certain parameters that any player can easily type into their browser's address bar, NationStates recognizes those parameters and sends them as the initial value of some elements (textboxes etc.) in the page it sends back to the user's browser. This happens with the telegram message box, the telegram recipient field, and some other places on the website as well. From a technical standpoint, therefore, the question isn't one of Telegrams, but rather of URL handling.

We could start policing what sorts of URLs one may generate, but that opens a whole host of issues. Not only is it incredibly difficult to enforce, but it also leads to the absurd situation where a player can break the rules by simply entering something in their address bar or clicking on a benign-looking link. The much better (and easier) solution here is to simply add technological restrictions on the server to prevent player's using URLs we don't want them to. We have decided that so long as it doesn't otherwise violate NationStates Terms of Service or another site rule, players (or scripts) can craft whichever URLs they want, and if we feel that they shouldn't be able to do what their crafted URLs achieve, we simply block it server-side. To that end, we're adding the following addition to the draft in the Miscellaneous section:

Tools may generate any clickable links to NationStates that a user could also type into the address bar manually, so long as the crafted URL is not presented in a way that deceives the user, and clicking it would not otherwise violate the site rules or the terms of service. For example, crafting a URL that shows nation statistics that can't be reached through clicking on the site is fine; crafting a URL that is known to be slow to DDoS the site, or a URL that spams an RMB is not fine; and if you send a URL to resign from the World Assembly to a Delegate and pass it off as "hey, click this to see my puppy dispatch", you can expect very harsh punishment.

There is no guarantee that any URLs not explicitly specified here will remain stable or accessible.

As it pertains to the Telegrams interface specifically, we have decided not to block NationStates' autofill possibilities for at least as long as there are no other changes to how recruitment is done. In other words, Dot etc. can continue to operate as they have been.

Now, can we please get back on track and talk about the rules draft rather than telegram recruitment?

[Giraffeton]

Not sure if this has already been said but

Answering an issue is now a prohibited action rather than restricted action, since that can be done via the API. But don't panic: your keybind scripts for this purpose are still perfectly okay

and

Prohibited actions are:
Answering or dismissing an issue
Sending a telegram
These actions must not be performed by a script, no matter if human-initiated or not, in any case. Note that all of these actions can be performed using the API instead.

Contradict each other as keybind scripts are still scripts and would be illegal under the ruling

If keybind scripts are legal that an extra distinction for the type of action needs to be made such as 'accessibility' which only allows for an action that would be completed by a click to be completed with another input but nothing else. (ie a created button would be illegal if you can't already do it with a click but answering an issue with 'enter' as an input instead of a 'click' as a input is ok)

If my understanding of the proposed ruling is incorrect, please correct me

[Roavin]

Not sure if this has already been said but

Answering an issue is now a prohibited action rather than restricted action, since that can be done via the API. But don't panic: your keybind scripts for this purpose are still perfectly okay

and

Prohibited actions are:
Answering or dismissing an issue
Sending a telegram
These actions must not be performed by a script, no matter if human-initiated or not, in any case. Note that all of these actions can be performed using the API instead.

Contradict each other as keybind scripts are still scripts and would be illegal under the ruling

If keybind scripts are legal that an extra distinction for the type of action needs to be made such as 'accessibility' which only allows for an action that would be completed by a click to be completed with another input but nothing else. (ie a created button would be illegal if you can't already do it with a click but answering an issue with 'enter' as an input instead of a 'click' as a input is ok)

If my understanding of the proposed ruling is incorrect, please correct me

The above section is referring to scripts crafting their own requests. Keybinds are handled in the "Modifying Pages" section:

Your tool may offer alternate input methods (such as keybinds) to any existing page items (including prohibited ones). To qualify as an alternate input method for prohibited page items, or to buttons that perform a prohibited action, each distinct input sequence must map to one unique click location per page. For example, it’s okay to map the keys 1-4 or voice commands “one” to “four” to issue answers 1-4, but it’s not okay to make one button that programmatically decides which issue to answer and clicks the button, or to autofill a text box.

[New Astri]

In other words, Dot etc. can continue to operate as they have been.

thank FUCKING god

[Ever-Wandering Souls]

Fair ruling ("if we want to make these links illegal we should just break them" was always the most sane option regardless of whether or not you did choose to break them); glad to see it typed up; does this mean that NS-owned and (un)maintained utility NS++ is now (more??) illegal? If so, can the site just roll in the key QoL features and kill it? Should I take that question to another thread?

[Roavin]

Fair ruling ("if we want to make these links illegal we should just break them" was always the most sane option regardless of whether or not you did choose to break them); glad to see it typed up; does this mean that NS-owned and (un)maintained utility NS++ is now (more??) illegal? If so, can the site just roll in the key QoL features and kill it? Should I take that question to another thread?

Yes, NS++ questions should go into the other thread.

(I actually started typing up a reply regarding NS++' legality until it hit me. Nice. )

[Esfalsa]

The former is correct; the "Sending Requests" section is meant to address tools that craft their own requests "from scratch" (via XHR, manually adding <form> elements, or whatever else), rather than just doing a .click() on an existing NS-generated form.

I'd suspect the answer is "yes," but figured it wouldn't hurt to check — would modifying the endpoints of existing forms count as a script-crafted request? The use case might be something like sending data to the template-overall=none version of a page for performance reasons.

[Mechanocracy]

“Loading the Reports page” is marked as a restricted action, would loading the activity page also be a restricted action? I was wondering about this because they both seem to have the same function- Generating lists of happenings.

[Roavin]

I'd suspect the answer is "yes," but figured it wouldn't hurt to check — would modifying the endpoints of existing forms count as a script-crafted request? The use case might be something like sending data to the template-overall=none version of a page for performance reasons.

Yes.

EDIT: Considering this again, I'd see the basic principle of this as an extension of the following:

Note that this is an all-or-nothing situation - as soon as you introduce one button to send a restricted action, you must ensure that all possible restricted actions (including buttons that were not added by your tool but by NationStates itself!) that can be performed from the current page follow the simultaneity rule.

That might be worth amending and generalizing further.

“Loading the Reports page” is marked as a restricted action, would loading the activity page also be a restricted action? I was wondering about this because they both seem to have the same function- Generating lists of happenings.

Loading the activity page (or one of its raw pages) is not restricted, but unless you have a very specific use-case, you should use the API anyway, which gives you that data in a better-to-parse and faster format.

[Roavin]

I've updated the draft in OP with the following:

• Clarify that the "Sending Requests" section is for tool-crafted requests (as opposed to keybinds)
• Clarify how a keybind changing the page (rather than clicking an existing button) is handled
• Added the URL generation clarification

I want to try to put a bow on this soon-ish.

[Roavin]

I'm bringing this backstage now (though further comments/requests/criticism are still fine).

[Refuge Isle]

I'm bringing this backstage now (though further comments/requests/criticism are still fine).