Official script registry - discussion

Bale

Bale

Minion
zarqon said:
Bale, users of KoLmafia are scripters. By default. Excluding libraries would be silly.
Click to expand...

Most of them have trouble getting a script into the /script directory and get lost if they need to edit it. That's why zlib vars were such a large step forward in enabling users to edit script default values. I find it hard to say that means they are scripters. It certainly removes all meaning from that word. Sorry, but the purpose of the GUI is to coddle those with technical difficulty. Putting libraries into the GUI will reduce the coddle factor. It isn't the only way to find scripts, so it is fine for libraries to be listed elsewhere.


I like the idea of reducing entry requirements to almost nothing, then giving some users administrative power to remove unwanted entries from the list (or, if necessary, block users or IPs from submitting). Maximum convenience!
Click to expand...

I liked that idea better before I discovered that much of the internet likes to turn everything into penises. I completely cannot accept the idea of no barrier to entry. There needs to be an approval process, even if it is only a cursory consideration. A tiny speedbump of approval is a huge improvement from no restriction.
 
Last edited:
zarqon

zarqon

Well-known member
1. On Libraries' Relevance to Users
or
An Impassioned Plea for Users' Rights

Forgive me if I seem to be overreacting to this odd notion of excluding libraries, but I find your tacit suggestion that libraries do not benefit users to be presumptuous. Do you really consider everyone either a scripter or a user? Without overlap? To my thinking, anyone who uses KoLmafia has already taken a step on the path towards scripterhood. The second you string two CLI commands together with a semicolon, you've scripted. Next thing you know, you've saved a bunch of CLI commands in order in a text file. Then you discover you have more control using ASH. Then you discover there are library scripts to help you out, people who have already built important chunks of code that do things you'd like to do in your script. It's simply a question of how deep you want to go, and by excluding libraries from the visible list of scripts you're assuming, a priori, that anyone who uses this GUI instead of typing everything in the CLI by hand (uphill, both ways) is shallow and not interested in libraries that might be available to help them script. From what I've observed, all users are scripters; perhaps future scripters, perhaps not serious scripters, but scripters to some degree, and making it harder for them to access helpful libraries because they are users and therefore not scripters is both presumptuous and fallacious. The degree to which a user is a scripter should be up to each user, not prescribed for them by you or me.

Besides, I thought the primary purpose of mafia presenting an SVN list was to "reduce the barriers", not to "coddle those with technical difficulty". Excluding libraries increases the barriers by roughly categorizing users as separate from scripters, without accounting for overlap or facilitating the journey from one to the other.


2. On the Necessity of an Oligarchic System
or
Control vs. Trust Online: Can an Internet-based Community Deserve Trust?

I must also penguinfully disgree with your claim, Mr. Jobs, that approval is necessary before inclusion. Unless you're dealing with 5th-graders, inclusions that pass muster (correct format, no obvious red flags) can simply be moderated after submission, with much less of a burden on both submitters and regulators. Moderators could be sent a notification whenever a script is registered, to aid swift reaction times. Further, requiring forum membership (or KoL membership; the submission could be made from the logged-in GUI) makes for an extremely small slice of the internet pie, and as you've already noted, our community has a good record of trustworthiness. Let's compare the two:

Approval before submission
Pros: No bogus submissions. People in charge feel important and helpful.
Cons: All users, including the good majority, must wait for a person who has control and power over them to decide their fate. The amount of time this takes will vary based on approver availability. Users feel like they're being scanned at the airport, which frequently leads to negative feelings towards the security officers.
Worst case: Approvers all go on vacation simultaneously, causing delay and frustration to entire userbase. Personal feelings/vendettas can result in unfair regulation of submissions, because with this system, it's personal.

