Plugin Hosting

Something similar to what @Phiwa said would work. StackExchange have countless rewards that are available through reputation.

You could also have the same rewards Bukkit did (PayPal/Amazon) gift cards.

Problem is that BukkitDev worked in cooperation with Curse and I really hope they do not do this again because Curse might have a good network, but I do not like that they earn tons of money using my work.

4 Likes

Hashes are not compression, hashes are hashes. Hashing allows for validation that the file really is what it’s supposed to be. Hence why I recommended it, and why Bukget stores them

1 Like

It’s also worth pointing out that there are plenty of systems out there that have no reviewers as well, like the Python Package Index, RubyGems, etc. They may have an automated system, but no manual process that I am aware of.

I support proposition #2 for community orientation is a must anyway. I think that it will also allow for more input, which will let Sponge know everything before actual releases. Using the community as the primary ground opens up all sorts of thought that can be minor to the individual, but just the huge collections of it will prove useful in spotting things, such as technicalities and compatibilities.

I especially like having the staff actively involved as part of the proposition as well as having all the downloads available to everyone all the time.

Also, having the community more involved directly in this way I think will render an advanced community!

I’m for an automated scan that adds special tags to the project indicating what of the api the plugin is using like:

Plugin let’s a player execute a cmd so it get’s the Tag “Executes Commands for Players” or something like that.

And if the plugin uses something like op, deop, tries to access permissions of a player or whatever it gets a red flag and has to be reviewed by hand before it will made public. So like the google play store you could say.

But I’m also for a system where you can report a bad behaviour of a plugin if there are to many it has to be reviewed again.

Sorry if an idea like this has already brought up but I didn’t felt motivated enough to read through all of the 271 posts

Totally Agreed.

I pick the second one.
If it is not voted yet it will give a big warning, but for unregistered users it won’t allow them to download.
If it is rated by the community, it will allow anyone to download.
If it is verified by a staff member, the file will have a verified badge.

3 Likes

soitware review is not difviult, provide src and spec then staff compile for you. source is checked and file garanteed non-malicioum

Do you know how to spell PROPERLY? There’s some spelling errors…

i am slight dyslesic, nd english is not my native language.

Ok, just wondering.

We already had a discussion about that, and came to the conclusion that it opens up a whole world of new possibilites to try and get past the system. So no, It doesn’t work.

I think that it would be awesome if the plugin developers didn’t upload the .JARs but the sources that then gets sent to the Sponge Staff team for further investigation if approved, the staff will compile the .JAR and uploads it to the Sponge plugin hosting site. This will lead to no need for decompiling and maybe the Sponge team could develop a desktop program to download the sources and compile them by clicking one button after the source is checked. May be a lot of work but how Sponge is going forward right now I think the staff would be able to do it.

1 Like

Like VAC: You can use same cheats for a week and then VAC is like “enough”.

1 Like

Then the satff would have to check the buildscript aswell and all the dependencies grabbed and one could still hide things somewhere in the setup… No thanks.

Still way preferable over the alternatives.

No. It is safer to decompile a jar and know that the jar contains ALL code than to look at some source you build yourself, that could push in external classes in 50 different places, without ever being sure wether you’ve now seen all the code that’s going to be contained in the final jar.

Yeah exactly. The main differences here though is that game hacks won’t deal any permanent damage. When the player is banned, the issue is gone. Here though that malicious plugin may already have dealt some serious (irreversible) damage. You COULD have a system whereas there would be a malicious plugin detected after it was downloaded, it could somehow be remotely disabled. Eg. By checking it’s key a central server that says if a plugin is good or bad.

“it could somehow be remotely disabled.”
I have bad feeling about these.

I hope for hybrid mode. Have some automatic scans and some people checking stuff. Known people should be able to upload without too much hassle.