Hey guys,

With Flash slowly starting to fade out, I'm wondering if anyone can give me some information on what formats are able to be uploaded to e621 for an interactive style game.

As I browse, I really only see flash files. Is Flash the only option?

Thanks.

Yeah. Seeing some kind of html5 support would be awesome.
I've also seen some JavaScript library that enabled flash apps to be viewed using html5 without any addons. Beta, but still, a good option for supporting old posts when flash finally dies.

I'd like to see HTML5 support on E621. I think it is potentially much less obnoxious than Flash.

However, from what I've heard, it does not fit e621's "one-post-one-file" assumption. As I recall, the principal problem is related to the use of a CDN; the use of a CDN can mean that not all files would be on the same server. Files not being on the same server runs afoul of HTML5's restrictions on cross-site linking.

This is just off the top of my head, which is why I haven't been very specific. Hopefully someone who knows HTML5 better can clarify.

SVG+SMIL has also been discussed as an option in the past. However, there seems to be some doubt about SVG's continuing development (Lack of industry investment in bringing SVG 2.0 standard to completion.)

There are a whole bunch of problems I can think of with HTML5 that make it an annoying target, and nobody is on board yet.

First is that packaging resources is hard to do, fragile if done wrong, and outright broken you don't plan ahead and design your application to be run in an arbitrary url root.

The next comes with external resources, many games would like to load external resources, either to support saving things, or to load content that wasn't uploaded. This tends to be a privacy issue, but it is also broken if you sandbox the frame and say it can't load content outside same domain. This tends to fall under being polite and not allowing your platform to be a launching ground for a DDoS attack by having people load undefined resources on another domain from some popular content.

Storage is another problem. Most games want to store data somewhere, and when you stick all of these files on a single domain, they compete for storage space, are not namespaced in any way, and it's just problematic overall. Cookies are a bad choice because they get sent to the server. localStorage has a limit of a few MB. IndexedDB is decently supported, but most people don't know, or want to use it, and some implementations are buggy.

I'd really like to see a standard emerge that allows for loading web applications from a zip file, the same way extensions currently work in chrome. It has a metadata blob that describes what it wants to do, the user can grant permissions to it, and it can be hosted and run inside a frame without worrying about it being able to access any of the other content on the page. Storage gets assigned to a pseudo site id based on where it is hosted, and the hosting site controls what permissions can be requested by the application in a whitelist manner.

Having a zip file with the whole application resolves resource location problems, standardizes practices and expectations, and also sandboxes what can be accessed.

If anyone is aware of clearly defined solutions to these problems, I'm totally up for trying it out.

A lot of this isn't covered by existing Flash sandboxing, but would be great improvements to have to solve existing problems with Flash sandboxing.

As of right now my understanding is that we'd need to roll a new domain to host the content on, run it inside a sandboxed iframe, and just hope that it doesn't explode because somebody made a wrong assumption or tries to break the sandbox rules in some way by mistake. We would have to provide guidance on how best to package applications for our platform, and then provide a troubleshooting or sandbox section so that it could be tested before uploading. It just turns into an e621 specific, complicated, and problematic mess.

Thanks for getting back to me.

I know that both Chrome and Firefox have already started to phase out Flashplayer and as of chrome at least, a lot of functionality has been automatically turned off.

Could you possibly tell me if Unity would be a viable option for the site? Or if you know of somewhere to direct me to that has the answer, that would be great.

Thanks!

KiraNoot said:
If anyone is aware of clearly defined solutions to these problems, I'm totally up for trying it out.

Apparently people at Glitch somehow managed to make an usable "applet" platform out of HTML5+JS, though they also seem to support (optional) NodeJS backend. Also their preferable method of deployment involves either "remixing" (which to me sounds like another word for "forking") or pulling an existing Git repo, rather than directly uploading ZIP bundles. Probably has to do with their whole philosophy of "start from a working project, so every bug is your bug".

This might be problematical in regard to e621, in the sense that:

• not every author would like their code and assets to be reused in derivative works by other people, and
• existing public Git hostings (i.e. Github) are unlikely to approve of uploading much of adult/NSFW content such as presented on this site.

As of a tidy way of creating ZIPpable bundles themselves, I would probably suggest looking into something like Parcel.