Moderation after submission:
Pros: Freedom to submit for all users. No delays, regardless of moderator activity level. Giving users power/responsibility/choice causes them to feel trusted.
Cons: Fifth-grade users may successfully submit penis.ash when their parents aren't looking.
Worst case: A daft, foolhardy user installs and runs penis.ash before moderators remove it (they're all on vacation). Surprise! The script turns out to be malicious and sends all of the user's meat to some other account. Since the author of penis.ash is known, that user is banned and reported everywhere it's possible to report them. The daft, foolhardy user learns a valuable lesson.

In both cases, problems arise when the human element is tardy. Who then does the system punish when that happens? In the case of pre-approval, everyone is punished. In the case of post-approval, only the daft, foolhardy user who actually installs the harmful script is punished. The second option strikes me as much more fair, in addition to promoting a healthy community.

In most apps where user content is permitted carte blanche, there is also a peer feedback system. Having a "vouch" button show up for your installed scripts would be a neat way to reduce problems with the post-approval method to practically zero. Scripts with multiple vouches would be "trusted scripts" whereas users "without technical ability" probably ought to avoid scripts that have very few vouches. If the number of vouches could be expanded to show who had vouched for the script, it might even be more helpful, since the vouch of prominent users would carry more weight.

It appears we differ philosophically -- perhaps even politically -- on this age-old debate of freedom vs. security. As a teacher, I believe it's important to the classroom environment that the students be trusted, and that's what's governing my opinion here. I feel wary that amid the clamor for high security in this system, we will neglect the community aspect. I believe that KoLmafia users can, by and large, be trusted to submit good scripts and correct data, and that we should not penalize the many for the crimes of the few. I believe that by simply regulating input (rejecting anything harmful or incorrectly formatted) we can eliminate penis-ridden submissions, and in the unlikely but possible case that a maleficent, identifiable, registered player or forum member deliberately submits bogus data, I have no doubt that our team of alert and knowledgeable moderators would take it down before it could do any harm and ban/report the offender, reducing the the payback for any malicious user and making it not worth their while.

I respectfully yield the floor.
 
lostcalpolydude

lostcalpolydude

Developer
Staff member
Approval before submission
Worst case: Approvers all go on vacation simultaneously, causing delay and frustration to entire userbase. Personal feelings/vendettas can result in unfair regulation of submissions, because with this system, it's personal.
Click to expand...
End result, people decide the system is too slow and go back to using the forum, while the built-in system is still somewhat useful.

Moderation after submission:
Worst case: A daft, foolhardy user installs and runs penis.ash before moderators remove it (they're all on vacation). Surprise! The script turns out to be malicious and sends all of the user's meat to some other account. Since the author of penis.ash is known, that user is banned and reported everywhere it's possible to report them. The daft, foolhardy user learns a valuable lesson.
Click to expand...
I don't want the user that runs a bad script in this repository to be considered foolhardy. I would prefer never seeing this feature added to mafia than have a system with this risk.

In most apps where user content is permitted carte blanche, there is also a peer feedback system. Having a "vouch" button show up for your installed scripts would be a neat way to reduce problems with the post-approval method to practically zero. Scripts with multiple vouches would be "trusted scripts" whereas users "without technical ability" probably ought to avoid scripts that have very few vouches. If the number of vouches could be expanded to show who had vouched for the script, it might even be more helpful, since the vouch of prominent users would carry more weight.
Click to expand...
That could work (and would ease my concerns sufficiently), but I suspect the added complexity means the feature would never be added.

One thing not mentioned in your discussion is legitimately-written scripts by new scripters that have significant room for improvement. Castle farming scripts that consume very specific stuff, equip specific gear, and don't check for any error cases would be a typical first script that has actually been posted here multiple times. It's great for people to post those here, especially since they can get feedback about how to improve their scripting, but I wouldn't want to see it in the script registry.
 
roippi

roippi

Developer
I disagree with your worst case for "moderation after submission." One particularly spiteful person can create endless smurf accounts on sourceforge and keep replacing the entire registry with penis.ash. Ad infinitum.

I would love to create a peer feedback system but that requires a server set up to receive and digest the clicks from said system.

As for libraries: eh. If the author wants it to be in the repo, okay. A description of "this library is automatically installed by other scripts that depend on it" or somesuch can smooth any confusion by lay users.
 
Last edited:
fronobulax

fronobulax

Developer
Staff member
Why are we doing this? I would say to publish, and make more visible, a list of scripts that KoLmafia users might find valuable. This, I am swayed by zarqon's plea for libraries. Someone who is about to learn to script might very well be pleased to know that there are libraries out there. So yes, let's include libraries. And let's choose a format so that libraries with documented functionality can be listed with a link to the documentation.

On the penis.ash problem, I am not, however, swayed. The user who inadvertently runs it is going to tell every one how awful KoLmafia and the developers are because they published a link to it in a catalog which means they endorsed it. This is after they have already smeared kolmafia.us and every user name they have ever seen on it. If my choice is to have the opportunity to clean up after this mess or put something in place to reduce the likelihood of it occurring I'm all in favor of the latter. And I am selfish enough to make eager scrip submitters wait until everyone gets back from vacation, if that is the price. I mean it's not like KoLmafia and scripts are anything other than labors of love, right? Even dj_d has decided that there is no longer a point in charging for his work.

I note the SF repository for KoLmafia source code. Everyone who has access to it has been vetted by someone who already had access.
 
Fluxxdog

Fluxxdog

Active member
I think Zarqon has me convinced on both the facets he presents.

First, make libraries available. If people can understand what they are to begin with, so much the better. The user will have to make the conscious choice to download it anyway, whether it's a dependency or the start of their own scripting career.

Second, approval before submission. Zarqon makes his worse case scenarios very clear. In one of them, someone does suffer harm first and foremost. The other is simply opinion anyway. Yeah, frustration and, as it was eloquently put by someone else, "butt hurtz".
http://kolmafia.sourceforge.net/ said:
To make things absolutely clear, open sourcing a program does not make it secure -- it strictly makes it easier to take advantage of work already done by other people, provided you are willing to act in accordance with the terms of the license under which the source code is provided. That said, I believe KoLmafia is safe. However, I'm the main developer of KoLmafia, and I only use a small fraction of its features, so my opinion of it should be taken with a grain of salt.

My personal belief is that running any program (including the web browser you are using to view this page) is about near-unconditional trust. If, for any reason, you don't trust the companies and individuals involved in the development of the program, I strongly suggest that you should never run the program, no matter what the promised benefits may be. I believe these same guidelines should be applied if you're thinking about using KoLmafia.
Click to expand...
As such, we should do everything to help ensure that trust, including making sure such releases are safe for use. The forum gives a layer that has people recognize that it's not a part of KoLmafia but . Once KoLmafia includes those third-party programs, this implies a level of trust. Any harm a person suffers then is reflected on KoLmafia. This is why programmers will allow third parties to create for their software through APIs, scripts, or directly editable files, but take absolutely no responsibility if they're used.

The level of trust extends beyond personal feelings. If someone starts acting like a jerk, it's the team's responsibility to reprimand them. If they don't, people are going to leave or start their own projects. I'll extend Zarqon's worse case to beyond the vendetta scenario: forks. Mafia is open source and it wouldn't be impossible for someone to fork the code and start their own project. Then the wars start. The people who worked hard on mafia will see their worked splintered and quibbled over as things go down the drain. In other words, there's incentive for them to keep doing a good job in the first scenario and moderate their jerks.

The "moderate after submission" is the forums.
 
Theraze

Theraze

Active member
I'd just like to agree with the developers... if someone DOES happen to screw up their account using mafia and the items that it offers up to them, they will blame mafia for their own failings. It's not their fault. It's NEVER their fault.

Rather than dealing with the drama, it's so much easier to limit the list to what is actually useful. Don't like the list or where it's stored? Compile your own version with a separate list-storage location or system. It's really not THAT hard to compile if you can follow easy directions from the Wiki, and if you can't follow them... then you're probably the kind of user who can't be trusted to not run penis.ash.
 
roippi

roippi

Developer
I actually don't care too much about the end-user who is hurt by running malicious code that they obtain through the script browser. We The Devs cannot and do not guarantee "safe" execution, however you want to define that - wasted turns, suboptimal meat expenditure, sending all your stuff to malicious scripterdude.

What I DO care about is an inability to protect the system from one disgruntled user who wants to grief it. There will be a singular file hosted on an SVN repo. We can't just give "add" privileges; we give "edit" privileges. i.e. you can edit the entire document. And if that privilege is global, there is no way to prevent one guy behind infinite smurf accounts from doing whatever-he-will. I can't endorse opening up the system to such an obvious attack vector.
 
S

slyz

Developer
roippi said:
I would love to create a peer feedback system but that requires a server set up to receive and digest the clicks from said system.
Click to expand...
Having the number of times a specific project was checked out would give a good enough metric for users who want to know which scripts are trusted by the community. Does SVN provide anything close to this? If not, hosting the SVN server on kolmafia.us would allow us to track this eventually, which would be a strong pro, in my opinion.

roippi said:
What I DO care about is an inability to protect the system from one disgruntled user who wants to grief it.
Click to expand...
Isn't it possible to deal with this kind of griefing only if and when it happens, by modifying the privileges? If it becomes a Club sport, I guess even Zarqon would have to admit that yet another piece of the internet would have to be moderated.
 
roippi

roippi

Developer
slyz said:
Having the number of times a specific project was checked out would give a good enough metric for users who want to know which scripts are trusted by the community. Does SVN provide anything close to this?
Click to expand...

Nope. If we had access to the apache logs we could parse it out, but sourceforge doesn't provide that. I don't think.

Isn't it possible to deal with this kind of griefing only if and when it happens, by modifying the privileges?
Click to expand...

Well, yes. We could. But at that point we have no infrastructure for taking requests-for-access. And do we switch after the thing gets vandalized once? Three times?

It's a tradeoff either way, I'll admit. I just don't see the cost of PMing a mod or posting in a thread to get lifetime edit permission as being terribly high.
 
Bale

Bale

Minion
I suppose if we want to have information about numbers of users we could have mafia record the information every time an install link is clicked in the GUI and then update the information at logout just like mall prices... Kinda overkill though.

I believe we have sufficient consensus on the subject of registry editing access. Zarqon is the sole voice of the opposition which isn't really enough to sway it unless he can convince someone else.

It appears I am the only one who believes we shouldn't list library scripts. Sigh. It seems we have sufficient consensus on that as well even though it has not gone my way.

Fields for each script should be:
  1. Name of script
  2. Author(s) of script
    If there is more than one author, the first name should be the current maintainer.
  3. checkout https address
  4. Hyperlink to forum thread or other place where the script can be discussed
    I feel it does not need to be on this forum. Some people (bumcheekcity) like to post threads in G-D about their script and that seems legal as a link if it is their desire.
  5. Description of script
    I put description last because is the only part that is likely to become lengthy.

It seems that tab delimited text was determined to be the lowest barrier to entry for adding new scripts although zarqon suggests there should be a web-based php script that takes inputs and converts them to JSON. I like zarqon's idea, but someone would have to host it, etc, so it is more complicated than just creating a project on sourceforge.
 
Theraze

Theraze

Active member
Question... is this something that could possibly be done similar to zarqon's Script Registry, where a script can be registered and usage tracked by notify or something similar?

For that matter, could this just be an official version of the Script Registry with some sort of "mods need to approve you as a script creator, at which point you can update your own scripts in the future" system where you can't mess with anyone else's stuff?
 
xKiv

xKiv

Active member
Bale said:
It appears I am the only one who believes we shouldn't list library scripts. Sigh. It seems we have sufficient consensus on that as well even though it has not gone my way.
Click to expand...

I think it wouldn't be a bad idea to list them separately (i.e., sorted at the end, or something like that), at least by default. When I am looking for a script that does something, I don't need to see libraries that are used by those scripts. I only need to see libraries when I am looking for libraries.

Theraze said:
... where you can't mess with anyone else's stuff?
Click to expand...

(assuming svn/sourceforge as the repositoyy) That would require either an involved front-end (with its own login), or structuring the repository so that each developer has separate file for editing, and then some automat generates a complete list, from a template (include script X by looking at developer Y's file) to prevent duplicates, confusion or abuse. (Or just have mafia download and process all those files after login / on demand)
 
H

heeheehee

Developer
Staff member
zarqon said:
Approval before submission
Pros: No bogus submissions. People in charge feel important and helpful.
Cons: All users, including the good majority, must wait for a person who has control and power over them to decide their fate. The amount of time this takes will vary based on approver availability. Users feel like they're being scanned at the airport, which frequently leads to negative feelings towards the security officers.
Worst case: Approvers all go on vacation simultaneously, causing delay and frustration to entire userbase. Personal feelings/vendettas can result in unfair regulation of submissions, because with this system, it's personal.

Moderation after submission:
Pros: Freedom to submit for all users. No delays, regardless of moderator activity level. Giving users power/responsibility/choice causes them to feel trusted.
Cons: Fifth-grade users may successfully submit penis.ash when their parents aren't looking.
Worst case: A daft, foolhardy user installs and runs penis.ash before moderators remove it (they're all on vacation). Surprise! The script turns out to be malicious and sends all of the user's meat to some other account. Since the author of penis.ash is known, that user is banned and reported everywhere it's possible to report them. The daft, foolhardy user learns a valuable lesson.
I respectfully yield the floor.
Click to expand...

Proposal: unconfirmed scripts are tagged as such; moderators can clear this tag after checking that the submission does what it claims to do. As a user, I might be more likely to trust a script from Bale than Jick (who hasn't ever written any Mafia scripts, as far as I'm concerned), even if his script hasn't been validated by a moderator.

Pros: Extra warning for users; users know which scripts are unconfirmed and can hold off on installing them. To some extent, combines the pros of both approaches.

Cons: Updating scripts --- newer versions also need to be checked. As a user, I would like the ability to use the oldest confirmed version and also for svn update to work as much --- additional complexity to handle this. The very daft, foolhardy user is still punished. Trust gets shifted from scripters to moderators (although this is the case with any moderation).
 
roippi

roippi

Developer
Bale said:
4. Hyperlink to forum thread or other place where the script can be discussed
Click to expand...

This doesn't have to be its own thing; the GUI can display arbitrary HTML so you can in-line it in your description.

heeheehee said:
Proposal:
Click to expand...

How would the backend of this work exactly? We have one text file, hosted on an SVN repository. How do we get to your system from there?
 
H

heeheehee

Developer
Staff member
roippi said:
How would the backend of this work exactly? We have one text file, hosted on an SVN repository. How do we get to your system from there?
Click to expand...
This is a difficult question to answer. (mostly because of the words "backend" and "exactly")

I imagine the textfile would have entries like
Code: 
author_name, script_name, last_approved_revision, current_revision, svn_url
where last_approved_revision starts out as 0.

Two pieces of UI (front-end):
Author interface: specify author_name, script_name, svn_url.
Moderator interface: after reviewing a script, specify svn_url and reviewed revision.

back-end: some way of providing this UI and updating the datafile accordingly.
 
Bale

Bale

Minion
One more detail for the list of scripts: It would be good if it was sorted into categories like my list. That makes it a lot easier for the user to find the script they want. Roippi, is that feasible? Perhaps a field in the file that identifies the category to put it in?
 
roippi

roippi

Developer
heeheehee said:
back-end: some way of providing this UI and updating the datafile accordingly.
Click to expand...

The point is that I don't want to set up a server to receive and digest things in order to make this all work.

Bale said:
One more detail for the list of scripts: It would be good if it was sorted into categories like my list. That makes it a lot easier for the user to find the script they want. Roippi, is that feasible? Perhaps a field in the file that identifies the category to put it in?
Click to expand...

Yeah, that could work. I'd probably go with a pre-defined list of acceptable categories, coercing to "miscellaneous" if none is specified or the field doesn't equal any pre-defined categories. Although.. I dunno, user-created categories wouldn't be the worst thing, just potentially messy.
 
Bale

Bale

Minion
roippi said:
I'd probably go with a pre-defined list of acceptable categories, coercing to "miscellaneous" if none is specified or the field doesn't equal any pre-defined categories. Although.. I dunno, user-created categories wouldn't be the worst thing, just potentially messy.
Click to expand...

That sounds like a good plan. I don't think that user-created categories are a good idea because you'd end up with too many categories which are typos and way too many sub-categories of only one or two scripts. I worked hard to find categories that would divide scripts into meaningful groups of recognizably definable functionality without leaving too many in the miscellaneous category at the end.

Categories:
  • Adventuring Automation (Anything that causes mafia to spend adventures for the user)
  • Action Automation (Because your character can alter things without needing to adventuring)
  • Information (Anything that displays information to the user without changing your character's status or inventory)
  • Relay Overrides (Scripts that alters KoL's browser display -- Needs a warning that some of these will conflict with each other)
  • Combat Script (These are used to enchance or automate combat)
  • Function Libraries (Scripts intended to be called by other scripts)
  • Miscellaneous (Anything that defies the above categorization -- Very little should end up here)

Incidentally, several of those categories were created after I noted similarities between a number of scripts in miscellaneous so I wouldn't be surprised if a growth in the miscellaneous category will inspire a new category to be created. If that eventually occurs, I suspect it may require a change to KoLmafia to recognize that new category. (It shouldn't be too hard since it would be a fairly simple "New Feature" request.)
 
lostcalpolydude

lostcalpolydude

Developer
Staff member
One advantage to only allowing pre-defined categories is that the GUI can have a brief description along with each category. If new categories are needed, a description can be added.
 
Last edited:
You must log in or register to reply here.
Top