Change to Script Rules for HTML Site

[Yuts Knenxland]

To put out a suggestion - what if the stamped telegram queue were cut off after the [first hour] of a nation's founding?
That way, some stamps get through, but are severely limited by the [1h] limit that stamps can get through, which places more emphasis on API and Manual.

But wouldn't that negate the whole non-recruitment campaign stamps thing? If you cut off the stamp queue at some point for the nation, then you arbitrarily have to pick a day when they can again receive them. That seems like a messy solution, at best. It would be easier (and far more effective) to increase the price of stamps overall. I don't see how increasing said price could prohibit people from using them, it would just make them think twice about how they use them. Perhaps it would help with the rampant poaching going on in the world.

I think you may be overcomplicating it a teeny bit. I don't exactly know how the stamp queue works, but I would imagine that all those with stamps are immediately placed in that queue the moment a new nation is founded. API slowly lines up after waiting for their 3m cooldown, and manual does a quick surge with all those who are hanging out on the founds page.

After a period of initial competition, I would imagine that manual clears out, because no one really wants to send to a nation founded several hours ago. That leaves the competition between API and Stamp queues. If API is as slow as what everyone is saying, API would clear sooner than being replenished, leaving the stamp queue to send out uncontested over the next few hours - up to a day.

For those that clear their inbox regularly, hoping to find a new region, they'll just be met with floods of (mostly) stamped ones towards the end.
By placing a time limit on when the stamp queue is in operation, it would nerf stamps severely, so as to speak.

As for picking a day that they can receive them, I don't think that's needed. The stopped queue would mean that the telegram didn't go through, equivalent to it not being sent at all. It would be a complete wiping out of the queue at that point of time, no continuations at a later date. If someone decides to send to "All in the east pacific" after not making it within that [1 hour], the telegram will still go through.

Regarding how increasing the price of stamps prohibiting people from using them, it definitely wouldn't prohibit them, but it would definitely make it more costly to even think about using stamps for anything. In my opinion, higher cost isn't a good thing. But if it has to be done, then perhaps instead of increasing the price of stamps across the board, make recruitment cost 2 stamps per nation.
That way, WA proposals, joke "all" telegrams can still pass through without having to worry about the increase in cost.

Finally, regarding poaching - I'm not sure about you, but the only poaching I see going on is ol declansburg manually sending to everyone. Very impressed by their stamina. Don't see folks wasting stamps to go around poaching. Oh maybe if you want to telegram an entire region you don't like perhaps.

My only stance on poaching is that if you have your recruitment preferences on, you're open to recruitment

Hope this clears up some stuff on what I'm thinking about.

[Bassiliya]

Fair enough. Not sure I really understand the purpose of the 1 hour block of time thing, but I'm willing to take your word for it.

Regarding how increasing the price of stamps prohibiting people from using them, it definitely wouldn't prohibit them, but it would definitely make it more costly to even think about using stamps for anything

Yeah, see, I don't see that as a bad thing at all. If your message is that important, you'll spend the stamps on it. If it's not, then you won't. But that might just be my personal preference speaking.

Finally, regarding poaching - I'm not sure about you, but the only poaching I see going on is ol declansburg manually sending to everyone. Very impressed by their stamina. Don't see folks wasting stamps to go around poaching.

I know a number of other regions have done similar things in the past and most likely will in the future. Just because no one is doing it right this second doesn't mean it is not something to be addressed. Recruitment on or not, poaching is poaching, no matter how you look at it.

[Leutria]

I just wanted to say I recruit 100% manually and yet regularity hit the "To prevent spam, you cannot wire a message so soon after your last one. Please try again in a few moments." I use a template so I am just pasting the template code, and get nations off the activity page. Often you get a burst of new nations (or I let my attention wander for a moment) and I have several new ones, so I open each in a new tab. Then as I go to past and send each (scroll down the page, click write telegram, click the message field, ctrl+v, click send, check if it actually sent, close tab, repeat (it puts me on the next opened tab automatically). When I do this, I almost always keep hitting that cool down even though I am completely manual using only site-provided tools.


Edit: Anyway, what is my point? I guess these tools might make manual recruitment easier, but with practice the site itself provides tools letting you recruit almost as fast (the only times I have not been able to keep up with the activity page were some of the events where we were getting a flood of new nations). Plus, that cooldown can really break your flow, I know I have closed the tab and then had to remember which nation that meant I missed. Quite a pain.

[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. What will happen to them? Will they just be told, "well, tough luck, but you can't recruit anymore"? I'm sure there are some communities where the active recruiters are only mobile-only users that rely on public systems like the ones created by Refuge Isle. Are they going to just have to watch their communities fall apart?

[Vylixan]

Hello all,

[box]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

So, I still don't really get what is legal and not under this new rules regarding answering issues. I'm trying to determine what existing scripts are still legal under the new rules, and what changes to those scripts might make them legal again.
So therefore I have some questions:

- Is it still legal to use a script to select one of the issue answer buttons for you, that then gets submitted when the user hits a keyboard or mouse key? Or does it need one action for the selection and one for the submitting?
- Is it still legal to craft a HTML page on your local system that directly links to an issue a nation has.
- Is it still legal to craft a HTML page on your local system that directly links to the issue overview page of a nation.
- Is it still legal to use the API to find what issues a nation currently has and use that information to craft an HTML page on a local system linking to those issues on that nation
- Is it still legal to use the url part "template-overall=none" to minimize the page size when linking to an issue page on a nation
- Is it still legal to use the url part "template-overall=none" to minimize the page size when linking to the issues overview page on a nation
- Is it still legal to use a script that automatically closes the issue page after an issue is answered
- Is it still legal to use a script that automatically closes the issues page after all issues are answered
- Is it still legal to use a script to minimize the issue page on a nation to just the buttons and nothing else
- Is it still legal to use a script that opens a card pack after answering an issues by selecting the open pack button after answering and submitting that button when the user hits a keyboard or mouse key?

[Racoda]

Full support for Vylixan's concerns – depending on where the line is drawn, the new rules may either fully ban any existing card farming meta or only require tweaks to make the process closer to standard site interaction (with keybinds), as it was before "pregenerated-single-link-answering" appeared.

As a side note, going as far as prohibiting keybinds whilst still allowing style changes to an issue page (ie. leaving only the buttons and moving them to the top) wouldn't be *that* different from keybinds - you'd just need to keep the cursor in one place and click using the mouse instead of the keyboard.

[Markanite]

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?

[Sandaoguo]

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

I have a question regarding this, especially since endorsements are covered as a permitted but "restricted" action. Every endorsement tool that isn't just giving a list of nations operates by generating a URL that includes "pre-filled" form data. To put it in coding terms, these scripts generate a variable like this:

Code: Select all

var endorseURL = "https://nationstates.net/cgi-bin/endorse.cgi?nation=" + element + "&localid=" + localid + "&action=endorse";

nation and localid are technically form fields (albeit hidden) that get passed to the endorse.cgi script when clicking the Endorse button a nation page. Endorsement scripts work by generating this URL to click directly, bypassing the form. And they only work because endorse.cgi accepts GET data and not just POST data. If it's not considered pre-filling a form field, is it considered "auto-generating HTML links containing embedded information"? I'm not sure how far you're taking 'embedded information' here.

Is that interacting with the HTML site during the execution of the action (endorsing)? I've been using some variation of a script like that for at least the past 6 years, as have many others. Scripts like these have never been previously considered illegal, have had their source codes shared here over the years, had admin input, etc. But with this change, even though all the examples seem to be targeted at sending telegrams, there are other ways scripts "interact" with form fields on NS that just aren't obviously visible.

[[violet]]

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

[[violet]]

All the questions below are written in present tense, but for clarity, note we're discussing proposed rule changes for the future, NOT the current situation today.

- Is it still legal to use a script to select one of the issue answer buttons for you, that then gets submitted when the user hits a keyboard or mouse key? Or does it need one action for the selection and one for the submitting?

I'm not sure what you mean by "selecting" an issue... I can't think of what action that is. But bots would be prohibited from interacting with the HTML version of the issues page in any way, while remaining free to read / answer issues via the API.

- Is it still legal to craft a HTML page on your local system that directly links to an issue a nation has.
- Is it still legal to craft a HTML page on your local system that directly links to the issue overview page of a nation.

You're referring to a situation where a bot generates HTML pages? If so, it's free to generate regular links, but not specially crafted URLs that contain a payload to be executed upon page load.

- Is it still legal to use the API to find what issues a nation currently has and use that information to craft an HTML page on a local system linking to those issues on that nation

Yes, assuming these are simple links to individual issues.

- Is it still legal to use the url part "template-overall=none" to minimize the page size when linking to an issue page on a nation
- Is it still legal to use the url part "template-overall=none" to minimize the page size when linking to the issues overview page on a nation

Yes, as this is a regular URL, with no payload that will trigger interaction.

- Is it still legal to use a script that automatically closes the issue page after an issue is answered
- Is it still legal to use a script that automatically closes the issues page after all issues are answered
- Is it still legal to use a script to minimize the issue page on a nation to just the buttons and nothing else

No, as all of these scenarios involve a script interacting with the HTML issues page.

- Is it still legal to use a script that opens a card pack after answering an issues by selecting the open pack button after answering and submitting that button when the user hits a keyboard or mouse key?

I'm not 100% sure I understand the precise order of events here. Opening a pack is a "restricted action," which means bots aren't permitted to do it by themselves. They are permitted to transmit the command on behalf of a user, in the same manner as all restricted actions.

[[violet]]

Is that interacting with the HTML site during the execution of the action (endorsing)? I've been using some variation of a script like that for at least the past 6 years, as have many others. Scripts like these have never been previously considered illegal, have had their source codes shared here over the years, had admin input, etc. But with this change, even though all the examples seem to be targeted at sending telegrams, there are other ways scripts "interact" with form fields on NS that just aren't obviously visible.

It's not relevant whether an endorsement script is considered to be interacting with the HTML site, because an endo isn't a prohibited action. Only sending telegrams and answering issues are listed as prohibited actions, which is why the discussion above is centering around them.

Endorsements are restricted actions, which means scripts aren't allowed to do them with no human input. (And they must also abide by a bunch of other HTML site-specific rules.) But they are permitted to interact with the HTML site.

[[violet]]

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.

[Sandaoguo]

Is that interacting with the HTML site during the execution of the action (endorsing)? I've been using some variation of a script like that for at least the past 6 years, as have many others. Scripts like these have never been previously considered illegal, have had their source codes shared here over the years, had admin input, etc. But with this change, even though all the examples seem to be targeted at sending telegrams, there are other ways scripts "interact" with form fields on NS that just aren't obviously visible.

It's not relevant whether an endorsement script is considered to be interacting with the HTML site, because an endo isn't a prohibited action. Only sending telegrams and answering issues are listed as prohibited actions, which is why the discussion above is centering around them.

Can this be made explicit, in that case? The proposed rule only gives TGs as an example of "interacting with the HTML site in any way during the execution of an action," not as the only thing being prohibited. There's a lot of confusion because admins are only talking about TGs, but the proposed language is far broader than you seem to be intending.

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:

A tool may never perform or assist in a "prohibited action" via the HTML site. Tools may not directly take action nor provide assistance or semi-automation in performing a prohibited action. Prohibited actions are:

• sending a telegram
• answering / dismissing an issue

[[violet]]

Can this be made explicit, in that case? The proposed rule only gives TGs as an example of "interacting with the HTML site in any way during the execution of an action," not as the only thing being prohibited.

The proposed rule specifically says "Prohibited actions are:" and lists two things. I think that is explicit. It doesn't say "for example" or "including" those things.

Your changes seem to make more ambiguous, as they remove the part about URLs that pre-fill form fields -- which is the key change -- while introducing new terms like "semi-automation", "assistance" without defining them.

[Racoda]

All the questions below are written in present tense, but for clarity, note we're discussing proposed rule changes for the future, NOT the current situation today.

- Is it still legal to use a script to select one of the issue answer buttons for you, that then gets submitted when the user hits a keyboard or mouse key? Or does it need one action for the selection and one for the submitting?

I'm not sure what you mean by "selecting" an issue... I can't think of what action that is. But bots would be prohibited from interacting with the HTML version of the issues page in any way, while remaining free to read / answer issues via the API.

Presumably keybinds.

---

- Is it still legal to use a script that automatically closes the issue page after an issue is answered
- Is it still legal to use a script that automatically closes the issues page after all issues are answered
- Is it still legal to use a script to minimize the issue page on a nation to just the buttons and nothing else

No, as all of these scenarios involve a script interacting with the HTML issues page.

Farmers at increased risk of RSI.

Well, at least opening

Code: Select all

https://www.nationstates.net/page=show_dilemma/dilemma=${issue_id}/template-overall=none

and pressing Tab-Tab-Enter will still be legal. Of course that always selects the first option
I think it would be good to finally decouple cards from issues, but these rule changes point in the opposite direction...

---

- Is it still legal to use a script to minimize the issue page on a nation to just the buttons and nothing else

No, as all of these scenarios involve a script interacting with the HTML issues page.

So CSS modification is prohibited iff it changes the way one would answer an issue (ie. changes how much one has to scroll, or Tab twice as mentioned above) or just completely prohibited in general?
To make it clearer, here's an example of such a script – which both modifies the CSS and adds a keybind to answer an issue: https://github.com/dithpri/RCES/blob/ma ... nd.user.js
As I understand it, the keybind would be prohibited, what about the CSS?
Which leads back to this:

As a side note, going as far as prohibiting keybinds whilst still allowing style changes to an issue page (ie. leaving only the buttons and moving them to the top) wouldn't be *that* different from keybinds - you'd just need to keep the cursor in one place and click using the mouse instead of the keyboard.

Edit (zoom idea courtesy of Seanat):
Turns out this is even trivially easy to do without any CSS modifications: maximally zoom out the page. The issue/option text won't have to wrap, which means the Accept buttons will always be in the same position. So, you can still just keep your mouse hovered in one spot. Which is exactly what CSS modifications would do.
Hell, you could even bind your mouse button to also simulate pressing enter and only then a mouse click (order important). You click on the Accept box (enter is sent to the page as well, but it does nothing since nothing is selected), issue answered. On other pages (edit for clarity: non-issue pages), a mouse press sends enter, a preselected button is submitted. So we're back to mashing a single button, and everything works exactly the same as before, we've just switched the keybind/mousebind stack around.

---

- Is it still legal to use a script that automatically closes the issue page after an issue is answered
- Is it still legal to use a script that automatically closes the issues page after all issues are answered
- Is it still legal to use a script to minimize the issue page on a nation to just the buttons and nothing else

No, as all of these scenarios involve a script interacting with the HTML issues page.

- Is it still legal to use a script that opens a card pack after answering an issues by selecting the open pack button after answering and submitting that button when the user hits a keyboard or mouse key?

I'm not 100% sure I understand the precise order of events here. Opening a pack is a "restricted action," which means bots aren't permitted to do it by themselves. They are permitted to transmit the command on behalf of a user, in the same manner as all restricted actions.

To follow up on the questions, am I correct in understanding that when answering an issue and being redirected to https://www.nationstates.net/page=enact_dilemma/dilemma=${issue_id}, that page still counts as an issue page and cannot be interacted with by scripts?
That would indeed mean that page cannot be closed by a script, but also that any pack-opening keybinds would be prohibited on that page specifically whilst remaining allowed on the https://www.nationstates.net/page=deck page.

[New Astrian Outpost 1]

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

Using the currently most-optimized method of manual recruitment, mobile recruiters do not have to copy paste anything. They are given a link which pre-fills the template code into the message box and a list of nation names into the send-to box. They hit send, and then confirm by reacting to a bot that they have sent the message and are ready for the next one.

If links which pre-fill the code and list of recipients in are no longer allowed, this process would be changed. Here's how mobile recruiters would have to operate instead:
1. Copy the template code.
2. Open the link.
3. Paste the template code into the message box.
4. Go back to the page where the bot has provided the code/nations to copy & paste.
5. Copy the list of nations.
6. Change the tab to the telegram box again.
7. Paste the list of nations.
8. Send the telegram.
9. Change the tab to the one with the bot again and confirm that they sent the telegram.

That's a lot of swiping and copy-pasting. It might sound somewhat fast to do on paper, but we over in TCB have personally seen the difference between mobile recruiters using the prefilled link system & mobile recruiters using the 9-step, non pre-filled system, and it's actually so so so much slower and more painful to use the non-prefilled method. When we test implemented it, our mobile recruiters (even the most dedicated among them) reported that it was so frustrating they literally could not stand it and would HAVE to wait until they were at a computer to recruit. Copying & pasting on PC isn't too bad because it's just CTRL C + CTRL V, but mobile users have to do a lot of precision dragging and tapping to copy text, and they have to fiddle around with holding the screen and waiting + precision tapping to get text to paste. Changing tabs so many times and doing that much inconvenient copy-pasting is deeply tiring and time-consuming and draining for mobile users. If this change is implemented, I swear on my soul that essentially no one who plays NS solely from mobile will ever be able to recruit again.

Is there any possibility you could allow for the links to pre-fill the template, but the nation names still have to be copied and pasted in by the user? Just that small adjustment would cut the amount of work mobile users would have to do in half, and make it significantly more bearable to recruit from mobile. I don't want to watch dedicated players have to just...stop recruiting because the system is too frustrating to work with.

(And oh, god, I don't want to even imagine what mobile recruiting would be like without any bot assistance. It would be literally 100% inconceivable to expect anyone to do it, because in addition to the 9 steps above, they'd have to individually swipe around searching for each batch of nations to set as the recipients. That's bad enough on PC, there's no way it would even be feasible on mobile.)

[Vylixan]

All the questions below are written in present tense, but for clarity, note we're discussing proposed rule changes for the future, NOT the current situation today.

- Is it still legal to use a script to select one of the issue answer buttons for you, that then gets submitted when the user hits a keyboard or mouse key? Or does it need one action for the selection and one for the submitting?

I'm not sure what you mean by "selecting" an issue... I can't think of what action that is. But bots would be prohibited from interacting with the HTML version of the issues page in any way, while remaining free to read / answer issues via the API.

I'm still iffy on what "interacting with the HTML site" means, selecting an option is arguably not interacting with the HTML site? it does not change anything on the HTML page?

Most if not all of the current farming scripts bring the focus to a random or more often the first issue option, which then gets confirmed by a key/button press of the user to submit. This done for ease of use and speed, since manually doing this would mean using the mouse to manually click the issue, or using the aforementioned Tab-Tab-Enter to do the same, which both take more time, and also take more actions, thus lead to fatigue and RSI etc.
Then on the next page it once again bring the focus the new pack button if that's present so a simple press on the enter key will also submit that button.

Let's just hope that there are no blind or visually impaired people doing any card farming. I would fear any accessibility tools and Assistive Technology like screen readers etc. or even increasing contrast or changing colours would be illegal with these rules. All accessibility tools I know off interact with HMTL pages on levels comparable with the current card tools and scripts.
This would get into an ADA-compliance issue, where my knowledge is minimal since I'm neither a legal expert,, or an expert on the ADA and accessibility tools, nor a citizen of the USA, nor using any accessibility tools,and I'm also not handicapped in the sense that I would need them.

Or hell even translating the page for our non-English friends. There are so many issues with a broad ban on "interacting with the HTML site".

Also I still don't know if my script mentioned a month ago in this topic is legal or not.
Would be nice to get some clarity there, since people replied to my question telling me that I wasn't interacting with the HTML. But interpreting what we've since then learned in this thread would mean that my current script would be illegal under the new rules.

My Issue answer support script adds a link beneath each issue on https://www.nationstates.net/page=dilemmas to for example http://www.mwq.dds.nl/ns/results/1483.h ... _aphrodite (the nation name is so the script working on the page can highlight stats for you based on nation config), it also adds the same link the the issue page its self (https://www.nationstates.net/page=show_ ... lemma=1483). Finally, once an issue is answered it also highlights preconfigured stats in the results.

Full screenshots

[Giraffeton]

do these proposed rules mean that prohibited actions must be done by a click and not a similar action such as pressing enter?

[Sandaoguo]

Can this be made explicit, in that case? The proposed rule only gives TGs as an example of "interacting with the HTML site in any way during the execution of an action," not as the only thing being prohibited.

The proposed rule specifically says "Prohibited actions are:" and lists two things. I think that is explicit. It doesn't say "for example" or "including" those things.

Your changes seem to make more ambiguous, as they remove the part about URLs that pre-fill form fields -- which is the key change -- while introducing new terms like "semi-automation", "assistance" without defining them.

It's not as explicit as you think it is, that's what I'm saying. The proposed rule says that a tool can't be used to perform a prohibited action. In the next sentence, it defines what "performing a prohibited action" is, which is when a tool "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." That's the operative rule. The example given is a telegram. Then the rule provides a list of "prohibited actions."

Given that the Script Rules for HTML interaction have always had an ambiguity problem, I'd rather not be staring down the barrel of a potential DEAT or WA ban because 5 years from now admins forget this thread and read the wording like I am. If this is only supposed to apply to TGs and answering issues, that should be made 100% explicit, whether it's my proposed wording being used as a base or admins coming up with better verbiage themselves. But right now, the rule's definition of what it means for a tool to perform a prohibited action applies to a lot more than TGs/issues.

As for whether or not "semi-automation" is more ambiguous, use my words if you want or don't, that's not my main concern here. But I think if the problem you're trying to solve is that clever devs keep making scripts that are technically legal, but undesirable, because the rules aren't written well... you guys should probably avoid making a rule that talks about very specific types of implementation. You want to ban these scripts because you don't like that they've introduced semi-automation to sending TGs or answering issues, not because of the specific implementation of passing parameters in a URL. If that's what you didn't like, you could change the backend to stop accepting/processing GET requests.

[Refuge Isle]

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.

Is "https://m.nationstates.net/page=compose_telegram?tgto=Markanite" considered a "script", then? That's a widely broader description than anything provided in the How We Regulate Bots announcement.

If the grounds of your rule is "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.", then you are presumably saying that it is permissible for a user to manually create a URL which performs the same action, as no tool is being used to generate the link. You're now contradicting your proposal.

Like Glen, I feel that you're trying to accomplish X by banning Y, where Y has a variety of implications that are ambiguous and open-ended, leading to swaths of users in the future facing bans for practices that are currently considered mundane, and to no benefit to site or community health. It would be greatly preferred for admin to adjust the site in terms of what you are willing to accept and process than to pursue this moderation route.

[[violet]]

Is "https://m.nationstates.net/page=compose_telegram?tgto=Markanite" considered a "script", then? That's a widely broader description than anything provided in the How We Regulate Bots announcement.

If the grounds of your rule is "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.", then you are presumably saying that it is permissible for a user to manually create a URL which performs the same action, as no tool is being used to generate the link. You're now contradicting your proposal.

An URL isn't a script. But if a script generates URLs with embedded payloads for the telegrams & issues pages, that's what would be illegal.

These are script rules -- they govern what scripts may do. People remain free to craft whatever links they like. I'm not sure what contradiction you refer to.

[[violet]]

It's not as explicit as you think it is, that's what I'm saying. The proposed rule says that a tool can't be used to perform a prohibited action. In the next sentence, it defines what "performing a prohibited action" is, which is when a tool "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." That's the operative rule. The example given is a telegram. Then the rule provides a list of "prohibited actions."

Ah yes, I see what you mean. "Prohibited action" is kind of defined twice.

Given that the Script Rules for HTML interaction have always had an ambiguity problem, I'd rather not be staring down the barrel of a potential DEAT or WA ban because 5 years from now admins forget this thread and read the wording like I am.

I have to point out, this is the exact problem with bots on the HTML site, and why we're trying to shift them onto the API!

HTML bots violate site rules on a very regular basis. It's very difficult for admin to tell whether this is because the author made a mistake, was unaware of the rules, or was trying to cheat. A large percentage of the time, when there's a major system performance problem, it's because of a bot running rampant on the HTML site. Often, I see bots that are clearly trying to stay within the rules but slip up occasionally, sending too many requests in a burst.

We built an API for bots that doesn't have this problem -- you can do whatever you like there, with no fear of accidentally falling foul of the rules. The API itself simply prevents bots from breaking the rules, and serves you data in a fast, efficient, and stable format.

However, many people choose not to use the API, but instead write HTML-targeted bots. We discourage this practice because it's so fraught with problems. No matter how crystal clear the rules are, not everyone will read them, not everyone will follow them even if they mean to, and some people will deliberately not follow them and get away with it because it's hard to tell the difference. So I can't agree that all we need here are clear rules.

If that's what you didn't like, you could change the backend to stop accepting/processing GET requests.

Again, this is a problem with bots on the HTML site, which is already solved on the API. On the API, we constrain how bots behave. On the HTML site, almost anything we do to manage bots will impact some poor unsuspecting humans - particularly humans with assistive tech - who find themselves getting blocked because our system thinks they're acting bot-ish.

[[violet]]

do these proposed rules mean that prohibited actions must be done by a click and not a similar action such as pressing enter?

No. The script rules (both current and proposed) say: "a user's mouse click (or similar input)."

[[violet]]

I'm still iffy on what "interacting with the HTML site" means, selecting an option is arguably not interacting with the HTML site? it does not change anything on the HTML page?

So here you mean "selecting" an option (but not "submitting" it) is the equivalent of pressing Tab in a browser, until a particular button is highlighted, such that any subsequent keypress of "Enter" will cause the equivalent of that button to be clicked? If so, that is interaction with the issues page, and would not be legal.

Also I still don't know if my script mentioned a month ago in this topic is legal or not. Would be nice to get some clarity there, since people replied to my question telling me that I wasn't interacting with the HTML. But interpreting what we've since then learned in this thread would mean that my current script would be illegal under the new rules.

It would be illegal, as it interacts with the issues page.

[Racoda]

-snip-

Not sure if this was missed because it sounded like an opinion more than a questions post, but I'd appreciate some answers ^^