search

thenick775 / gbajs3

Gbajs3 is a full Game Boy Advance emulator online in the browser supporting the mGBA WASM core. It is freely licensed and works in any modern browser.
38 stars 25 forks source link

Self-host on static hosting? #49

Closed 0dt483e0 closed 4 months ago

0dt483e0 commented 7 months ago

Hi, is it possible to self-host this on static hosting? I'd also like to have a preloaded and auto-starting ROM. Thanks

thenick775 commented 6 months ago

In the current state of this repo, the frontend (gbajs3 directory) can be built and statically served by running npm run build then uploading the contents of the generated dist directory to your static hosting provider.

If you don't have a server/host to run the auth/admin servers and the database (can be hosted in AWS separately), you wont be able to leverage any login/profile functionality. If you do have a separate server/database it is all a matter of building with the correct environment variables.

I may consider an enhancement to remove profile related menu nodes based on configuration if this is a popular ask (full static hosting with no database or auth).

What is your desired use case for preloading a ROM file?

I've avoided anything like that in the past due to the illegality of publicly distributing ROM files, but am open to a different approach provided it takes U.S. copyright law into account.

Currently all ROM files must be provided by the user, either locally or through the profile upload/download methods (as these are all private, and don't allow public distribution) and aren't able to be easily shared across devices/profiles through the exposed functionality of the server containers listed above.

0dt483e0 commented 6 months ago

In the current state of this repo, the frontend (gbajs3 directory) can be built and statically served by running npm run build then uploading the contents of the generated dist directory to your static hosting provider.

Great, that's good to know, thanks.

If you don't have a server/host to run the auth/admin servers and the database (can be hosted in AWS separately), you wont be able to leverage any login/profile functionality. If you do have a separate server/database it is all a matter of building with the correct environment variables.

I may consider an enhancement to remove profile related menu nodes based on configuration if this is a popular ask (full static hosting with no database or auth).

Ah I see. I think its probably fine as is, for me anyway.

What is your desired use case for preloading a ROM file?

I've avoided anything like that in the past due to the illegality of publicly distributing ROM files, but am open to a different approach provided it takes U.S. copyright law into account.

For a low-barrier-to-entry game demo basically.

But yeah you wouldn't want a copyrighted ROM in the git repo or on your instance or anything, this would just be a configuration option.

thenick775 commented 6 months ago

This all seems like a good addition!

I'll come up with a plan and update here on what I think is the best approach.

Thank you for opening this issue! 😎

0dt483e0 commented 6 months ago

Thanks!

thenick775 commented 6 months ago

Just circling back here, I have some local code that facilitates most of the needs here, but I'm struggling to find a good general format for preloading rom files that also abides by my current legal copy.

I'm thinking url parameter(s) that correspond to a public unzipped rom file download, maybe additionally putting basic auth on the landing page for static compiled builds with preloaded rom file(s) specified as some form of keeping it private, but allowing you to share access at your discretion privately.

Just wanted to let you know some thought is going into this, which is why implementation is taking a bit longer than expected 😎

Current copy for reference: No Distribution of Game Boy Advance ROMs: The Emulator does not provide or distribute any Game Boy Advance ROMs or copyrighted game software for public consumption. You must obtain Game Boy Advance ROMs from legal sources and ensure compliance with applicable laws regarding the use of copyrighted materials.

0dt483e0 commented 6 months ago

Ah so you're thinking gbajs3 could just generally let the user set a ROM source via URL parameter? Nice idea. An option for zipped ROMs would probably be useful, but that's maybe out of scope for this.

Good idea about an auth option too. Although so it could work for static hosting too, you could instead point to an encrypted ROM and have the key as a URL parameter too. Although that's more complicated of course.

That copy makes sense/looks good.

thenick775 commented 6 months ago

Zipped roms may be in scope given it's just a singular zipped rom file 😎. I just don't want people trying to link to a url that contains a full zip with other files in it or a directory structure, as I don't think I'll be working on complex zip structures.

Provided the request supports gzip it should still be compressed over the network though!

I'm hesitant to use encryption keys, and that's a bit harder to work with from a public rom clients perspective, and a lot of truly public roms wont offer encoding that way as they sit today in the public domain!

Basic auth would work from a static hosting perspective, as it would be one set of credentials for all that can be privately disclosed, but I'm still on the fence if it should even be necessary, optional, or implemented at all.

thenick775 commented 6 months ago

I'll fool around with getting more of this finalized with the current path laid out above, thanks for all the discussion and feedback! 😎

thenick775 commented 4 months ago

Just want to follow up here as I've been encountering some problems with the last request.

Now, if building statically you can:

I've got most of the code worked up here to allow you to load a rom from query params, but have run into many issues when installing as a PWA on iOS.

For example, the start_url of my manifest may have to be built exclusively with javascript, as otherwise we lose query params when installing, along with all other data since iOS PWA applications are sandboxed separately from what you see in Safari.

I'm still working on a solution to the last ask, preloading and installing a public rom after a user has agreed to install it, but definitely would like any feedback on an appropriate solution.

I most likely will have to go about this with fingerprinting or some other method like dynamically assembling the manifest, but I feel like I'm going to run into service worker precache issues, which I should eventually be able to navigate around.

I'll leave this issue open until I get preloading public roms after consent working fully 😎

0dt483e0 commented 4 months ago

Nice work. Loading a non-zipped ROM via URL seems to work for me, via the public instance.

About iOS installed PWAs (although I'm not an expert on thme) - if no user data is transferred, I guess you might have to prompt the user to copy a base64 string from the browser, to the installed webapp. That way you can transfer the ROM URL and any other config data (although not a large amount of data, so not ROMs/saves).

thenick775 commented 4 months ago

Exactly, I'm debating leveraging cache storage if it even still works for this, but additionally, I may just have the user copy paste into the upload rom modal.

Until I figure out what decision I want to make, you can always build and deploy the branch mentioned above either through the workflow, or by building/deploying those static files.

That should at least make it so that you can use the url param 'romURL' in the meantime until I get a full solution through, or document the limitations!

thenick775 commented 4 months ago

I'm going to close this issue, as static hosting is fully supported 😎

I'll spin up a new one explicitly for loading a rom from url params as i figure out how data transfer will work.

Feel free to keep commenting here, open a separate discussion, or follow the next issue 🚀

Status checklist: