Draft of new OSRS Script Rules

[Roavin]

Hi coders,

motivated by a number of factors (including your grievances), we have rewritten the current OSRS script rules. The rewrite isn't necessarily meant to change any of the current rules (though there are a few changes), but rather to:

• Consolidate miscellaneous rulings and guidelines made by [violet]/Eluvatar/Ballotonia over the few past years
• Provide a better framework for future rule changes as we shift more things towards the API
• Clear up cases where the rules seemed ambiguous
• Add examples where appropriate

For the most part, the rules in this draft should be equivalent to the existing rules + extraneous rulings, just that they are explained differently (and in more detail). There are a few differences, however:

• 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 option to answer).
• The act of loading the reports page is now a restricted action (use the happenings API instead). But don't panic, this doesn't affect things like Breeze++ where loading the reports page is user-initiated.
• "page=blank" is now documented.
• All tool-crafted requests (i.e. requests that are not based on an existing button on a NS page) must now identify themselves to the server. Before, this only applied to restricted actions. Most tools already do this.
• Tool-crafted user-initiated requests must send a "userclick" parameter (this has been a best practice for many years now).

The new rules are not in effect yet, because we want to hear from you first. Comments, (constructive) criticism, questions, and suggestions are all welcome and encouraged, in particular with regards to how clear and easy to understand these relatively complex rules are, and we'll be actively engaged in this thread. However, when you do post a suggestion or a criticism, note that the "why" is more important and helpful than the "what"; for example, saying "a blue sky sucks" helps nobody, but instead saying "dusk and dawn are generally considered romantic so the sky should have a red tint" is helpful.

I look forward to your responses!

Script Rules for HTML site

The rules described here apply to any kind of tool (standalone script, browser extension, custom stylesheet, etc.) that interacts with NationStates in any way that is not using the NationStates API. If it's only using the NationStates API, you're in the clear and these rules don't apply! We encourage everyone to use the API wherever possible.

Deprecation Notice

Note!! Tools that interact with the server should use the NationStates API, rather than sending commands to the HTML site.

Authors of tools that interact with the HTML site must take extreme care to follow the below rules, which are complex and subject to change. Access to the HTML site by such tools is being increasingly restricted and may be blocked altogether in the future. Before you write a script that sends requests to the HTML site, consider whether it can use the API instead, which is a safer, faster, simpler, and more reliable environment for bots.

Identifying your Tool
Identifying your tool in requests it makes to the site helps diagnose and identify issues, and also allows us to contact you if something goes wrong and give you a chance to fix it. Your tool must identify itself for any requests it creates and sends.

The identification must include the name of your tool and a way to contact you the author (main nation name, email address, and/or the URL of your website are all acceptable). If at all possible, the identification must also include the name of the user using the tool and the current version of your tool. In addition, for user-initiated requests, a UNIX timestamp (in seconds or milliseconds) of the time when the user initiated (by clicking a button or pressing a key) must be included as a URL parameter with the name "userclick".

If at all possible, your tool must identify itself by setting the User-Agent header with the relevant data. An example of how this looks HTTP-conformant way is:

Code: Select all

User-Agent: ExampleScript/1.2 (by:Testlandia; usedBy:Maxtopia)

If your environment doesn't allow you to set the User-Agent header (for example, in Chromium-based browsers), you must instead pass a URL parameter called "script" with that information. In combination with a userclick parameter, an example request URL looks something like this:

Code: Select all

https://www.nationstates.net/page=un?script=ExampleScript_1_2__by_Testlandia__usedBy_Maxtopia&userclick=1658713900823

Sending Requests
This section applies to any non-API requests your tool crafts itself and sends to NationStates, and not to keybinds etc.. When your tool sends such a request, we distinguish between manual and automatic requests, as well as between prohibited actions, restricted actions, and non-restricted actions. Each of these are governed by their own rules.

Note that your requests must identify themselves to the server; see the section "Identifying your Tool" for details.

A request is manual if and only if it is initiated by immediately responding to a user's input (mouse click or key press), at the ratio of one click to one request. You must not queue or delay performing the action (for example, to wait for a previous request to complete) in any way; you must perform the action immediately when detecting the input (such as in the appropriate callback), or not perform it at all. Anything else (including a second request sent by a user input) is considered an automatic request. Manual requests must be marked with a userclick parameter; see the section "Identifying your Tool'' for details.

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.

Restricted actions are:

