Sponge Status Update 12th December 2019

G’day everyone! It’s time for another exciting Status Update full of holiday merriment and a dash of dev talk.

Developer Update

Our developers have been hard at work on maintaining and building on our 1.12 LTS as well as making lots of exciting progress to the 1.14 update. While we’re aware 1.15 has been released, we remain committed to release Sponge for 1.14.4. Once 1.14.4 is functional, we will look into the migration process for 1.15. Thank you for your patience.
Since it’s been a while, check out our latest visualisation to see our efforts over the years:

1.12.2 LTS

The biggest news here is that we have recently released a new Recommended Build, 7.1.7. This update has been a long time coming - about 6 months of features and fixes have gone into this build. If you’re using any build before this one, we recommend you make the jump to 7.1.7 to benefit from these fixes! Some of the notable changes are:

  • Compatibility fixes for mods such as LibrarianLib, Tinker’s Construct and others;

  • Improved memory usage (optimising how we create and cache objects for our Phase Tracker and Cause Stack);

  • Significant Command, Inventory and Data fixes; and,

  • Update of internal code structure to create a sane policy for our mixins.

That last point may not seem significant to you, but the reorganisation will make it much easier to maintain 1.12.2 as a LTS build, but also significantly simplify the process of migrating our mixins to newer versions of Minecraft (indeed, more on that in a moment).

Some plugin developers have been asking about a potential release of the API to version 7.2. We can confirm that it is indeed coming. We have a couple of final additions that our team wish to add. Our focus will then be on API 8 for new features.

That does not mean that we will abandon API 7.x, far from it. It will, however, become a lot more community driven. If there is an API addition that you wish to make once we release 7.2 - we will still consider it and help you get it into the codebase. If there are enough contributions, we will consider releasing an API 7.3.

Finally, for the avoidance of doubt, we do not have an end of life date set for 1.12.2 and API 7 and we don’t envisage dropping 1.12 support any time soon. However, as far as the core team is concerned, we will be transitioning into “maintenance mode” beyond API 7.2, we will only be fixing issues that arise, any new features will be down to the community!

1.14

The most frequently asked question on our platforms is, without a doubt, “when will you release Sponge for 1.14?” Our response has always been “when it’s done” or “we haven’t got an ETA”, and we know that hearing that is frustrating for you. I do want to share the progress that we’ve made, and to give you a little bit of insight as to what we’re doing.

Sponge API 8

The current state of API 8 can be viewed at https://github.com/SpongePowered/SpongeAPI/tree/api-8, with a PR and (much) discussion at https://github.com/SpongePowered/SpongeAPI/pull/1995.

API 8 is our next big release of the Sponge API, and is shaping up to be our biggest update ever. As Mojang has been rebuilding many of the Minecraft internals, we have been taking time to do the same to our API. Commands, Inventory, Data and World Management are all examples of areas that we’ve identified as needing much in the way of love, either to fit around the new structures (such as Commands and the new client completion), or that the existing API wasn’t really well loved by the community (custom data, anyone?).

