Had a look at how Maven/Ivy dependency management works?
I’m in favor of combining the efforts of the community and moderator screenings. Also a complete ‘no’ for any kind of money involved in the uploading - I think even more mature devs would be turned off by the thought of having to flip out their payment details just to upload a file.
I would agree with this, I feel like an unrevealed, or even somewhat randomly generated requirement (e.g. between 10 & 20 files must be reviewed), with the ability to flag users by reviewers for something like non-files being submitted, or the same file being resubmitted several times for the purpose of beating the review requirement. I feel like this would be reasonably annoying for newer submitters, while providing a decent buffer between the users and the common Malicious code trolls.
Also, Because I am not too familiar with the Plugin community… are plugins more vulnerable to malicious intent then mods, if so I would greatly appreciate a technical explanation ;~)
I don’t use Java, but from what I know it’s similar. Though, a Gemfile is kept really simple and nicely readable, so I’d prefer that.
On the other hand, Gemfile support would either require a custom parser or (at least) a JRuby implementation, and is hard to do securely. Maven/Ivy is already proven and used, is plain XML (so easy to parse securely), and is already both generated and consumed by Gradle (the build tools used by Sponge).
i vote for number 3.
on EVERY download page, there should be a link to jdgui (http://jd.benow.ca/) and a recomendation that people use jdgui to decompile ALL plugins that they download
EDIT:
sometimes the decompiled code is different to original code.
i suggest that you force developers to upload the source code, then the server compiles it.
server owners then get access to:
- an online source viewer (like github’s file preview)
- zip file download of the source
- compiled jar file
another thing:
devs get rep for good files,
Everyone gets rep for reliable reviews (flagging a file for review, then staff members agree with it)
@sk89q
if you use both flags and community reviews, some things that get past the flags might get caught by the community, then you can add a flag to prevent similar attacks, keep doing this, and eventually, almost all dangerous plugin will be eliminated.
of course, there will still be people who can get past everything, but i think currently, more damage is done by the people who write simple hacks, so if we get rid of them, we get rid of most of the problems.
also, i suggest that you get the downloads site finished and fully operational before you start letting people make mods / plugins,
if someone makes a plugin, but theres no official website to upload it to, they will find somewhere else to put it,
they usually wont bother reuploading it on the official website
ANOTHER IDEA @sk89q
(this idea was stolen from google 
)
you should add permissions groups for plugins,
before the server owner downloads the plugin they see something like this (but for plugins, not apps)
the server owner clicks accept, they download the plugin
for example, the server will NOT let the plugin use .setop(true) unless the developer has told the website that they will use it.
You have good points but I respectfully disagree. In my opinion the added work of a full review for every update or submission is more likely to burn people out, yes it’s riskier, but as a trade off for speed, and less work for the reviewers I believe its worth it.
Even if files were not released until reviewed, I still believe diffing with the option to fully review is the best method, and should also be viewable by the community.
Additionally external sites should still display warnings but should not be banned.
I don’t think that developers should get rep’d for plugins… This could turn into Hackforums where it’s harder to get people to try out your stuff if you’re low on rep (ie those who release plugins from the beginning get the most rep and people trust them).
edit: Also I disagree with supporting plugin decompilation. Not saying that I don’t decompile some plugins, but encouraging this can be bad especially if the developer does not wish to share the sauce yet (or at all).
2 Likes
I agree. It sucks if you made something new that is actually pretty good, but nobody uses it because your rep is low. Also, concerning decompiling, most users can’t even understand teh codes. (People setting up servers for friends etc…).
The only kind of “rep” I’d suggest is flagging (tag next to name) people if they actually did something bad. But I’d not bother as moderation and just straighout ban them for posting malicious code.
Also, some things (Grief prevention etc) would be compromised if everybody was encouraged to decompile them. (Not that hack developers didn’t do that anyway…)
1 Like
One thing that I think is very very very important is that the plugin hosting is accessible via an API. (REST?)
There are several types of systems that could profit from it.
Auto updaters, update checkers, local plugin managers, things like MCAdmin or comparable control panels.
Maybe instead of a Reputation system, how about a Karma System?
i didnt think about the rep thing.
the only reason a dev would not want the source to be seen is if they are hiding something bad
Or, you know, if they didn’t want someone to steal their code.
1 Like
Define: Stealing. If I look to someone code it is to learn from it. And with jd-gui you can see every plugin his source, so why hidding it?
Can protect someone’s intellectual property.
“To take (another person’s property) without permission or legal right and without intending to return it.” - via Google.
While this philosophy is great for an open source community, it doesn’t give you blanket access to everyone’s code who doesn’t want their work to be shared. Would you be silly to assume you could hide your code from others? Yes. Does that make people decompiling your work and looking at it when you’ve made it obvious that this goes against your wishes right? No.
Just because you have the power to do something does not make doing it okay.
I just see it like this. We are making Plugins on top of a public/open source project. If this is now forge, Sponge, Husk or something else it doesn’t really mater for me. We make these plugins/mods to help server owners or make the game called minecraft more fun.
Lets say the server owner likes the plugin but wants to change some small part for himself. Than he could do that with having the source available and so far I know it it completly legit to take someone code, change it and use it for own use (Off course without support from the original author).
But lets say you hide your code. And the server owner wants to add that small feature he needs, he wouldn’t be able to. Or he will need to research and look a lot to get the source of the jar and recompile it. What in most cases brings up more problems. Also most people give up. (I spend hours and hours to figure out how to recompile computercraft mod with bukkit support (for own use), but it simply won’t work… .)
Than don’t share the plugin. no source == no plugin, their are enough licences that can protect your intellectual property.
1 Like
And this is what? An open source community!
If you want to make a proprietary plugin, that’s fine and not against the license of Sponge, but that doesn’t mean Sponge has to host or endorse it. You need to learn to separate the license of Sponge(API) from the ToS of SpongeDev.
2 Likes
I’m not even sure what you’re trying to get at, with this statement. I never quoted the Sponge license, or the SpongeDev TOS, both of which are rather irrelevant. The Sponge license being irrelevant because, though you use the API, assuming your scope is provided (or whatever you would use for non-maven projects), none of the code is actually included in your project (though it wouldn’t work without it).
Again, you’re kind of coming out of left-field here. The debate wasn’t about whether or not Sponge would “host or endorse” a proprietary plugin. There were plenty of plugins on BukkitDev that weren’t open-source, but could still pass the approval process. Those who reviewed the files were given that right by an agreement made by the developer upon signing up for BukkitDev in the first place.
However, anyone else who was attempting to decompile/read the project, without permission, and without the code being open sourced, were simply in the wrong. It doesn’t matter if the community is predominantly an open source community. That doesn’t give everyone blanket access to violate someone’s intellectual property by decompiling their code against their wishes.
The fact that this is even a point of debate, the morality of reading someone’s code when they’ve made it clear they’re uncomfortable with it, after they share their - potentially - hard work with the community is, frankly, appalling.
Depends why you’re doing it.
If it’s for interoperability or security testing you’re generally permitted by law, no matter the licence.
Copying the code still comes under copyright law, of course.
1 Like