• Creating a nation
• Posting a message
• Suppressing / unsuppressing a message
• Moving regions
• Endorsing / unendorsing a nation
• Banning / ejecting a nation from a region
• Anything that generates a Happenings event line in a region, the World Assembly, or a nation other than your own
• Anything that sends a request to the forums (https://forum.nationstates.net) as a logged-in user, or a forum login request
• Anything that affects a Trading Card, including placing a bid or ask, junking a card, and opening a pack
• Anything that sends a command for a NationStates special event mini-game (e.g. April Fools, N-Day, Z-Day), including NS Challenge
• Loading the Reports page

Restricted actions must only be initiated manually. For example, a tool that sends ban requests to the server at five-second intervals, regardless of user input, is executing restricted actions automatically, and is illegal. However, a tool that makes ban buttons appear on pages where they aren't normally present is legal (if all the other rules here are followed), as this requires a user's click to change anything in the gameworld.

Actions that aren't listed above and only affect your nation, such as changing its custom fields are non-restricted actions. Other actions that only scrape information are also non-restricted actions. Non-restricted actions can be performed manually or automatically.

Automatic requests are subject to a rate limit of 10 requests per minute (or one request every 6 seconds). Manual requests have no rate limit (but usually must follow simultaneity).

	Automatic	Manual
Non-restricted action	Ok (with rate limit)	Ok
Restricted action	Illegal	Ok
Prohibited action	Illegal	Illegal

A tool must not execute restricted actions simultaneously, but must instead wait for the completion of each command (that is, a complete response from the NationStates server) before issuing the next one — this is widely known as the "simultaneity rule". A tool must not spawn background processes to enable multiple simultaneous server connections that each perform a restricted action. A tool is theoretically allowed to send simultaneous non-restricted actions, but we recommend applying simultaneity universally as this makes things easier for everyone involved.

If you're working in a synchronous/imperative programming environment, simultaneity is relatively straightforward: do not have multiple threads of execution simultaneously making HTTP requests that perform restricted actions, even in response to multiple user inputs. For example, in a GUI program like an android app, it's easier to follow this rule than not to. However, as soon as you're working with asynchronicity in any fashion (multiple threads, or using a language's asynchronous features like async/await in Javascript or C#, or generally working with an asynchronous HTTP interface such as XMLHttpRequest or fetch() in the browser), this can be tricky, and you must take great care to not violate this rule. If you're unsure, you could use Wireshark or a similar network analysis tool to make sure your tool is above board.

If your tool runs in the browser, the section "Modifying Pages" has additional guidance on how to best handle simultaneity.

Modifying Pages
You're free to write and use tools that modify what NationStates pages look like, with few exceptions.

For the most part, prohibited page items are entirely off-limits to tools. These are:

• The telegrams user interface, e.g. page=telegram, page=compose_telegram, anything within <div id="tgcompose"></div> on a nation page, or any other place from which a telegram can be sent.
• The "Getting Help" interface
• The NationStates Shop

Note that this list may be expanded in the future. We will give ample notice if this happens.

Your tool may freely customize everything that affects the look (but not the layout) of any NationStates page (including prohibited page items). This includes fonts, colors, margins, paddings, borders, and more. Note, however, that we don't make any assurances (beyond those explicitly listed in these rules) about the format and markup of any part of the site, and they can change at any time without any notice.

Your tool may adjust the layout of existing NationStates page items, or augment existing page items with new elements, or auto-fill existing form elements, with some restrictions:

• Any prohibited page item may not be modified in any fashion.
• If NationStates itself creates multiple buttons that allow the user to perform restricted actions, you must not relayout these buttons in a way that allows faster clicking unless you also follow the simultaneity rule. See below for details.

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.

Your tool may add links, buttons, or alternate input methods (e.g. keybinds) pointing to other NationStates pages. Such a button may not perform a prohibited action in any case. If such a button performs a restricted action, clicking it must abide by the simultaneity rule. 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.

If your tool wants to create its own pages, it can use https://www.nationstates.net/page=blank. This opens a blank page that includes the side and header bars, and your tool can inject its content into <div id="content"> within that. We expect that this URL will remain stable for the foreseeable future. Note that NationStates ignores any additional URL parameters for this page, so you can freely use those to distinguish between different pages of your tool; we recommend that you include the name of your script in the URL, for us to track it and for different tools not interfering with each other. For example, you could generate and use links to https://www.nationstates.net/page=blank ... t/settings and https://www.nationstates.net/page=blank ... =something, and your tool then parses this URL (window.location.href in Javascript) to display the appropriate page to the user.

Handling Simultaneity
Specifically in the context of a tool that runs in the browser, special care has to be taken to follow the simultaneity rule. A proven method of doing this involves disabling all form buttons in the button onclick handler, and reenabling them when the request has completed. The correct time depends on how your tool operates:

• If your tool lets the browser handle the form submission, don't reenable buttons at all, since a full page load will be initiated.
• When using XMLHttpRequest, either the loadend callback can be used, or the readystatechange callback with readyState == 4 (DONE).
• When using jQuery, the complete callback function passed to jQuery.ajax or jQuery.post is called at the correct time and can be used to re-enable buttons.
• When using Fetch API, buttons can be re-enabled once the Promise returned from one of the Response object's methods (such as text()) is resolved.
• For other methods, consult the corresponding documentation to know when an issued request is fully completed.

To disable/enable form buttons, the following snippets (using jQuery) can be used.

Code: Select all

$('form input[type="submit"], form button').attr("disabled", true).addClass("disabledForSimultaneity");

Code: Select all

 $('.disabledForSimultaneity').removeAttr("disabled").removeClass("disabledForSimultaneity");

Miscellaneous

It is illegal to distribute a tool that breaks game rules when used in its primary, default, or intended manner. For details on how we deal with tools that violate these rules, see this post.

Rate limits and simultaneity handling apply to a tool only within its operating domain and the confines of its possibilities. For example, a Greasemonkey script, a browser extension with only a content script, or a user stylesheet only operate within one tab and can't worry about following simultaneity or the rate limit in other tabs. Similarly, a browser extension (with a background script) has access to multiple tabs and needs to ensure that the rate limit is followed across all tabs it operates in; it cannot (and need not) concern itself with tabs in other browsers, or tabs in the same browser it does not have access to through security measures in the browser. Standalone tools aren't responsible for what other unrelated tools do on the same computer. Users of your tool should be made aware that taking advantage of this (for example, by running your otherwise legal auto-refreshing tool in 100 browser tabs, or starting a standalone scraper tool 100 times) may lead to punishment.

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.

NationStates offers an API, which provides a faster, more efficient interface for many scripts. It is governed by its own rules; these Script Rules don't apply to any API request. It is a much more bot-friendly environment, with far higher rate limits, and there are some things that can only be legally done via the API. You should, if at all possible, choose the API over the regular HTML site.

[The King Isle]

Would we still be able to use autologin scripts such as NS++?

[Esfalsa]

Forgive me if I'm missing something, but I'm still a little unclear on what counts as a tool-crafted request with respect to keybinding scripts. I know you describe them as…

requests that are not based on an existing button on a NS page

…but the draft rules themselves seem to just reference sending…

a (non-API) request to the NationStates server

…as being tool-crafted.

In particular, I'm curious where this leaves keybinding scripts. Tools like Breeze++ or Feather trigger click events on existing buttons/links for some keybinds, but they also make use of setting window.location.href or calling window.location.assign(). Under these new rules, would these now count as tool-crafted requests and thus require user agent and userclick information? Would they have to prevent, for instance, responding to keyboard inputs after redirecting the user in order to follow the simultaneity rule?

More generally speaking, when does opening a page count as a tool-crafted response? For example, let's say I've been chatting with another player and want to check out their nation(s). There's a few ways I could do this, some very obviously manual, others less so:

• Entering "nationstates.net/testlandia" into my browser's address bar.
• Clicking a link to "https://www.nationstates.net/testlandia" from an instant messenger.
• Clicking a link generated by a tool. For instance, we're chatting on Discord and I decide to type in something like "!nation testlandia" and a Discord bot generates a response that includes a link to https://www.nationstates.net/testlandia. Then I decide to check out their nation further, so I click the link.
• Using a keybind to open a link from a spreadsheet. Let's say this player is just getting into R/D gameplay, has just made a bunch of puppets, and wants me to check if they're all properly prepped, that is, applied to the WA and in the correct jump point. (Yes, I know this can be done through the API so bear with me for a moment.) They list all their puppets in a Google Sheet and send it to me. I open the spreadsheet, click on a cell with a link, and hit option+enter on my keyboard to open it.
• Using a keybind to open multiple links from a spreadsheet. Let's say I want to be a little more efficient. Instead of opening one link at a time, I open multiple, by selecting a range of cells and hitting option+enter. Maybe these links are even generated using the spreadsheet as a tool, e.g. by interpolating cell values if the puppet names follow a numerical sequence.

Which, if any, of these would count as a tool-crafted request?

---

When using Fetch API, buttons can be re-enabled once the Promise returned from one of the Response object's methods (such as text()) is resolved.[/quote]

Minor nitpick, but I don't think waiting for one of the Response object's methods is necessary? According to MDN:

The global fetch() method starts the process of fetching a resource from the network, returning a promise which is fulfilled once the response is available.

The way I would understand that would be that waiting for the Promise returned by fetch() to resolve would be sufficient. This would be useful for something where, perhaps, I want to POST some data to the server and am more interested in the speed of my tool between requests than I am in actually reading the server response.

[Window Land]

Would we still be able to use autologin scripts such as NS++?

Autologin scripts should be operating over the API already, so they should be fine.

[Roavin]

Would we still be able to use autologin scripts such as NS++?

Yes! Autologin tools generally use the API these days, and nothing changes for them.

Forgive me if I'm missing something, but I'm still a little unclear on what counts as a tool-crafted request with respect to keybinding scripts. I know you describe them as…

requests that are not based on an existing button on a NS page

…but the draft rules themselves seem to just reference sending…

a (non-API) request to the NationStates server

…as being tool-crafted.

Good catch. 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.

In particular, I'm curious where this leaves keybinding scripts. Tools like Breeze++ or Feather trigger click events on existing buttons/links for some keybinds, but they also make use of setting window.location.href or calling window.location.assign(). Under these new rules, would these now count as tool-crafted requests and thus require user agent and userclick information? Would they have to prevent, for instance, responding to keyboard inputs after redirecting the user in order to follow the simultaneity rule?

Ah, no. They're functionally equivalent to "Your tool may add links and buttons to other NationStates pages" (or clicking a bookmark or such). I'll add that in explicitly. Another good catch!

More generally speaking, when does opening a page count as a tool-crafted response? For example, let's say I've been chatting with another player and want to check out their nation(s). There's a few ways I could do this, some very obviously manual, others less so:
[snip]

None of them; see above.

Minor nitpick, but I don't think waiting for one of the Response object's methods is necessary? According to MDN:

The way I would understand that would be that waiting for the Promise returned by fetch() to resolve would be sufficient. This would be useful for something where, perhaps, I want to POST some data to the server and am more interested in the speed of my tool between requests than I am in actually reading the server response.

The rule is "a complete response from the NationStates server". Only awaiting the fetch() itself doesn't necessarily give you the complete response, but only needs to give you the response headers. The Response object's body-methods (json(), text(), etc.) all return a Promise for that reason.

Quoth MDN:

The fetch() method takes one mandatory argument, the path to the resource you want to fetch. It returns a Promise that resolves to the Response to that request — as soon as the server responds with headers

[Refuge Isle]

Hello.

Your tool may adjust the layout of existing NationStates page items, or augment existing page items with new elements, or auto-fill existing form elements, with some restrictions:

[*]Any prohibited page item may not be modified in any fashion.

For the most part, prohibited page items are entirely off-limits to tools. These are:

[*]The telegrams user interface, e.g. page=telegram

You guys have initiated two discussions on this topic, where it has repeatedly and overwhelmingly been responded to by the NationStates community, with evidence and personal testimony, that the current situation with recruitment, which ostensibly can only be credibly be carried out by telegram, relies on third party tools to be easy and accessible to users. These accessibilities include opening recruitment up to mobile users, people with visual and processing disabilities, as well as letting the NS' most active users recruit people to their active regions for better retention on the site, without driving the recruiters mad with splitting headaches.

One of my long-form responses previously: viewtopic.php?p=40012275#p40012275

I guess my question is why the feedback in those threads is 100% ignored and cast aside, along with their credible and constructive counter-suggestions for how to build a more accessible NationStates? Why do we need to continually have these arguments again and again? Why are we punishing users who rely on these tools, as well as punishing the developers who want to make any type of tool that makes the site more pleasant than shooting a nail through your eye? What is the point of this thread if the last two have been discarded?

[SherpDaWerp]

so long as they don't programmatically decide which issue to answer
...
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.

This reads like a new prohibition on random-choice issues answering scripts (which are, IIRC, still commonplace) in favour of always-choose-option-N. Is that interpretation correct?

[Roavin]

I guess my question is why the feedback in those threads is 100% ignored and cast aside

Short story: They haven't.

Long story: These are separate processes. The first thread is [v]'s announcement that she plans to make that change to the script rules; it hasn't been enacted so far and since we're doing the rewrite, the prospective change has been rolled into this draft. The second thread is about how to deal with that change when/if it comes. As it stands as of right this second, the change is on track to become part of the rules whenever this draft goes live, but if it's decided to not enact this rule change afterall (and there is an open discussion on this internally), it'll be reflected here accordingly.

so long as they don't programmatically decide which issue to answer
...
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.

This reads like a new prohibition on random-choice issues answering scripts (which are, IIRC, still commonplace) in favour of always-choose-option-N. Is that interpretation correct?

Kinda-but-not-really new. It's new in relation to the current rules, but not new as it's a consequence of the prior announced (but not yet enacted) rules change from [v] here. That change makes answering issues a prohibited action, rather than a restricted one, since there has been a stable API endpoint for answering issues for quite some time now. With this new draft, doing keybinds there anyway is explicitly allowed (that would have been a very murky grey-area before).

[Esfalsa]

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.

They're functionally equivalent to "Your tool may add links and buttons to other NationStates pages" (or clicking a bookmark or such). I'll add that in explicitly.

Makes sense. Thanks for clearing these up!

The rule is "a complete response from the NationStates server". Only awaiting the fetch() itself doesn't necessarily give you the complete response, but only needs to give you the response headers. The Response object's body-methods (json(), text(), etc.) all return a Promise for that reason.

Quoth MDN:

The fetch() method takes one mandatory argument, the path to the resource you want to fetch. It returns a Promise that resolves to the Response to that request — as soon as the server responds with headers

I stand corrected then — thanks for pointing that out.

[SherpDaWerp]

not new as it's a consequence of the prior announced (but not yet enacted) rules change from [v] here. That change makes answering issues a prohibited action, rather than a restricted one

From where I'm standing, I can see how [v]'s rule change implied that issues couldn't be randomly chosen, but that was not clear in the slightest. Creating an array of "issue answer buttons" and randomly choosing which one to .click() on keybind activation is a fair world away from "pre-filling forms".

In any case, it's clarified under this ruleset, so we're all on the same page now, which is nice.

[Trotterdam]

Could we make "template-overall=none" officially documented, too?

[Comfed]

Not sure why the telegram rule is still even under consideration when it has already been shown what a bad idea it is.

[Quebecshire]

I will post in more detail later - in the meantime I echo Luca and Comfed's comments. After two exhaustive threads with textwalls, data, and testimony, in addition to the technical difficulties of enforcement, why is the telegram rule still being considered?

EDIT:

More specifically, what has changed since Aav said "Please note this post, I am disinclined to continue with this line of discussion without compelling reason. (10/8/22)"?

[Tim-Opolis]

I'll attempt to summon the energy to make a more long-form post later, but I echo the well-reasoned sentiments of Luca et al regarding the "telegram rule"

Given the overwhelming sentiment regarding it, and the bounty of arguments made on it, if Admin is going to force it down our throats anyway then they should just say it instead of this performative "we're listening". To nonsense. To be perfectly blunt, I don't have any faith or trust in a "internal discussion". The takes we've seen from those who are "internal" have evidenced beyond a reasonable doubt that site staff (not counting some recent tech appointees) basically have no grasp of modern regionbuilding. If the plan is to just squeeze more stamps out of people, just say it, instead of playing around with this nonsensical song and dance where we keep receiving false hope.

[Ever-Wandering Souls]

Posting a message

Does this not conflict with the RMB API interface that, as far as I know, is still running in encouraged beta, and allows for automated RMB posting, despite last I checked being unlisted in the API documentation?

Or is that blanket excluded, because it's via the API?
Edit: Yeah it should be, my bad, "when your tool sends a (non-API) request to the NationStates server, we distinguish..."

---

I quite like some aspects of this, such as the easy-to-interpret table about restricted vs prohibited. Very clear.

In case it helps the team at all, Zizou collected a variety of rulings and clarifications given over the years too, here: viewtopic.php?f=15&t=516753#p39458048

Ideally as many of those things would be included here as possible; it seems like some already are, such as clarifications no keybinds. Overall, I think this is a very clear improvement and I appreciate the work put into collecting things in one place and refining how it is present! =)

