Shouldn't we maybe create a more generalized version? I think the mappings might diverge more with every update and just adding more class names won't last very long @Ingrim4 ?

I completely agree that splitting the code into more generalized components for increased fail-safety would be advantageous. However, it's important to acknowledge that such a redesign could potentially break compatibility with certain plugins if not executed carefully. This is definitely something that could be done in a future redesign of a new API which tries to separate the API from the implementation (Somewhat related to this comment).

I have an idea how to make it work for mojang mappings and spigot obf, we could use https://github.com/jpenilla/reflection-remapper library to make it so we can use only spigot obf then use this library to convert it to mojang mappings so we can make it generalized and not add additional classes to every method out there. Tho we need to download the mappings files in the plugin(but it will take a lot of space) or download it from the web and put it in the plugins folder

I have reservations about mandating unrestricted web requests for the plugin's functionality. Additionally, the suggested library appears to offer more features than necessary, possibly introducing unnecessary complexity. For ProtocolLib, a solution tailored specifically to its needs might be more appropriate. Ultimately, these considerations tie into the potential redesign I'm planing for certain aspects of ProtocolLib. While this may not be immediately feasible, it's certainly worth exploring in the future. (Also mappings don't ensure mojang won't rename things in the future)

This will work for the moment...
But it's not a "typo" ! ;)
The unobfuscated server has a lot of different names than the obfuscated one...

How is Visiblity not a typo. Its missing the third I

How is Visiblity not a typo. Its missing the third I

oops, didn't see the second commit ;)
Yes , you're right...