We frequently post updates to the API to api8/* branches for feedback and we have a number of API 8 pull requests open just waiting for developers to cast their eye over.

Now is the time for plugin developers to start looking at what we’re proposing and to play about with the API and to tell us what could be better. Let’s make API 8 the best it can be - come talk to us!

Sponge Common Implementation

The current state of the 1.14.4 implementation can be viewed at https://github.com/SpongePowered/SpongeCommon/tree/api-8, with various branches also being worked on (generally starting with api8/)

It’s no good having an API if we have no implementation to run against. We are pleased to report that we are making good headway with our implementation - we have managed to just about clear our first stumbling block and we are now working on getting a compilable build of SpongeCommon.

The first step in our upgrade has been to perform a “remapping” of objects from their 1.12.2 MCP names to their 1.14 MCP counterparts. Zidane, with support from jamierocks, has now been able to automate this process, and we have now got a codebase that uses MCP names for 1.14. Our next step, which is underway, is to audit all of our mixins and determining whether they relevant any more. Developers in the community can help us with this - it’s simple work that will make a real impact on the development of Sponge! If you want to help, please ask in the #1dot14updates channel on our Discord server and we’ll let you know what needs to be done to help.

Simultaneously, some of us are working on bigger chunks of functionality that are crucial to a functioning build, such as commands, inventories and world management. Keep an eye on our Github repo to keep up to date with our work!

We know you have been waiting patiently for 1.14 builds. We are working on it!

A Note on Mojang Provided Mappings

Some of you in the community will be aware that Mojang now publish their own source mappings that give readable names to otherwise obfuscated names in the Minecraft code. While it would be great to be able to use them, the licence on those mappings implies that they are for “internal, reference purposes” only - meaning that we cannot distribute them which we (or Forge, or other modding platforms) would have to do if we used them! Thus we will continue to use MCP names until such time Mojang clarify that we may use these mappings in our own modding products.

However, these Mojang mappings do provide opportunities for us to inspect code more quickly and get a better idea as to how things fit together. It also enables projects such as MCP to provide their own names more quickly as we now have hints as to what different parts of the Minecraft code does - knowledge of these names may afford us more rapid development in the future!

Ore

Striking a balance between ease of use and security is always a difficult challenge, especially in the case of remotely downloaded executable code. As always, we suggest that users carefully evaluate the trustworthiness of the developer before installing plugins, especially in the case of those that download code that we cannot assess. Of course, there are a great many reasons for building plugins that utilize this technique, so as such we’ve updated our guidelines regarding plugins that execute downloaded code to the following:

  • We cannot ensure that content that is downloaded and executed at runtime is safe and complies with our guidelines.

  • Any project that performs downloads and execution of code will have warnings on the project page and a warning prior to download to ensure users know the risk.

  • The following conditions must be also be met by the project:

  • Downloaded content must have hard-coded SHA256 (or better) based hash checking

  • Downloaded content must be explained in the main project page as to what is downloaded and what purpose it serves

  • Downloaded content must be performed over HTTPS connections

  • Downloaded content must not be hosted in a location that will limit downloads (e.g. DropBox, Google Drive)

  • Downloading another plugin must go through Ore’s API in the same fashion as Update Checking

We’re always looking for more developers, and you no longer need to touch any Scala to be helpful thanks to our Vue rewrite.

Community

Sponge Holiday Festival

Roll up one and all for the amazing Sponge Holiday Festival! Watch as @worm424 does backwards pirouttes, be astounded as @dualspiral tells tales of his adventures in far off lands and join the Sponge team for a jolly good night of laughter and merriment! (Backwards pirouttes and tales of adventure may be postponed indefinitely).

Join us at the usual time of 21:00 UTC on Saturday 28th of December and compete with and against the Spongineers in a series of minigames and challenges on the Sponge Community Server (demo.spongepowered.org). We’ll post more details closer to the event, hope to see you there!

Summer Plugin Competition

As we get to the end of the year, it’s time for another plugin contest! This time around we won’t be giving you a theme, instead we want your imaginations to run wild. Come up with something intricate, exciting or just downright useful!

New Plugins submitted to Ore between December 1st and January 31st will automatically be entered into the plugin competition (Updates or reposts will not be permitted)

We have 3 sets of prizes to be won:

  • Third Place: Will receive a $20 in value prize from the list below.
  • Runner-Up: Will receive a $40 in value prize from the list below.
  • Winner: Will receive a $60 in value prize from the list below.

You will have the choice between:

  • A reasonable amount of games (3 or less) totaling (before tax) up to the value of your prize from Steam, Origin, or GreenManGaming.
  • Gift card code matching the value of your prize for one of the following places: Nintendo eShop, PlayStation Store, Xbox Marketplace or GameStop. (For US residents only)
  • Donation to a charity of your choice.
  • FLARD (Note: FLARD may explode and/or lead to a series of comedic and likely dangerous scenarios)

Prize options are not guaranteed and are limited by the availability of the given prize at the time of collection.

Winners will be announced at the first State of Sponge following the close of the Plugin Competition

9 Likes

How would I go about hard-coding hashes for config like files from e.g. git, that are supposed to change mid plugin-release? Should I remove these downloads completely and just updated the plugin for every fixed typo?

Also is that meant to say Summer Plugin Competition?

Keep up the good work :slight_smile:

I believe best practice would be maintain the downloads for each version, i.e /v1/example.conf, /v2/example.conf and release a new version when you make a change. Paging @Grinch to check.

And we do absolutely mean to say the Summer Plugin Competition, some of us happen to live in the southern hemisphere you know!

2 Likes

If a plugin contacts something like the Discord API, it would be technically downloading things to operate. However, that’s impossible to run hashes against. Would that be classified as an exception?

Would “signing” each file provided by a server with something like GPG and then verifying the file’s signature on the plugin side of things be sufficient for SHA256?

If SSL certificate verification is done on the plugin side (double-checking certificate authority, etc), would that be sufficient for SHA256 hashing? It effectively accomplishes the same thing.

It is my understanding that SSL/TLS (with a valid certificate) is a must for all downloads anyways - the actual file itself still needs to be hashed though, just because you have a secure connection does not mean that the server can’t have incorrect or changes files.

I believe that GPG signing would more than cover the hash issue - that being said iirc GPG is harder than basic hashing so…

Things like a discord API that aren’t actually downloading runnable code won’t be as much of an issue I do not think - you just need to make sure it’s documented. This was more aimed at plugins that wanted to download entire huge libraries (like kotlin runtime) I believe. I believe that with a discord API, You would primarily be making API calls to an outside connection, however you will not be like downloading an executing code from discord…

1 Like