[Varanius]

I mean I am genuinely a little confused as to the telegram discussion. Is there any benefit to the site infrastructure or political meta? I’m obviously not a coder, but I’ve yet to see any particularly convincing arguments as to why this change should be enacted. What I certainly have seen though, is a plethora of community members requesting that moderation not enact something like this, and they do actually seem to have reasons. Nationstates is, frankly, underwhelming in terms of actual design. From manual recruitment, to card farming, to chasing, a number of communities on NS have made up for the lack of site infrastructure with scripts. Scripts that make it significantly easier for wider audiences to actually participate in the game. What the site has lacked, the users have delivered. So why ban these scripts? I mean really, they seem to be purely tools of convenience with no obvious downsides, certainly not any that the moderators have informed the community about.

[Zukchiva]

Manual recruitment is exceedingly difficult to the point where few people have the time, willpower, or both to do it. Telegram scripts make manual recruitment tolerable and more accessible - thus allowing more regions to recruit without having to spend monetary resources they may not have on stamps. Removal of telegram scripts without an accompanying fix to recruitment will force regions who rely on those scripts for recruitment to either pay for stamps or die.

It's exceedingly disappointing to see that prohibition of telegram scripts is even being considered after two threads of extensive community input against the prohibition.

[Altys]

I'll continue the echo chamber regarding telegrams. Coming from a region (Thaecia) which extensively relies on manual recruitment due to simply being unable to afford stamps, I can only read this, as Zuk put it, as a move to kill UCRs in a similar situation as us. Coming from an admin team who went out of their way to find a system aiming to reduce the size of Feeders, I too fail to understand the reasoning. Is the goal to force players to rely on the site's own infrastructures? It's clear it favours Feeders by design due to how tedious and time-consuming it is to manually recruit without any assistance. And you can't squeeze stampts out of people who don't have the money either.

