search

nonstorio / nosenstory

NosenStory API, client-agnostic interface for maintaining NosenStory game process across multiple chat applications.
https://nosenstory.github.io
Apache License 2.0
0 stars 0 forks source link

Client-agnostic migration considerations #3

Open vintprox opened 4 years ago

vintprox commented 4 years ago

All models related to Discord identities (channels, guilds, users/players) contain field ref_id. Just so you know, it's not same as id serial value, which identifies the row in database table.

It's made for error-free transferring between identities. For example, NonStory ID of player remains intact for binding data to same identity while allowing one user to transfer statistics to another user, considering latter one has near to zero playing history in database (which usually means that user is just migrating accounts and wants to keep stats and not abuse a system), so only ref_id in according row is changed during that process.

It would be good to settle with conditions for transferring between channels and guilds also.

vintprox commented 4 years ago

9 points out the need to move client-specific logic to separate repository. Regarding it, Discord identities remain bound to appropriate models (channel as NSRoom, guild as NSHome). Key ref_id may whether remain intact or renamed to id_int, referring to it as "integer ID" for server types that support it. For other types of servers there can be id_str added to allow usage of domain names to identify servers, for example. With this, I also propose to rename ref_name to id_str.

vintprox commented 4 years ago

With a0db7c3, it was decided that supposed "channels" must be abstracted to client-agnostic NSRoom. It and other data-heavy models now contain nullable id_int and id_str fields to represent identifier of object that target app uses to find out distinct identities.

NSRoom strictly resides as child of one NSHome, client-agnostic abstraction for supposed "guilds" in Discord, domain-bound IRC servers, etc.

And finally, NSHome is always related to one NSApp, client type representation of bot or whatever service using NS API. "Apps" that will be added by default in this official repository are reserved for single official bot per each supported chat platform/client.

NSLobby will act as bridge between rooms from same/various homes and apps. One can get grasp of lobby as of dedicated playground scattered across the servers.

vintprox commented 4 years ago

It's made for error-free transferring between identities. For example, NonStory ID of player remains intact for binding data to same identity while allowing one user to transfer statistics to another user, considering latter one has near to zero playing history in database (which usually means that user is just migrating accounts and wants to keep stats and not abuse a system), so only ref_id in according row is changed during that process.

The important point about migration of users is to make it strictly without requiring email and setting passwords, because we aren't able to host such facilities right now and to create ToS. Plus it's a huge vulnerability because of the third-party nature of bot hosting. We must discourage users from typing any registration data, unless it's just a non-unique name, while facing any bots and web/PC clients (which will be there more and more in perspective). For that, I propose to include warning on official website.

Keep in mind that Discord is centralized and requires you to have only one account, while for example, IRC servers are distributed and users with same resembling characteristics can be completely different persons between servers. Process of user migration in same home/app implies having access to previous account to cautiously proceed with migration to new one. Linking account in new home/app must be granted from origin account, and for that we send confirmation prompt to origin. One can change their origin based on which home/app they use often. That also can be predicted by summarizing stats, I guess.

It would be good to settle with conditions for transferring between channels and guilds also.

Transferring between servers/guilds should be straightforward enough and reside in same app. Condition is to have management rights for related NSHome. If some rooms have no resembling identities in new home, we send notice about these rooms' migration.

Speaking of NSRoom, to change id_int from previous to new one, Discord bot shall detect channel with same id_str (name) in guild and permit users to run game in this new channel. Migrating room to other home should be possible, but only within one app.