fabricmc / fabric-meta Goto Github PK

Would be great to have also access to the latest versions of the API.
Like this:

/v1/versions/api

/v1/versions/api/:game_version

The endpoint /v2/versions/game sometimes shows 23w06a and sometimes not.
This is looks like a cache issue to me.

Why pretty printing?

( public static Gson GSON = new GsonBuilder().setPrettyPrinting().create();

I mean this is an api...that gets used by probably bots and not humans. It increases traffic and file sizes (for them, who download it). Also it affects performance.

Has this an intention?

I'd think about an extra parameter like ?pretty=true that is false by default.

For some of the responses the meaning of stable is not described in the README (would be great if that was added), however for /v2/versions/intermediary and for /v2/versions/yarn it is, and the current behavior does not match the described one. For both of them the description says:

stable is based of the minecraft version

However https://meta.fabricmc.net/v2/versions/intermediary has stable: true for all entries, even for the ones create for snapshot Minecraft versions.

https://meta.fabricmc.net/v2/versions/yarn returned that 1.14.3-pre2+build.10 is stable. This can be seen in the example response in the README, and I was seeing it at that time as well. However currently its value is false. It appears it is always setting the latest build as stable. While writing this issue, this is 1.14.3+build.9, however 1.14.3+build.8 or any other older build for that version is not stable despite it being for a release Minecraft version.

It would be useful to have a list of dependencies/libraries (that Fabric Loader needs at runtime) available, either with the /v1/versions/loader endpoint or a separate endpoint.

Note: There are no plans to remove or deprecated the V1 or V2 API's

This issue is a place to discuss/track ideas for a V3 of the metadata API. V1 and V2 were created without a lot of thought and contain data that is no longer required. The goal of V3 is to provide a consise API and prepare for future addions. This issue does not contain the final form of the API.

Please leave any suggestions in the comments on this issue.

V3 high level features

• Installer versions
• List of intermediary versions
• List of game versions
• List of loader versions
  • With loader release date/time, this can be acquired by the modified time of a jar entry.
• Server launcher jar, for given versions
• Client profile json
• Better defined documentation/schema
  • Note that maven ids can have classifiers
  • Don't expose the maven hostname where possible
  • Document fallback maven/meta servers
• Anticipate loader only running on newer Java versions, not planned to be used yet.
• Support "intermediary-less" install of older versions.
• Use v2 intermediary in prod

Future additions

• Fabric API versions, with supported Minecraft versions
  • LIkely driven by some SQLite DB
• Fabric Loader's "semver" compatible Minecraft version.

Misc changes

A list of changes to be made to fabric-meta that does not relate to to the public API.

• Add checkstyle
• Add some unit/intergration tests, to ensure that we dont break the existing endpoints
• Update all dependencies, and update to Java 21 for some loom goodness
• General code cleanup

API

/v3/versions/installer

Returns a list of all installer versions.

[
  {
    "name": "net.fabricmc:fabric-installer:0.11.2",
    "stable": true
  },
  {
    "name": "net.fabricmc:fabric-installer:0.11.1",
    "stable": false
  }
]

/v3/versions/intermediary

Returns a list of all intermediary versions.

[
  {
    "name": "net.fabricmc:intermediary:1.20.4"
  },
  {
    "name": "net.fabricmc:intermediary:1.20.4-rc1"
  }
]

/v3/versions/minecraft

Returns a list of all game versions, older versions that do not have an intermediary name are marked as legacy.

[
  {
    "id": "23w60a",
    "java": 17,
    "stable": false,
    "legacy": false
  },
  {
    "id": "1.20.4",
    "java": 17,
    "stable": true,
    "legacy": false
  },
  {
    "id": "1.4.7",
    "java": 8,
    "stable": true,
    "legacy": true
  },
]

/v3/versions/loader

[
  {
    "name": "net.fabricmc:fabric-loader:0.15.2",
    "java": 8,
    "stable": true
  },
  {
    "name": "net.fabricmc:fabric-loader:0.15.1",
    "java": 8,
    "stable": false
  }
]

/v3/server/:game_version/:loader_version/:installer_version

/v3/server/:game_version/:loader_version

/v3/server/:game_version

/v3/server

Provides a download for the server launcher jar, the versions can be omitted to use the latest stable version.

/v3/client/:game_version/:loader_version

TODO: Come up with a new stable schema for custom launchers that will not change. Likely very similar to the current json.
TODO: also offer this without intermediary for none Minecraft installs.

/v3/client/:game_version/:loader_version/vanilla

Provides a profile json in the format only for the vanilla launcher. Look into the "modern" schema as noted in #12 This should only be used by launchers/installers that utilise the vanilla Minecraft launcher. This may change if required.

Hey there

I'm working on a little tool for modders and modpack makers.

The tool is basically a launcher, but for servers (for local testing and debugging without a dev env). To speed up instance creation and to save bandwidth, the launcher caches downloads.

To ensure a download is not corrupt, it checks the file against a hash (SHA1, SHA256 etc). Currently, your meta API doesn't include file hashes. While it's possible for me to get these from the maven, some cases like the server jar generated by the jar endpoint, won't work, since the file is modified before being served by the API.

I guess I can just make a request to get the SHA, but to build an initial hash base would require a LOT of requests, which I don't think any of us want lol.

This feature could also be useful for other launcher and tool devs, that use a similar caching system

I am even willing to make a pull request for this, if it's something you'd be interested in adding

Hello! I'm not sure whether this issue is related to the Fabric Meta project, but I think you'll be able to figure out where to redirect this.

Currently, Fabric uses a mix of old and modern formatting of the version JSON file.

GET https://meta.fabricmc.net/v2/versions/loader/1.16.5/0.11.2/profile/json:

{
  "id": "fabric-loader-0.11.2-1.16.5",
  "inheritsFrom": "1.16.5",
  "releaseTime": "2021-02-28T13:24:03+0000",
  "time": "2021-02-28T13:24:03+0000",
  "type": "release",
  "mainClass": "net.fabricmc.loader.launch.knot.KnotClient",
  "arguments": {
    "game": [
      
    ]
  },
  "libraries": [
    {
      "name": "net.fabricmc:tiny-mappings-parser:0.2.2.14",
      "url": "https://maven.fabricmc.net/"
    },
    ...
  ]
  ...
}

Here, it uses the arguments property, which is a modern formatting property, it is split for both game and jvm, legacy formatting only used minecraftArguments. But then, in libraries, it uses a simple combination from old formatting — name (library coordinates) + url (Maven repository URL).

The correct way to list libraries in modern formatting is by providing name (library coordinates) and:

• downloads property, which is a map of downloads where the key is a classifier of the download. It supposed to be "artifact" for libraries downloads.

  Each ‘download’ has to contain:

  • path where the library is installed, relative to libraries folder;
  • sha1 — checksum of the library file, preferably created during the build process;
  • size — the size of the library file in bytes;
  • and url — full download URL of the library file.

Here's the example from the official Mojang launcher meta:

{
  "downloads": {
    "artifact": {
      "path": "oshi-project/oshi-core/1.1/oshi-core-1.1.jar",
      "sha1": "9ddf7b048a8d701be231c0f4f95fd986198fd2d8",
      "size": 30973,
      "url": "https://libraries.minecraft.net/oshi-project/oshi-core/1.1/oshi-core-1.1.jar"
    }
  },
  "name": "oshi-project:oshi-core:1.1"
}

The modern formatting is clearly superior as it is lacking this element of unpredictability — you're giving Minecraft launcher clear instructions on where to search for the library, where to download it, and what file to expect in return. It also gives Minecraft launcher the ability to check integrity of the library files before firing up the game.

Current legacy formatting allows for the following things to happen:

• If Fabric sites get hijacked, attackers can put a fake library file that will be loaded and launched by the launcher, it then gets to do whatever JVM can do when run in the context of the user.

  Of course, with Fabric this can happen even with modern formatting because the client JSON is still downloaded from the remote resource during installation. Projects like Forge try to mitigate this issue by creating separate installers for each version, hosting client JSON within the installer itself.

• In a case when the player has an unreliable internet connection, due to random disconnect or hiccup, a library file might be incorrectly downloaded. The launcher then has no way of checking its integrity besides checking whether it exists or not, and if it does, it will attempt to launch Minecraft with a broken set of libraries, causing the crash with a generic unhelpful message:

  

  Even if the player will be able to access the launcher log, the only thing they'll see is:

  [Info: 2021-02-28 14:42:01.783255619: GameCallbacks.cpp(162)] Game/game () Info Error: Could not find or load main class
  

  This is a standard Java message, googling it provides close to zero helpful results to an unadvanced user.

• [Added (might be recent change)] It seems that using mixed formatting also causes launcher to actually send additional requests every time game launches to retrieve .sha1 files for libraries (e.g. for net.fabricmc:tiny-mappings-parser:0.2.2.14 library it will retrieve tiny-mappings-parser-0.2.2.14.jar.sha1) to check their integrity. It might be a new feature, or there might be something to do with the launcher ignoring library with incorrect SHA-1 — previous point describes a real case, although it should be prevented by this point (weird!).

I hope this little bit of research brings some awareness to the consequences of using mixed legacy formatting in modern versions of the launcher. I hope Fabric will be able to follow the steps to resolve this issue by generating a modern client JSON during the build of the next Fabric versions, ensuring safety and a nice experience for the players.

Describe the bug
The /v2/versions/loader/:game_version/:loader_version/server/json endpoint has wrong releaseTime's.

To reproduce

1. Choose a random game version and a loader version
2. Go to the before mentioned endpoint and fill out the blanks, a finished url example: https://meta.fabricmc.net/v2/versions/loader/1.20.1/0.15.11/server/json
3. Look at the time or releaseTime, they are both wrong.

Expected behaviour
The specified endpoint's releaseTime/time should be the correct date, not a random, recent date.