Implementation Discussion Thread: Client Core
Gaelan opened this issue · 14 comments
Here's a thread to discuss the implementation of the client core, the library which (official) UIs will use. This should handle the hard work of downloading mods, launching MC (or setting up another launcher), etc. Questions we need answered before we can start work on this:
- What technologies will be used to implement this?
- Can these technologies work with a small memory footprint?
- How hard is it to port a tool written with these technologies across OS X, Linux, and Windows?
- How will UIs interact this tool? What constraints will this place on the implementation of the UIs? Are these acceptable?
- Who will work on this?
For this discussion it would be great to have a more detailed list of which steps need to be taken to launch MC.
So what does a Launcher actually do.
If I remember it correctly there is not much more to it than setting some environment variables, class path and launch a Java process. A batch/shell script can do that.
One of the more difficult things is probably getting the logging right. (and don't do it like atlauncher).
Also: on Twitter it was shown, that the vanilla launcher will be improved in terms of logging and stuff.
I think we should consider using the vanilla launcher to start the game, because then we don't have to deal with user passwords and "remember login" at all.
I have an item on the wishlist for launcher agnosticness (not a word), so that users can use the launcher they prefer. I think a built-in launcher has its advantages as well. I am also yet to see a launcher that doesn't gobble memory. A little exercise: create a (vanilla) launcher profile with the Java jar set to /usr/bin/echo (or equivalent) to see the options passed to MC. A nice thing about handling auth in our launcher is that we can use Mojang accounts as our login system as well (our server side would need to emulate the flow for connecting to an MC server).
What benefits do you see from a built-in launcher?
Yes this kind of server emulation is possible, but to me it looks untrustworthy and it is against the Mojang rules and common sense to enter your credentials into another program.
And I thought the goal was to have a launcher without login needed.
Also it might become target to Mojang blacklisting.
Things a launcher also has to do, if we don't use the vanilla one: download the game and make sure that the game is owned. (we don't want to create a trivial piracy launcher, do we? There are already so many.)
A native launcher can certainly come later. My goal was no separate accounts (everyone should have a Mojang account later). I guess we can implement that later, if necessary.
EDIT: If we don't use Mojang accounts, we will need a separate authentication scheme for people to upload their mods under. I figure just having one account is better.
Mojang's stance is that they don't like 3rd party launchers, so I think we should use the Mojang launcher if we can.
Since Mojang doesn't have an OAuth API, people won't be able to login with their Mojang accounts on our system (unless they give us their Mojang login info, which is a terrible idea). Storing passwords in any way, shape or form is a bad idea, and prone to security risks, so we should probably just add "Login with Facebook/Twitter/Reddit/Github" buttons (all of those websites offer OAuth, and almost everyone will have an account on at least one of them.
To allow a vanilla minecraft server to check if a minecraft account is authenticated Mojang already implemented something like oauth that we could abuse to authenticate users without seeing their passwords.
But only because it's possible, it does not mean, that it is a good idea.
Yeah, they're using Yggdrasil, which is fully documented here. We could use it, but it'll still require people to enter their info on our site. We'll POST them directly to Mojang and not actually do anything with it, but I still don't like it.
Yes, I totally agree.
I think using Mojang accounts is best, because we get unique usernames and everyone already has one. We can always offer two options: enter Mojang login, or connect to a server we run using the Vanilla client to get a token.
Using Mojang accounts requires users to enter their Mojang details into our website. That's something we definitely shouldn't do.
Connecting to a server we're running? How do you see that happening? It sounds like it could work, but I can't imagine the workflow/dataflow right now, could you explain how you see that?
- Users browses to our website, clicks "log in"
- Prompt appears to connect to server. IP is shown.
- User fires up MC, connects to our server.
- Link appears in MC chat
- User clicks on link, is logged in
It's basically a modified version of your standard Email/SMS authentication setup. Also, I was less thinking about using direct Mojang auth with the website, and more on the client side (the launcher/client program running on the computer). I think we should offer both flows on the client (where, if the user is using the built-in launcher, we need a Mojang account anyway).
Why would we even need another account or one bound to the mojang one? We don't really need authentication to download the mods?
@Turmfalke2 Comments, uploading mods and modpacks. Also, if we are launching we need to authenticate MC as well.
We have decided a few things over discord.
- Technologies used:
C++
CMake
Qt5
QtTest
(forgot what we're using for CI) - Style Guide:
https://google.github.io/styleguide/cppguide.html - Branch and Merge strategy:
Branch Per Feature as in scenario 4 of https://msdn.microsoft.com/en-us/library/bb668955.aspx
This will probably be added upon later. We should probably update the README.md with this.