NestorAjax said:
Apparently people at Glitch somehow managed to make an usable "applet" platform out of HTML5+JS, though they also seem to support (optional) NodeJS backend. Also their preferable method of deployment involves either "remixing" (which to me sounds like another word for "forking") or pulling an existing Git repo, rather than directly uploading ZIP bundles. Probably has to do with their whole philosophy of "start from a working project, so every bug is your bug".

This might be problematical in regard to e621, in the sense that:

• not every author would like their code and assets to be reused in derivative works by other people, and
• existing public Git hostings (i.e. Github) are unlikely to approve of uploading much of adult/NSFW content such as presented on this site.

As of a tidy way of creating ZIPpable bundles themselves, I would probably suggest looking into something like Parcel.

If you suggest using a git based service, you should better have a look at gitlab. E621 could provide its users a gitlab instance that supports private repositories, gitlab pages for hosting all necessary files and pipelines to automatically build, test and deploy those html5 applications.

Users would upload these games using the link to the gitlab pages page.

I just noticed some activity in my thread over here, so I searched for other relevant threads and found this one. It is good to see an admin involved in this matter, hence I try to address the mentioned issues.

KiraNoot said:
First is that packaging resources is hard to do (…)

Indeed, one needs to inline all resources. But there is a number of tools available to automate this. Up to now, I always achieved good results with https://github.com/remy/inliner.

KiraNoot said:
Storage is another problem. Most games want to store data somewhere, and when you stick all of these files on a single domain, they compete for storage space, are not namespaced in any way (…)

Indeed, the limitation of localStorage is an issue. However, there are libraries with user-friendly front-ends to IndexedDB like https://localforage.github.io/localForage/.

KiraNoot said:
As of right now my understanding is that we'd need to (…) run it inside a sandboxed iframe, and just hope that it doesn't explode (…)

Breaking sandboxes always raise concerns, but that issue exists within Flash, too. And prominently so. I do not see a sandbox provided by the browser being much worse than a sandbox provided by the flash plug-in (the only advantage would be process separation).

There also seems to be the misconception that e621.net would need different domains. This is apparently not true. For maximum security, e621.net would offer one origin per interactive submission. At first, this seems to be insane, but wildcard DNS entries and catch-all name-based hosts totally exist. https://1209825.post.e621.net/ could show the data from https://e621.net/post/show/1209825 and client-side, everything would be fine. This would also resolve the localStorage issues.

I have to admit, that I have no first-hand experience with the host-based-content idea. I could do some research, but I do not want them to be in vain right from the beginning. Last time I inquired about this matter here in the forum, there was a lot of backlash. So, KiraNoot – or any admin – if I threw together a more elaborate tech-demo/proof-of-concept, would you even look at it?

I have to admit, that I have no first-hand experience with the host-based-content idea. I could do some research, but I do not want them to be in vain right from the beginning. Last time I inquired about this matter here in the forum, there was a lot of backlash. So, KiraNoot – or any admin – if I threw together a more elaborate tech-demo/proof-of-concept, would you even look at it?

While I'm open to looking at things, I'm currently pretty busy working on other stuff, so I can't focus my attention on this issue right now.

As per the wildcard DNS, my understanding is that we'd need to set up something with another wildcard domain certificate. I suspect that we can negate the cost of this, if there is one. The reason to place things on a different domain is to negate some issues surrounding cookies and the definition of origins. So it would be another domain on a TLD.

As for local storage, when I last looked, browsers are doing quota accounting per domain and not strictly per origin, in order to prevent sites from unfairly spawning out sub domains and using up too much space. The exact details of this have been vague at best, and seem to change without warning. Firefox being the most forthcoming and saying that 20% of the global temporary storage pool can be used per domain but that evictions are likely to happen before that point anyways, or quota errors.

KiraNoot said:
As for local storage, when I last looked, browsers are doing quota accounting per domain and not strictly per origin, in order to prevent sites from unfairly spawning out sub domains and using up too much space. (…)

Which is exactly what we would want to do. The spec indeed says, although "namespacing" happens per origin, storage quota is calculated per domain. I did not know this before. Thank you for your insights, I feel more informed now. Unfortunately, this puts another nail in the coffin of this approach.