If scripts exist in an area there's a reason for it. When this specific area goes the way the admins want it to and doesn't seem to raise huge concerns, why removing it? It's obvious UCRs thrive thanks to these. And when they do, the gap between UCRs and the Feeders narrows. And even then a minority of big UCRs are only capable of sometimes beating them in terms of active dedicated members (number of voters in elections, number of updaters/pilers in an operation, etc.) and not pure numbers (which also translate into the capacity to get more active and dedicated members).

[Roavin]

(Not relevant anymore, see this post instead)

Regarding manual telegram recruitment:

The "autofill" method used by Dot and other tools is not illegal today, won't be illegal tomorrow, and there is an open staff-internal discussion about whether it will be implemented or not. Your concerns from prior threads have been heard loud and clear and have not been ignored. There's no need to voice your support for autofill here or to disable Dot at this time.

"Ok, Roavin, but why is the rules change here?" — this is simply because this is an overarching effort that includes prior planned changes; the particular change regarding autofill has remained on the list of planned changes since the internal discussion has not yet concluded.

If you have purely technical reasons about the autofill clause in the above draft, they belong in this thread. But if it's about the functional aspects of autofill as it pertains to manual telegram recruitment, it should go in this thread.

[Roavin]

Could we make "template-overall=none" officially documented, too?

