[Feature Suggestion] The ability to save teams to some cloud (like dropbox)

[benbot]

I think that would be a pretty cool feature. I'd be glad to put some work into something like that if you guys would want that kind of functionality.

[benbot]

Accidentally clicked close. Sorry :3

[kotarou3]

Wouldn't it be better just to save the teams to the server?

[benbot]

I don't know how much server space they have or if they want to use their own resources to hold the teams. If you store the data on another service then the responsibility of keeping that data secure and uncorrupted falls on dropbox... making the maintainer's lives easier.

[Zarel]

Well, the advantage of storing on Dropbox is that users would be able to manipulate the teams as normal files.

The advantage of storing on PS is that it's associated with the PS account with no need to link to an external service, and PS deduplication etc can be tuned to its own service.

I'll probably just store on PS, to make it seamless. But first we need to fix server load.

[Protonk]

Why not just symlink the teams folder into your Dropbox folder?

[benbot]

That's what i ended up doing. I was just saying for the betterment of
showdown.... integrated cloud storage.

[Zarel]

I actually do plan to add a feature to store teams on accounts.

[benbot]

If you need any help with it just shoot me an email. I'll be more than glad
to lend a hand.

[Zarel]

Um, how skilled at programming are you? I've been planning a refactor to save teams in the new packed team format instead of JSON; if you could do that for me that'd be pretty nice.

[benbot]

I've been programming for about 8 years (mostly C and C++ but I know some
JS). I'm in college atm. What's the new format?

[Zarel]

Time and skill are different. :P

https://github.com/Zarel/Pokemon-Showdown-Client/blob/101d67ea23d7a87c117338e341312c68bddd4aa0/js/storage.js#L64

I mean use this to pack the teams.

[benbot]

That looks pretty straight forward. But why use this instead of JSON?

[Zarel]

It's a bit less than 1/3 the size of JSON, which probably already uses even less RAM than the actual object representation. Storing teams that aren't open in this format should save a huge amount of memory.

[benbot]

Yeah that's quite a difference. So What exactly do you need done?

[Zarel]

Well, teams are currently saved in localStorage in JSON. The first step would be to change that over to the Storage.packTeam format. Be sure to make it backwards-compatible!

[benbot]

So converting JSON to Sotrage.packTeam? Seems pretty straight forward.

[Zarel]

Yep. It's probably a good first task for you to do; get you used to coding for PS. The repository is:

https://github.com/Zarel/Pokemon-Showdown-Client

And you test with testclient.html.

[benbot]

I'll get working on that tomorrow then.

[scpinion]

I've been lurking in the dev room for a while now and was looking to start contributing. I know this is an old issue, but is it something you guys are still wanting to do? If so, I'd be willing to give it a go.

[Zarel]

Sure, assuming you mean the Storage.packTeam implementation.

[scpinion]

Yes, implement the Stoarage.packTeam in the current teambuilder with backwards compatibility for JSON. At the moment, the tier and team name are not included in the packed format. Was this by design?

I do not have the knowledge/experience to implement something that would allow saving teams to the server, but I'm willing to learn.

[Irraquated]

I have a bot capable of saving teams to its files and are able to send you the link to them after storing with a command. maybe this could relate to how this could be done?

[itsjavi]

Hi @Zarel what's the status of this? I still get different teams depending on the browser session I use, even if I am logged in with my regular user.

The thing is that it's not very straightforward to import the team I have in other browser (in my laptop at home) when I am using Showdown in my mobile, because most of the time I don't have access to that browser session where I have my teams.

I ended up having an online file where I manually save my teams every now and then... but It's awful, would be nicer if they could be saved server-side, or integrate Dropbox for automatic synching (for that a timestamp-based logic could be used, in order to decide if there is new data or not) if you want to avoid the server load / storage possible problems.

Thanks!

[Zarel]

This is planned, but unlikely to happen particularly soon

[prayansh]

A suggestion: You could store the file on the dropbox account and on the PS server just store the link to this file. Probably wont take much server space. And then sync it regularly with the file. Also adding a functionality to change the file url could be an added bonus.

[ghost]

This would be a nice "Premium feature". I'd be happy to pay a fee for this additional service. You could make it one time fee, yearly or monthly.

[Zarel]

We don't charge for features ever, so that's not really an option.

As a note for anyone reading the earlier conversation: Teams are now already stored packed.

[DeathlyPlays]

When I thought of this I considered like being able to download teams from the teambuilder to the user's computer, perhaps as a text file

Edit: Oh so did jpinto lol

[NicholasEther]

I know this is an old topic that's harder to kill than a Wish Blissey's teammate, but it's still not solved so thought I'd add my own suggestions.

Is it possible to make it so the storage location can be chosen by the user? Then we could just choose our dropbox/onedrive/etc folder on our computers and they will sync as usual. Then I just choose that folder on each computer, so it will automatically sync and load.

I can see how that could cause issues though, obviously it's easier to use LocalStorage, but it does save you from needing to make any other changes.

Another option is to allow us to download and upload our teams directly as a file instead of copy, and pasting text. Especially if you can remember our download location preferences. Then we can click the download button after every team edit. It syncs with our cloud of choice, then on the other computer we click the upload button and choose the file. This would overwrite the localstorage. Allowing you to save that feature.

The main issue is that clicking team back up, copying teams, opening text file, pasting teams, saving; is cumbersome, especially when you're making small tweaks to the team during and after every match.

Importing isn't that much of an issue since you'd only need to do it at the beginning of the session, but being able to backup with minimal effort or preferably automatically, would be very helpful.

[Zarel]

You can already download and upload teams by dragging and dropping them between the teambuilder and your computer (on Chrome and the desktop client).

