-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature]: 3rd party server support #95
Comments
I'm unsure about allowing 3rd party NEX servers due to all the issues that it brings, though I guess we would have to allow it for some cases, such as Monster Hunter games that use NEX Another thing we have to consider is making a good user interface to allow switching or enabling services, depending on the circumstance |
Outside of the InetAddress exploit Kinnay published, what other issues do you see with game servers specifically? Even if we didn't allow game servers, the issues I mentioned in the proposal would still need to be fixed for cases like Miiverse. That way we don't run into issues of Juxt users trying to pull Rverse posts, and vice-versa. If we're going to solve that, we might as well try to solve all the issues too so we can do game servers. |
I may have overreacted with using the term "all issues", but I'm still unsure This is only my perspective (feel free to disagree on this point), but I think offering 3rd party servers for games we already support could lead to some confusion since you may not be able to know (depending on the game) if you are connected to our server or third party ones. With Miiverse users can tell directly which service they're using, however, and the same applies for services we don't support ourselves I'm also on the opinion that third party services should be offered by communities, but not by random individuals (there can be exceptions, but those would have to be considered on a case-by-case basis) as this would filter malicious or poorly maintained servers |
Checked Existing
What feature do you want to see added?
(Mostly only making this issue to add it to the tasks tracker)
Add the ability to allow 3rd party developers to register both their own instances of NEX (game) servers, but also completely separate 3rd party services (such as those looking to integrate PNIDs into their systems)
Why do you want to have this feature?
This would allow for developers to create their own instances of game servers, and users would select which instance to connect to. This is most useful in cases like:
This would also allow non-game services, and games which are out of scope for us, to use existing PNIDs for authentication
Any other details to share? (OPTIONAL)
DUE TO THE WAY CERTAIN GAMES HANDLE USER GENERATED CONTENT, MIXING 3RD PARTY GAME SERVERS AND 3RD PARTY MIIVERSE IMPLEMENTATIONS, SPECIFICALLY, CAN VERY EASILY LEAD TO DATA CONFLICTS! THE IMPLEMENTATION NEEDS TO ACCOUNT FOR THIS!
As an example, Mario vs. Donkey Kong: Tipping Stars uses BOTH Miiverse and NEX DataStore when uploading levels. The level data itself is uploaded to NEX DataStore, however a Miiverse post is ALSO created at the same time. The DataStore data and the Miiverse post are linked together through their unique IDs.
This, very obviously, will create data conflicts if naively implemented.
Say a user is using GameServerA and MiiverseA, and then uploads a level. Only GameServerA and MiiverseA have records of this data. Now say a user is using GameServerA, and MiiverseB. The user is given level data from GameServerA, attempts to load the linked Miiverse post from MiiverseB, and either fails to get data back or receieves incorrect data.
Now say a user is using GameServerB and MiiverseA, and uploads a level. MiiverseA now has records for DataStore data which does NOT exist on it's own GameServer instance.
This is not a trivial problem to solve. There are options, such as only allowing the user to connect if using the same A/B instances of servers which rely on each other, however this is unreliable and would lock users out of other users data.
The text was updated successfully, but these errors were encountered: