<TimMc>
There's a mostly-abandoned web application I was thinking of porting to Sandstorm, but it has a quirk that I'm unsure about -- it uses a second domain name to host a tiny service for iframe-embedding stuff from other websites (e.g. youtube). That gives some kind of domain isolation, I guess. I imagine I'd have to find a different solution?
<ocdtrekkie>
Not something that be static published, by chance?
<ocdtrekkie>
I wonder if you could hack it with standalone domains.
<TimMc>
It's possible that it's all JS-based and therefore could be static-published, but I think it would have to be on a different grain in order to get that origin isolation.
<TimMc>
I guess my app could have two grain types, and you could make one embed-type grain that could be used by the regular app-type grains?
<ocdtrekkie>
Static publishing and your grain would be on different subdomains, in theory.
<ocdtrekkie>
And if you set up the CNAME for your static site, you have more domain isolation.
<TimMc>
yeah
<TimMc>
Heh, I just realized that my suggestion of one app with two grain types would be a nightmare as soon as it came time to upgrade the app in a non-compatible way.
<ocdtrekkie>
So you put the static published part up with instructions in the main app how to CNAME that domain.
<TimMc>
Two apps, then. A first app that creates a static site; a second app that's the main app (separately versioned) and tells you to create at least one of the first type, optionally shared.
<TimMc>
It might also be that iframe isolation and CSP have come along far enough that I can rip out the whole embedding trick.
<isd>
What's the app?
<ocdtrekkie>
Why would you need a separate app to do the static publishing, if you can CNAME it for domain isolation?
<ocdtrekkie>
Also, nobody uses it, but even if you wanted two separate types of grains they could be in one SPK.
<ocdtrekkie>
Radicale might be the only published app with two grain actions.
<TimMc>
I have no idea how long he's willing to keep spending $200/month on a chat server that, as far as I can tell, he doesn't actually use...
<isd>
I do not see the image, only a white gap in the chat log.
<isd>
But this looks nice & lightweight, and with a Go backend it probably starts decently fast.
<TimMc>
Postgres, etcd, haproxy, some background services.
<isd>
The embeds are likely to aslo be a bit thorny because of Sandstorm's general attempts to block third party resources from apps. My recommendation would be to more or less punt on it at first, and we can maybe fuss with it later.
<isd>
Ok, less so. But worth a shot.
<TimMc>
Can probably just rip out the whole embed system at first, yeah. Skip some of the background services too, maybe. I see one called "retention" which I think just deletes messages older than X days in room configured for that.
<TimMc>
My main concern is actually that I'm no great fan of Go, and I'd be tempted to rewrite it in Rust or something. XD
<isd>
:P
<isd>
I mean, if you want to write a chat app for Sandstorm I encourage this.
<ocdtrekkie>
Speaking of encouraging... Ian. If it would encourage you further... Prioritize sounds neat and I would probably use it.
<TimMc>
Sandstorm doesn't have enough chat servers already, eh?
<isd>
Hah. Yeah, I'll probably get to publishing it at some point, but as the readme says, it's barely MVP for myself. I am using it though.
<isd>
timmc: if you want to maintain one of the existing ones, I would also encourage that.
<isd>
I encourage app development in general
<isd>
But also esp. of apps that will start quickly; that's a constant thorn in my side.
* isd
makes mental note to get back to the squashfs thing sometime soonish
<ocdtrekkie>
YATA is still my preferred list app on Sandstorm by far, I use it often
<ocdtrekkie>
I feel like pinned grains would still be really nice for certain types of grains. I do fear an app like Prioritize I might forget to check if it's not at the top of my grain list every day.