Custom skins? #1182
Labels
No Label
#P1 CRITICAL
#P2: HIGH
#P3: elevated
#P4 priority: medium
#P6: low
#Review
annoying
API
bug
code quality
combat
commands
compatibility
configurability
contribution inside
controls
core feature
creative mode
delayed for engine release
documentation
duplicate
enhancement
environment
feature request
gameplay
graphics
ground content conflict
GUI/HUD
help wanted
incomplete feature
invalid / won't fix
items
looking for contributor
mapgen
meta
mineclone2+
Minecraft >= 1.13
Minecraft >= 1.17
missing feature
mobile
mobs
mod support
model needed
multiplayer
Needs adoption
needs discussion
needs engine change
needs more information
needs research
nodes
non-mob entities
performance
player
possible close
redstone
release notes
schematics
Skyblock
sounds
Testing / Retest
tools
translation
unconfirmed
mcl5
mcla
Media missing
No Milestone
No project
No Assignees
16 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: VoxeLibre/VoxeLibre#1182
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What if Mineclone had an optional clientside mod? And in it you could add custom skins of your own which would then be utilized by the server in order to have a custom skin.
is this possible?
I think Minecraft does it right by having a centralized skin system, because they can be misused and abused. It pays off to be careful about what kind of skins you allow clients to upload, process and display.
Proper consideration to such things leads to a more elaborated solution. We definitely need a way for people to use custom skins in multiplayer worlds, but we should do it right. This brings up some questions:
This is the kind of thing that's worth bringing up in the Minetest community for proper design and cross-utilization.
Yea, let's make auth+skin servers for mcl. They should be optional & open source ofc.
Great!!! I was waiting for sotmethink like this for a long time!!!
Ok. Node, Ruby on Rails, Rust, Flask, Go or PHP?
Why would we vote on this? :) It's ultimately up to whoever builds it. But Node, PHP and Flask (Python) are much more approachable to a lot of developers - if that matters. I'd pick PHP because that's my baby, although I'm ok with JS as well. :)
My ranking:
About the general concept of the auth servers:
There should be two MineClone2 settings releated to this:
disabled: will just disable connection to an auth server completely. Players need to pick ingame between Alex ans Steve.optional: If player name and password hash of a player that logs in match the data on the auth server, the player counts as logged in and the skin is set accordingly. If the player is not found in the DB or the password hashes do not match, they can play anyway, but they have to use the ingame skin picking.protected: Same as optional, except that the server will deny registration of any new users using names that are registered by the auth server. Any new players that don't have a connected auth account or old players that use the name of a registered account that is not owned by themselves are not affected.registration_mandatory: Any new players that register need to be authentified. Old players that don't have an account / use the name of a registered account that is not owned by themselves are not affected.mandatory: The server will only let authentified players play.Amazing! But this system should also support multiserver.
If the user could provide a unique string derived from the username and user id, like Blizzard and others have (User1234), that could be used to load the correct avatar and not send the password hash through who knows what insecure networks.
Could we allow users to "build" their character in game? The character would be represented as a wire-frame that players can fill in with colored blocks.
Users will not be able to edit their skin in-game by any means.
How to solve the photo name problem (and some file size problem): name textures by its hash
What is the photo name and file size problem?
The names can be abused to be very long and cause file system issues, or to have names that could potentiall overwrite existing files in certain configurations and (poor) implementations. So the file names could easily be "sanitized" by replacing them with a fixed-size hash that would anyway be associated to a user account, so no need for a certain file name.
And if we ever want readable names, we could only allow [\w]+ by removing the non-alphanumeric characters, then trim the filename to a safe length.
Are you guys aware of this feature in MT Crafter? It basically uses the HTTP API to download a PNG skin file at run-time and apply it to the player. It's super neat. Just build on that?
https://github.com/oilboi/Crafter-Minetest/blob/master/mods/skins/init.lua
I am aware of that feature. Using the HTTP API to download a PNG skin file at run-time is planned, but I want to make an user-friendly auth server, so users don't need to create a github account for setting their skin (and you can have a different ingame name than github name)
Yes, that'd be the next step. The auth server would be centralized however? Maybe with the option to self-host?
The server would be open source, with an official instance running that is used by default, but people can change the setting to use a different auth server and can also start their own auth server. (Similar to the Minetest server list)
Cool. I reserved skins.minetest.land for the purpose.
Why
skins? This service would provide skin AND auth.Because it's a service for skins and including "auth" in the domain name adds no benefit. It's better to keep it simple.
If the service grows to include more features than setting a skin maybe there's a better name for it, I don't know.
Make it fun!
@EliasFleckenstein03 If you want to create an auth system, do you plan to support optifine capes? That would be great!
What would an "optifine cape" be in the context of an mcl auth system?
Yes, optifine capes are not handled by mojang, but I would be cool to be able to customize per player on the auth server capes (capes are basicaly attached banners)
@EliasFleckenstein03 There is one problem with optifine capes handle by auth system ; how can auth system be hable to to hande custom banners patterns? (#53)
@AFCMS They can be designed and uploaded to the web, then pulled by the game server.
So, I need to add my custom banner pattern with a mod AND on the auth server?
No, the MT server can download it dynamically from the auth server.
Capes are basicaly banners. According to #53, how to add banners patterns with mods and be compatible with auth server?
Yes, I like this idea
Can't we make a skin editor with formspec? Then it would automatically have the right file size and you could script it so that the result is a *.png image file. And then you can also make your skins ingame. Or you could do it like in the MC Pocket/Bedrock edition.
I think we agreed not to do this. So no ingame editors.
Can be done technicaly, but not a very good idea. (grefing servers with spamming skin creation, bad performances, etc.)
does this mean that minetest players now have to have minetest accounts overall, or is this just for changing the skins on the particular client?
I think since Fleck has left he idea of an auth server is dropped, or at least very very low priority. Sadly.
If I manage to have enough skill to folow his design idea, I might try (much later) :)
The idea was to create an optional auth server serving skin and capes, so you no longer need to ask the server admin to add your own skin to the server
@cora which is you opinion about this issue?
While generally of course such an auth server would solve a lot of problems, not only would it have to be written but someone will have to run it. Which would be kind of an indefinite commitment.
i mean there is skins db .. no an auth server but a commonly used skin database. Iirc the skinsdb mt mod didnt work with mcl2 for some reason. Maybe getting that to work would be the simplest solution to skins.
Of course people can use everyones skins in that scenario. One way of fixing that I thought of just now would maybe be something like upload skin with name server:port:playername to skinsdb and mcl will automatically take care that only this playername can use it?
That would solve the skin stealing without auth (the auth would be to be the first one to upload it under that name to skinsdb).
Of course that is also something that would have to be made.
can't be lazy either way ^^
I looked into this issue and here is my proposal:
Architecture
Go is used as backend, providing a REST API for both frontend and mineclone2 servers.
Fiber and GORM modules are used for the web server and the database
React is used as frontend.
Target
You can create a account on the service, by using the frontend or the REST API.
You need to provide a email address, that will need to be verified by email sending. (maybe also require a captcha? idk)
Each of these accounts own a limited (5? 10?) list of users, so they can have multiple accounts on the same email.
An option to disallow connecting with multiple users from the same account is availlable to the mineclone2 servers.
The frontend/API exposes a public list of accounts, exposing datas like owned users, last connection date, etc
Accounts have a rank, with some users beeing moderators, with the ability to ban other accounts or byass their own amount of users
The frontend ui should be very good, with 3d skin preview, good CSS, etc
In my opinion, there should be an open source skin server server software (c++ (?)), and each mineclone 2 server should set its own server in some sort of config file.
The skin server software really needs some sort of authentication, my idea would be that you create an account with password, it should have the same username as your minetest account, then, the mineclone2 server tries to get your skin file from the specified server, and if the skin server returns null, it uses steve or alex.
Also, there should be a maximum file size for a skin so that people dont try to crash the server by simple uploading a 1.2GB png file or something...
Yeah, there could be an official Mineclone2 skin server which is default for all mineclone 2 servers, but there should be a way to host your own one.
C++ isn't really suited for this kind of task I think...
This is the minimal requirement, but I would like to a bit more if possible :)
Definitly yes
Just listing technologies alone seems too little for an architectural proposal IMO.
I think you would only need to specify the API, then everyone could implement it.
My brainstorm about the auth + skin system:
Users
Users can register and connect on a web interface.
The folowing is stored in a PostgreSQL database:
The user can then (still on the web interface):
Servers
Minetest servers who want to use the auth+skin API need an API token, associated to a server created by a user in the web interface.
Since the SRP hashes Minetest uses are technically breakable nowdays (difficult, but not impossible), servers cannot get them for any username by default.
Users must allow the server to get their SRP hashes from the web interface, so they still need to trust the servers they play on.
We could add somme kind of "official" or "validated" servers which bypass this restriction.
A server would have:
Technical part
The Minetest auth handler is kinda limited, as there is no way to kick a player with a message.
minetest.register_on_prejoinplayer()allows to do so, so we can get the SRP hash for the username inside this callback and store it for the auth handler if availlable, else just kick the player with a message.The major problem is that the HTTP API works asynchronously, so we need to make it sync artificialy in the
register_on_prejoinplayercallback:Even with a very low timeout value and a powerfull server running the system, the delay is questionable...
Maybe we could use the async env to fetch the SRP? And kick the player later after the
on_prejoinplayer? IDKOr maybe ratelimit the number of connections by seconds to (kinda) avoid DDOS? Maybe a server command to disallow any connection to reduce lag?
The skin can be applied to the player later, using a async http request.
Aditional features
"Friends" system
Allow users to mark other users as friends and know if they are online on a server.
This require a way to track user's connection to Minetest servers.
Optifine capes
Add optifine-like capes, that can be earned by having contributed mcl2, having joined the auth service 1 year ago, etc
Singleplayer
For singleplayer, I think we could think of a game setting specifying a username to take the outfit from.
Since the API endpoint to get a user's skin wont be restricted, it would be easy to implement.
what does "password encrypted traditionally" mean? And where is the key to decrypt it stored? If it's in the same db you might as well store the pw in clear text, no !?
I do hope you mean (salted) password hash and not encrypted password however as SRP certainly does not store the password on the server.
Not sure I understand the security scheme as laid out.
The upside of schemes like SRP is that compared to the traditonal method of storing a password hash it's supposed to make offline dictionary attacks impossible i.e. to verify a guess you need to talk to someone who actually knows the original pw every single time ( https://en.wikipedia.org/wiki/Zero-knowledge_password_proof )
Storing the pw itsself in any way should NEVER be done and storing unsalted hashes should also be avoided - even salting it with the username is better than no salt as it makes the search space for a brute force attack considerably larger basically making rainbow table attacks impossible.
In short you want to avoid a situation where someone who has a copy of your database can recover the clear text passwords of people.
Regarding the async thing: How about it just does the normal mt login and regardless and when the answer from the server comes in it applies the skin and stuff sent from the skin server. Until that happens it could temporarily revoke interact and/or shout depending on configuration. If the pw turns out to be wrong or the answer doesn't come in within some time it could just kick the player similarly to how IRC nickservs do it.
The thing is from what i remember the timing between prejoinplayer and joinplayer can differ considerably - by minutes even - depending on client side performance, network connection and/or if media downloads still need to happen.
@AFCMS I think it would be nice to not have the skins server as a MCL2 only feature but open it up to all Minetest servers.
Also while you are at it, why not replace the SkinsDB site which is junky and unmoderated.
Now Minetest will finally have feature parity with Manic Digger! lol
I mean password stored like most sites do (the SRP thing is the same password, but the way its stored in minetest database)
This incompatible with optifine capes + player model's UVs are not the same between mods I think
Actually right now player_api, 3d_armor, mcl_armor are compatible with the same skins. However I think player_api does not have capes support. That just means capes would not show up for player_api. What is so bad about that?
hmmmn... I was thinking about this, and then saw it in the projects.
If we made it an easy to use API, people could just make mods that use that, and install them onto their server for the players.
Just a thought.
Though I have to say, I want an Iron Man skin for my own server. lol. Not trying to introduce copyright issues with that statement... just saying that it would be nice to have a customizable skins thing where we could make our own mods that interface with it and add in skins.
Because yeah, with the centralized skins server, someone has to monitor and vet each skin set to prevent abuse. I mean, things like Tumblr and dick pix taught us that if you give a person a way to put up pix that can be seen with little to no moderation that it will be weaponized... and the last thing I want to deal with is some irate parent going off on me because their kid was exposed to pornography while playing mineclone.
Ok, so regarding this discussion and another one on Discord, I am comming with another proof-of-concept:
Dropping the auth server thing entirely, at least until Minetest implement a serious remote auth protocol.
We have a server, which provides an API and a frontend similar to http://minetest.fensta.bplaced.net/ but a bit better looking lol
Users can upload skins on the server.
Each skin have an unique UUID, a PNG data (can be obtimised using OptiPNG in the backend), an creator (user), something to tell if the image is approved or not and something to make the skin private or public (+ description and maybe license).
Every parameters can be changed, except the PNG data.
Skins marked as public and approved by moderators are displayed in a global page, accessible to anyone.
The other ones are only shown in users's lists.
Minetest servers have a way to make a specific player chose a skin UUID, and try to fetch the skin from the skin server. Will need the specific skin to be approved.
So we will have the ability to have a centralized skin server, that anyone can use... but it's on us to view and approve the skins before they can be used? (Checking my understanding of this, so that I am clear on it.)
Basically yes.
How do Minecraft custom skins work?
As far as I know, your skin is connected to your account, and that's how you can customise your skin?
Sadly, Minetest does not seem to have as much functionality in regards to accounts.
The first idea was to make a complete auth server with skins linked to it, but sadly Minetest have a too poor API to allow implementing it properly.
So partially needs engine change?
Yes for a complete auth server, no for a skin system.
When I did mine for minecraft, I had to find the skin that I wanted to use, download it. Then, I reuploaded it to my profile using the launcher, and had to wait for it to update. Then I could use it locally and in games on people's servers. Not a completely painless process, but it at least propagates wherever I go with it.
Is it based on that project? Their code is badly outdated (PHP 5). Is "ours" available for public testing or even contributions?
Nothing is published yet, its just a proof-of-concept.
I have still have some prototypes locally xD
How does that work?
It was just a proof of concept lol
Its possible to do using a mod.
If the user has a private skin they need to past in the UUID I guess? Must users wont know how to do that.
What about letting the user assigning a password or passwords to their skins. The passwords are stored on the server in plain text or reversible encryption. The user can login on the server and reference their passwords. When the user wants to use one of their skins on an MT server they type in their email and a password associated with the skin.
The main difference between using a UUID is that it is easy to type, the user can assign as many passwords as they want per skin, the user can change the passwords themselves.
Then, shouldn't this be an "Access Code"? I make the distinction here, because of the fact that people see "password" and they immediately type in the same password that they use on 30 other sites. Not saying that that is an intelligent thing to do, but... it happens more than anyone would like to admit. (Especially with younger players.)
Maybe making a change to how it's labelled will change the immediate mental reaction, and prevent username / password combos from being easily viewed. Just a thought.
Skins of common Minetest skin mods seems to be compatible (any mods that aren't? every one I used were compatible with mcl2 skins, and mc ones with minimal fixes), so I am thinking of a generic Minetest skin server serving 64x32 skins, detached from mcl2, but with official support rather than a mcl2 specific server.
Since we don't have a "mineclone2" domain name, it will also be more consistent with "skins.minetest.land".
I have much more than a prototype now (API, user accounts, docker-compose, skin files validation and storage, etc)
My plan would be to separate the skin server from mcl entirely, and to add official support for it.
@ancientmarinerdev Are you OK with that?
And @tacotexmex especially for hosting ^^
Ideally it should be as simple as a copy-paste, with just a button in the web UI. (minetest have now a decent copy-paste support)
The problem with this is that each "password" (or access code) must be unique, and so its much easier to find skins marked as private.
Private skins are accessible to anybody just like public ones (including servers ofc) using a route like so:
skin-server.com/api/skins/<id>. Public skins are shown on the search skin page, while private ones are not.If someone use too simple "passwords", then it's easy to find them, just by trying to define simple passwords for your own skins. Using an UUID makes it much more difficult.
About the male/female distinction in mcl2 can be done by adding something like a checkbox in the create skin page specific to mcl2. Default female skin seems to be compatible with male ones (you can set
gender = "male"in the meta file without any visual problem ingame, except a bigger arm size ofc)What do you mean by that?
That is why I said the email must be used as well.
About MineClone2/MineClone2#3058
If I understand correctly, currently the arms/legs are mirrored, but in mc they aren't?
It will obviously lead into incompatibility with a all-mt server if directly integrated, but maybe we can add support for them, but only for builtin and manually added skins?
Marked as private? What do you mean? Skins that you "Do not distribute!"?
Minetest under 5.4 (if I remember correctly) had annoying copy-paste issues under linux.
The email is used for user accounts on the web servers, not skins themselves.
Players are free to use a skin of the server without having an account on the server, just by knowing the UUID.
If you draw a custom skin for you, want to use it but do not want every player to get the same one easily because it's a beautiful one, you can upload you skin as private, so it will not be shown in the search tab of the web UI.
It will still be accessible to anybody, but require knowing the UUID. (the server technically does, but player shouln't)
Minetest doesn't have a context menu with a paste option so the user will have to use the shortcut keys. It would be a good idea to put that on the formspec and or on the website. Also the shortcut keys are different on Mac OS.
Nothing is stopping players from screenshotting your skin and just "reverse engineering" it, but I can see how that could be handy.
Actually the skin file is sent to everyone's computer but I'm not sure how easy it is to actaully get it.
supposedly, it's somewhere in your cache, for minetest.
I dunno if it's named or just has an id... but, it's going to be visible from looking at thumbnails that the os creates.
Yes, but most users won't know how to do that.
The point of the public/private distinction is to let people decide to share skins they made with others and some don't. As easy as that. The problem would have been the same with a complete auth server.
You do know that people have been doing that with their web cache for decades now, right?
I understand the point of the public/private distinction. And, I am good with it. And yes, I also get that it would be the same thing with an Auth server too.
I managed to get OptiPNG optimisation for skins in the backend 🥳
Bump.
@ancientmarinerdev @kneekoo @tacotexmex Can I have feedback for the above discussion?
I would like to know your opinion before working in a specific direction for nothing.
I have a quick question... :P
Is GreenXenith's Halloween skins (their halloween mod) compatible with our skins? And, if they are, can they be added to the skin server?
About "private skins" - it's technically impossible, as Minetest caches media. So we should definitely not advertise this as a feature, even if most players have no clue where to find the cache. Besides, skins can be replicated from video recordings, by manually drawing the pixels - they're not even that many in our game. :P Finally, having stuff resembling proprietary stuff is plain weird in a FOSS game/community - it goes against the whole concept of open.
About the service, it would be cool, but it should be of course optional and opt-in, so that you don't get messages/warnings if you're offline, or if you don't want the service to begin with.
About the code, I can help with PHP and JS.
skindbsupports private skins, and technically to get a skin on a server you had to send the admin and they manually add it a a private skin like that. And to also make sure these files are the smallest possible.The point of this service is to automate what
skindbdoes, by removing the need to interact the admin for adding a skin.Yes ofc.
Nice.
But I would like more feedback on the idea of making a Minetest skin server, not just for mcl2, and to add official support to it.
Personally, I like this idea.
I also think that you should be able to access your online skins in a local game... but it shouldn't error out or it should gracefully error... if it cannot connect.
Yeah, since the skin data associated with a skin uuid is immutable, you can basically download the data to a world folder and load it then needed, even if you can't load the associated metadata from the server.
This is something that would have to be discussed with the Minetest team. I think that official support would only be given if they like the plan and it's conceivable for them to host it or allow a third party to officially host it on their behalf. Have you talked to them about it yet?
No, no. The idea was just to split the skin server from mcl2, not making it official for minetest.
I found an idea for supporting both 64x64 and 64x32 skins.
We can let users upload any formats, and convert the skin to the other format in the backend, so we have an endpoint for each skin type per skin.
We need something to convert MTG skins to MCL2 skins
Why do you want to have both formats on the server? MT only uses 64x32. Allowing 64x64 upload might be helpful though so people can use MC skins.
MineClone2/MineClone2#3058
Thank you.
I tried to use an online skin converter for MC->Minetest skins, but it just made a skin that was garbled. Like, only parts of my player char was even visible, and the skin image file looked "not right"... it was a valid image, just missing most of the texturing.
I'd be one of those people.
About licensing of uploaded skins, should I add a license dropdown when uploading a skin?
We cannot realistically only allow skins shared under CC-BY or smth.
And add a disclaimer about some skins not being free?
Technically MC have the same problem, anybody can upload any skin.
Maybe we could let the minetest server see if they accept non-free skins?
Oh, and since I am new with this: xD
For email verification, can I just use a configured account (like a google one) and do the job with just the
net/smtppackage, or include a mail server like docker-mailserver in my docker-compose.yml ? Not a big fan of using a google account lol.I am not very familiar with the mail stuff (protocol, implementation, servers, etc).
This one is difficult. There's a bunch of hoops to make it go to the users' inbox, and not immediately to the junk mail folder. And, that only works until a few people mark it as junk, even if unintentional.
Personally, I would try to find a guide with a check list of steps, to do this. Because the mail in, say, PHP etc., will fail if there is any issues at all with the set up. It'll still send, but no one will see it show up. (Junk mail doesn't trigger any notifications.)
I made my repo public because I wanted to showcase it in my CV for my future school xD
Its ABSOLUTELY NOT production ready yet and most features still works only from the REST API.
You can give it a first look, I appreciate any advice here. I would prefer not getting direct contributions before having at least a fully working REST API linked to the frontend.
https://github.com/AFCMS/minetest-skin-server
Oh, and some stars would be great :)
Quick question here:
Is the 64x64 Minecraft skin support still planed? I would like to know because if no games use it I won't add support for them in the skin server.
If yes I will allow uploading both 64x32 and 64x64 skins and generate the opposite format dynamically (the 64x32 version will lose some legs details), and then give an endpoint for each format.
Oh and I got the school btw xD
For people like me who don't know what the difference is:
64x64 Minecraft skin:
64x32 Minetest skin format:
Basically Minecraft skins have the right and left arm and the right and left leg mapped to different places on the texture. Also the Minecraft skin provides an extra layer for the torso, arms and legs.
It would require updating the two player models and all skins and skin items in the game.
Congratulations! That is awesome.
Apologies for my delay in response. A thoughts after digesting this.
clean text password. Absolutely not, when you can easily hash, no way is it justifyable for a server to know password. If someone hacks, we are risking ourselves and user
authentication is complex. Often you use a bespoke identify provider so the complexity is kept there and it passes token for authorisation to service provider (your app). Integration is also non trivial.
less data is better. Password and email are I think are considered special data and if in Europe, GDPR may apply. Username is probably safer. It isn't like we are protecting key data, we shouldn't take more data than we need.
if the server is distributing non free assets, it opens you up to copyright risk, licensing etc.
starting with the most simple thing nad building on is better. Upload manually or through mcl2 and only access own and build on from it. Some of the requirements here make this seem like almost as big a project as mcl2. That's a lot of complexity for changing appearance that could be hidden below armour. If you guys are cool, fair enough, but maintenance work and hosting costs are factors to consider.
if you can upload through mod or client, you could create key and private key. Send one back that you store locally, maybe mod storage which can be used to validate.
These are just a few points. This is way too complex for me for benefits so I probably will not be involved in this. Happy to give feedback occasionally.
Bump. Is the Minecraft skin support still planned? I really need to know if it will be in the game any time soon to continue working on the skin server.
Thank you for this.
@AFCMS
I think the fact that no one is replying to your question indicates that on one is planning to implement Minecraft skins. I think it's a good idea and I might want to work on it some time but it's certainly not planned.