[benedictb]

Is there any reason why PS doesn't use a database to store teams? I'd be happy to contribute to making this happen.

[Zarel]

@benedictb Your question is way too vague. Any system that stores data can be called a "database", so in a way, PS is already storing teams in a database.

If you're asking why PS does not currently store teams in the cloud, that's for a variety of reasons, but mostly does boil down to time needed. A lot of client stuff is slated to be significantly rewritten, so this is blocked until that happens.

[benedictb]

I just meant in a simple relational database on the server, as it seems like it would be pretty easy jump from the packed format to a table.

[Zarel]

Yeah, like I said, it boils down to time needed, and also a lot of client stuff is slated to be significantly rewritten.

[scheibo]

@Zarel

There are currently no major blockers, although it would help if someone could figure out the relevant Google Drive API for me (the API docs are really inscrutable). It would be nice to be able to store teams there, instead of on PS servers directly. It would also make it easier to share teams between accounts.

Can you elaborate on what your vision is here? Users would link their Google accounts with PS, and then when teams are saved/loaded instead of syncing with local storage they are instead saved to Drive? (or, perhaps you still use local storage as a cache, etc).

[Zarel]

@scheibo yes.

[timotree3]

I've been looking into how to implement this using the Google Drive API. Using this documentation, I've learned a few things.

• All interactions with the Google Drive API are done using the credentials of a Google Cloud Project.
  • Essentially, using the Google Account of the developer, you register an application and receive an authentication token.
• Users are prompted to give permissions to that Google Cloud Project.
• Once your user has given you permission in a Google pop-up box, you can use your authentication token to do whatever actions they gave you permission for. (e.g. read, create, edit, and delete files)

This situation necessitates one of two solutions:

• For each user who signs in with Google Drive, we create a Google Cloud Project (under the Google account of the server host) specifically for that user and then give their client the token to use that project's credentials.
• The server has only one Google Cloud Project that all users give permission to, then clients would go through the server for each and every sync operation done with their Drive.

The first one has the downside that it requires building some automation around the Google developer administrative API and I'm not sure if it is within the ToS to automate Project creation like that.

The second one has the downside that it would be high overhead on our server, requiring a copy of the updated team to be uploaded and temporarily stored as the server forwards the request to Google's servers.

Once we figure out these question about API authentication, it seems like it will be pretty easy to write the code to use Drive for team storage, we already use localStorage as basically a flat file for teams, and Drive allows Google Cloud Projects to store hidden files on their users Drives.

[Zarel]

It looks like the correct answer is to have only one Google Cloud Project. The reason I wanted Google Drive was so the teams could be files users could move around as they wanted.

[timotree3]

Is the idea that the user would, on a team-by-team basis, use a file browser to choose what text file on their drive that team is synced to?

[Zarel]

No, there would just be one folder "Pokémon Showdown Teams", which would be kept in sync with PS.

[timotree3]

Actually, based on this article about authentication, it seems like there is an intermediary authentication token that is specific to the permissions related to that user. It seems like that token can be sent to the client which would mean that we can have the best of both worlds.

[Zarel]

It looks pretty hard to control a folder in Google Drive. :/

[timotree3]

Based on the article on MIME-types, folders are files in Drive. (See application/vnd.google-apps.folder

[Zarel]

Yeah, but folder access doesn't seem to give you access to all its contents recursively.

I think no matter how we did it, it wouldn't be any better usability than the current system. We might as well just store teams on our own database, or in AppData.

[benedictb]

Why don't we use some cloud nosql database instead of Google drive? You wouldn't have to worry about authentication at all in that case, just let the client handle it.

If users want to manipulate their teams like files they can export them and store them themselves.

[Zarel]

Yeah, my original idea for using Google Drive would be the ability to access the teams directly as files. But it looks like Google doesn't make it very convenient, in which case, yes, a traditional database is probably good enough for our purposes.

[mfrancis95]

What about using object storage like S3?

[Zarel]

That doesn't seem like an improvement over self-hosting a database. Specifically, we've never been able to afford Amazon prices for web services; we've always just self-hosted them.

[mfrancis95]

There's free object storage like Minio that provide an S3-compatible API.

[Zarel]

Interesting. That might be taking a look at. What are the advantages/disadvantages vs regular NoSQL databases?

[alchzh]

Is it finally time to tackle this along with other database related moves e.g. #6469 ?

[marksg07]

@acz13 Funny you should bring that up, I have a few old PRs open for this issue (see smogon/pokemon-showdown-client#1418) that have been blocked on the Postgres transition (smogon/pokemon-showdown-client#1423) for months. Once that gets resolved I can continue work on it.

[TCModus]

I know that the client is slated for a major rewrite but I did have some thoughts on this:

if you wanted to support dropbox (which I think is a great a simple way to provide this feature to users) you could simply integrate the "saver" and "collector" javascript components in the teambuilder https://www.dropbox.com/developers/chooser https://www.dropbox.com/developers/saver

I actually would love to contribute to this project (in really any way because I am a life long pokemon fan and have been loving playing PS these past few months after discovering it) but I see the client is written in PHP which I am not experienced in.

Also what if the pokepaste system was leveraged to provide import/export functionality of teams? Essentially it already operates in this way but the user has to share the link with themselves and then re-import the team using that link on whatever different device or browser they are on.

Instead the team builder could have a "backup team" button that uploads the team to pokepaste and saves the url to the users profile, and a "restore team" button that imports the team from the saved url. This idea can be expanded if its not expensive to persist additional string values in the users profile and allow users to backup multiple teams using this strategy.

I do however have node experience and will be seeing if I can contribute to any issues I see.