I'm disinclined to do this because documenting it means supporting it. "page=blank" is "free", in the sense that it's reusing the existing layout code and simply not filling in any content. "template-overall=none", however, already breaks on several pages where there is a reliance on Javascript or the side/top bars, and supporting it would mean spending valuable admin time going through all pages and making sure those don't break if, say, jQuery isn't there, or #panelcontent isn't there, or whatnot.

"template-overall=none" is, as far as I know, used by players for two things. One, it's used by some content scripts to get a "cleaner" NS that can then be themed by the content script. Given that the no-template page breaks some things already, it'd be better to offer ways for such content scripts to do so on the regular page and/or do what those content scripts do on the site itself. And two, it's used by R/Ders to get faster pageloads, and in this case, it'd be better to make everything faster instead (and there are real possibilities for improvement), and I can speak from experience (as an R/Der with less-than-stellar page load times myself) that R/Ders can quickly adapt when something breaks.

Posting a message

Does this not conflict with the RMB API interface that, as far as I know, is still running in encouraged beta, and allows for automated RMB posting, despite last I checked being unlisted in the API documentation?

Or is that blanket excluded, because it's via the API?
Edit: Yeah it should be, my bad, "when your tool sends a (non-API) request to the NationStates server, we distinguish..."

Yep, your edit is correct. Though we really should be documenting that undocumented endpoint at this point.

I quite like some aspects of this, such as the easy-to-interpret table about restricted vs prohibited. Very clear.

In case it helps the team at all, Zizou collected a variety of rulings and clarifications given over the years too, here: viewtopic.php?f=15&t=516753#p39458048

Ideally as many of those things would be included here as possible; it seems like some already are, such as clarifications no keybinds. Overall, I think this is a very clear improvement and I appreciate the work put into collecting things in one place and refining how it is present! =)

That thread (both your OP and Zizou's additions) have been helpful in the first step when we tried to gather all these extraneous rulings in the first place (and I hope we didn't miss anything major), so thank you for that! I think anything in there that pertains to non-API requests should be implicitly or explicitly covered in this draft. At first glance, I'm not seeing anything that was forgotten.

[Trotterdam]

"template-overall=none" is, as far as I know, used by players for two things. One, it's used by some content scripts to get a "cleaner" NS that can then be themed by the content script. Given that the no-template page breaks some things already, it'd be better to offer ways for such content scripts to do so on the regular page and/or do what those content scripts do on the site itself. And two, it's used by R/Ders to get faster pageloads, and in this case, it'd be better to make everything faster instead (and there are real possibilities for improvement), and I can speak from experience (as an R/Der with less-than-stellar page load times myself) that R/Ders can quickly adapt when something breaks.

Umm, no. The main use case for template-overall=none, or at least the main reason I'd use it, is for faster and cleaner retrieval of data by non-interactive scripts that will never directly render the retrieved page on-screen.

[Roavin]

"template-overall=none" is, as far as I know, used by players for two things. One, it's used by some content scripts to get a "cleaner" NS that can then be themed by the content script. Given that the no-template page breaks some things already, it'd be better to offer ways for such content scripts to do so on the regular page and/or do what those content scripts do on the site itself. And two, it's used by R/Ders to get faster pageloads, and in this case, it'd be better to make everything faster instead (and there are real possibilities for improvement), and I can speak from experience (as an R/Der with less-than-stellar page load times myself) that R/Ders can quickly adapt when something breaks.

Umm, no. The main use case for template-overall=none, or at least the main reason I'd use it, is for faster and cleaner retrieval of data by non-interactive scripts that will never directly render the retrieved page on-screen.

In that case, you should absolutely use the API and/or daily data dumps instead. If there's an endpoint you're missing, let us know and we'll try our best to accomodate it — and most likely, whatever you need is already available via the API, in a way that's faster, better to parse, less subject to random breakage, etc.etc.etc.

[Fauzjhia]

The legality of Got issues

Hello

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.

Its use links like: https://www.nationstates.net/page=enact ... tmode=true, to generate a button that can be used to answer issues.

using API to get issues options

The HTML site created by Got Issues

Of course, it is made to be used with Firefox containers.

edit : if you need link, I can provide it, but I am not the author of this script.
I simply want to know its potential legality under new rules

[Quebecshire]

I have a couple things I want to seek clarity on after your post, Roavin. I'm not sure if they are best suited to this thread or the other one, so I'll just reply here. Apologies in advance if you need to move it, etc.

Regarding manual telegram recruitment:

The "autofill" method used by Dot and other tools is not illegal today, won't be illegal tomorrow, and there is an open staff-internal discussion about whether it will be implemented or not. Your concerns from prior threads have been heard loud and clear and have not been ignored. There's no need to voice your support for autofill here or to disable Dot at this time.

While it isn't illegal today and won't be tomorrow, it very well may be in the future under your current rules draft. Naturally that is going to invite responses and criticism. I think the reason so many people came here to voice their concerns is because there are a lot of people and communities this change would negatively impact, it's not a technical or language quirk we only need one person to point out before moving on.

"Ok, Roavin, but why is the rules change here?" — this is simply because this is an overarching effort that includes prior planned changes; the particular change regarding autofill has remained on the list of planned changes since the internal discussion has not yet concluded.

Two questions regarding this,

• 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.
  
• 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.

If you have purely technical reasons about the autofill clause in the above draft, they belong in this thread. But if it's about the functional aspects of autofill as it pertains to manual telegram recruitment (and it's a new argument not made before), it should go in this thread.

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.

Once again, apologies if this post is in the wrong place. Thank you in advance for your time, and hopefully for your responses.

[Jewish Underground State]

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.