Consistent Egg Identifiers

Is there an existing feature request for this?

[X] I have searched the existing issues before opening this feature request.

Describe the feature you would like to see.

Honestly, I could have sworn there was an issue for this already, but I cant find it.

Simply, Eggs in the panel have UUIDs, however, the exported json files do not.

The UUID generated in the panel is already visible to the client through the API, but its kind of useless on any panel other than my own.

Therefore, there is no way to identify eggs across panels at all, with the exception of feature strings, which is not enough for adding features without needing to go and add feature strings to everyone's panels. Given the lack of an egg update api (and, of course, a lack of identifiers per-egg) It is not currently possible to work around this without modifications.

Describe the solution you'd like.

The simplest solution is to add the UUID to exported egg json files.

Alternatively, some other kind of unique identifier (like minecraft:java:some_paper_fork - which has added benefits, like enabling themes to add a thumbnail based on that ie. minecraft:java:paper could enable a papermc thumbnail - or many other options.)

Want to have two versions of an egg? alter the id. pterodactyl:minecraft:java:paper could be what the built in paper egg looks like.

This could make updating easier, and open the door to egg repositories (perhaps sourced through parker's egg repo) perhaps with some kind of identifying json file that panels can use to locate eggs in a repo? (i could easily see a gh action being used that scans for all egg files and spits out a new json file - published through a gh pages page perhaps? - that you then point your panel at)

Alternatively again, if those identifying identifiers aren't feasible, some additional metadata about what the egg is (ie. minecraft, java, papermc, bukkit_api, etc) could allow for more granular control over what we want to do with regards to any specific server. (ie. a plugin downloader only being available for bukkit_api eggs) this is already technically doable with the features array, but eggs don't really have any other "features" than that which pterodactyl supports, making enabling them on supported eggs tricky with the lack of thorough existing metadata, and this cannot be worked around due to a lack of consistent identifier, hence this issue. (For the record, this would make it much easier for me to implement custom features through my app without altering the panel, thereby making it plug and play)

Perhaps we need a wider issue about adding more data to eggs in general, and not just the exported files?

Additional context to this request.

This could be useful for external services that use the UUID (such as my featherdactyl app or panel addons) to act based off of the UUID.

Now, the "correct" way to handle this sort of thing is meant to be using feature strings in the egg. However, external services may not be able to add these strings to the egg, but if we can know the UUID, we can just tell our services that [list of UUIDs] should have [so and so feature] enabled.

Honestly, I could have sworn there was an issue for this already, but I cant find it.

There is no such issue; there was a discussion about this in the Discord server a few months ago though.

Therefore, there is no way to identify eggs across panels at all, with the exception of feature strings, which is not enough for adding features without needing to go and add feature strings to everyone's panels.

Feature strings are probably the worst way to identify eggs because they are only used by a handful of official eggs, and even fewer third-party eggs. You would get far more accurate results filtering by egg name and author.

The simplest solution is to add the UUID to exported egg json files.

As stated by you, there is no way to identify eggs across panels, so how exactly would this help? Egg UUIDs are only universal to the panel they were created in, not universal to all panels.

Alternatively, some other kind of unique identifier (like minecraft:java:some_paper_fork [...]

This could only work if there was a global or centralised system for managing egg identifiers, as well as a way to enforce these identifiers.

Want to have two versions of an egg? alter the id. pterodactyl:minecraft:java:paper could be what the built in paper egg looks like.

What would the semantics of this be? For example, with versioning?

Alternatively again, if those identifying identifiers aren't feasible, some additional metadata about what the egg is (ie. minecraft, java, papermc, bukkit_api, etc)

I feel like this could lead to unnecessary clutter in egg metadata. Also, wouldn't the egg name suffice in this case?

this is already technically doable with the features array, but eggs don't really have any other "features" than that which pterodactyl supports

Let's not pollute the definition of egg features. Egg identifiers do not correlate to egg features.

Feature strings are probably the worst way to identify eggs because they are only used by a handful of official eggs, and even fewer third-party eggs. You would get far more accurate results filtering by egg name and author.

That's what I was saying.

As stated by you, there is no way to identify eggs across panels, so how exactly would this help? Egg UUIDs are only universal to the panel they were created in, not universal to all panels.

By storing the UUID in the json file, panels that import it will share the same UUID Granted, given that UUIDs are currently random and per panel, it might make more sense to use a different system to avoid conflict with already-imported eggs.

This could only work if there was a global or centralised system for managing egg identifiers, as well as a way to enforce these identifiers.

Not necessarily. Anything that uses the same identifier, whatever it is, would be considered an update for the existing egg. If thats undesired, edit the identifier to add some flavor text or something.

It does make it simpler to design a centralized system for managing eggs though.

What would the semantics of this be? For example, with versioning?

Any egg json file that uses an ID that is the same as one you already have installed should be considered an update. (perhaps a warning if the new egg was exported after the currently installed one)

I feel like this could lead to unnecessary clutter in egg metadata. Also, wouldn't the egg name suffice in this case?

Just the egg name would make it possible to create a map between names and features, but just including information about what's expected to be in the egg could be useful for, say, enabling a plugin manager only on bukkit-enabled servers like paper or [insert fork here]

Granted, that might be doable just with the feature list, so maybe we ignore that for now.

Let's not pollute the definition of egg features. Egg identifiers do not correlate to egg features.

I only bring it up because its the only current workaround, which requires that eggs actually have them.

Of course, thats irrelevant if panel owners don't update their eggs...

By storing the UUID in the json file, panels that import it will share the same UUID Granted, given that UUIDs are currently random and per panel, it might make more sense to use a different system to avoid conflict with already-imported eggs.

If UUIDs were to be accepted by the egg upload service then there would need to be a way to verify them, otherwise they are nothing more than a random assortment of characters.

Not necessarily. Anything that uses the same identifier, whatever it is, would be considered an update for the existing egg. If thats undesired, edit the identifier to add some flavor text or something.

It does make it simpler to design a centralized system for managing eggs though.

If there is no identifier verification then its purpose is meaningless, because anyone could put anything and the panel would just have to accept that as the identifier. You would quite literally be better off using egg names as a "consistent" identifier.

For the record, a centralised system doesn't mean having only one single source of truth. If we think in terms of distributions, Parker's repository would obviously be one that the panel uses by default, and third-party ones could be added over time — or better yet, make it configurable list of trusted sources from within the panel.

Any egg json file that uses an ID that is the same as one you already have installed should be considered an update. (perhaps a warning if the new egg was exported after the currently installed one)

This would absolve egg versioning, nothing in the identifier or the current egg model would denote a different version from the one you have imported already.

If UUIDs were to be accepted by the egg upload service then there would need to be a way to verify them, otherwise they are nothing more than a random assortment of characters.

What do you mean by verify?

This would absolve egg versioning, nothing in the identifier or the current egg model would denote a different version from the one you have imported already.

exported_at should work, though egg versioning is not a bad idea in general, as it makes the whole idea of updating eggs easier.

If there is no identifier verification then its purpose is meaningless, because anyone could put anything and the panel would just have to accept that as the identifier. You would quite literally be better off using egg names as a "consistent" identifier.

...you know, it didnt occur to me that the name was available. Might poke at using that for now...

Still, names cant fully replace ids, since they can be arbitrary and its entirely possible for eggs to share names.

Still, names cant fully replace ids, since they can be arbitrary and its entirely possible for eggs to share names.

This is exactly what I mean in my first point about verifying UUIDs/identifiers: they can be literally anything which would make it a redundant field in the egg model if there's nothing to verify it. Simply being an excuse for external users to falsely compare against is not a good enough reason to have it IMO.

exported_at should work, though egg versioning is not a bad idea in general, as it makes the whole idea of updating eggs easier.

Let's say you get a new Minecraft egg, it later becomes capable of supporting extra features upstream and is subsequently re-exported with the changes to support them, so you update the egg - that's a new version. Shortly after, a minor yet annoying typo is found in the name or description of the egg, so it gets updated and exported again. According to exported_at, that's a new version of the egg. See the problem here?

This is exactly what I mean in my first point about verifying UUIDs/identifiers: they can be literally anything which would make it a redundant field in the egg model if there's nothing to verify it. Simply being an excuse for external users to falsely compare against is not a good enough reason to have it IMO.

Yes, and "anything" is fine as long as the ones making the id know its meant to be unique. Names can work, but is not reliable because who is writing the name of any egg with that in mind?

Thats not to say there shouldnt be some kind of guideline or syntax for an ID, but as long as they are unique enough, any collisions becomes an admin issue, and feels out of scope to me. Parker's repo is where most people get their eggs, so that could easily have an action asserting ID-uniqueness.

Let's say you get a new Minecraft egg, it later becomes capable of supporting extra features upstream and is subsequently re-exported with the changes to support them, so you update the egg - that's a new version. Shortly after, a minor yet annoying typo is found in the name or description of the egg, so it gets updated and exported again. According to exported_at, that's a new version of the egg. See the problem here?

Eh, I think we can both agree that we should have egg versioning, but that should be kept to its own issue, which i think already exists? Bit out of scope for this issue, at least. (Though, if this gets implemented, that so-called egg version/update issue would have one less blocker. Not really sure what the proper procedure is to connect those topics though.)

pterodactyl / panel