You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have checked the repository for duplicate issues.
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:
Heavily modded game sessions
Players who may not want to conform to our general rules (allowing all cheats, everywhere, for example)
Private tournaments
Etc.
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:
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: