<merz>
does the sandstorm community have a discord?
<merz>
or is this the main place to collaborate
<abliss[m]>
nope! we have an irc channel :)
<merz>
sweet, im in the right place
<ocdtrekkie>
Welcome :)
<merz>
Thx!
<merz>
Quick question.. i see jujitsu is experimentally implemented with rocketchat. I'd like to accomplish a video chat room that's encrypted.
<merz>
does the video traffic using jujitsu/rocketchat go through the server or does it peer to peer connect?
<merz>
e.g. does it expose each others IP? (not a big deal, just learning about how its implemetned)
<merz>
and is it encrypted video chat ?
<ocdtrekkie>
So, our Rocket.Chat support is extremely, extremely old.
<merz>
ah. is there a newer/better grain?
<ocdtrekkie>
A couple times we tried to revive interest in updating the port, but nobody wanted to work it to completion.
<merz>
gotcha
<abliss[m]>
i think the Jitsi integration in the rocket.chat never worked.
<ocdtrekkie>
I think when our folks have expressed interest in working on chat, they have been more interested in working on something both federated and a bit more Sandstorm-like than Rocket.Chat's previous implementation. I'm not sure we'd put a lot of effort into updating that port.
<isd>
Anything with voice/video right now in Sandstorm is going to be weird, because pages in an iframe can't actually do browser requests for camrea/mic access
<merz>
oh, I see. Good point.
<isd>
and on the network side of things, part of the plan for finishing out the client-side sandbox is to block WebRTC, at least by default, since otherwise it can be used for exfiltration...
<merz>
so even embedding, say, a whereby room in that iframe wouldnt go smooth
<isd>
Right.
<isd>
There's various standards-body work going on that will hopefully provide us a way out, but it will take work and time.
<isd>
I want to get to a place where apps can ask sandstorm for these resources.
<merz>
So, forgetting about video for a moment, is there a discord-like channels grain that's as "rich media" as discord. (e.g. you can paste pics, videos, html links are expanded with a summary, etc) ?
<merz>
.. and have multiple #channels each with a rich-history ?
<isd>
I mean, the rocket.chat app works. It just hasn't been updated in forever.
<abliss[m]>
i think rocket.chat does most of that stuff, yeah
<merz>
yeah I noticed it did some rich-media
<isd>
If you skim the app market you will see there are a lot of out of date apps; there used to be three full-time developers doing (among other things) app packaging. Now it's just volunteers and whatever community fundraising can buy us. We could certainly use extra hands.
<isd>
I think rocket.chat is still probably the closest to that style of app. It should be possible to update it, just no one has rolled up their sleeves and done it.
<merz>
Yeah, I was playing with sandstorm years ago when the oaisis was hosting. Now Ive come back to it to see whats new and how I can use it
<merz>
I tried installing sandstorm on my linux laptop, but I dont think it's going to work behind my firewalls. You need a public IP (even with sandcats.io DNS hosting) right?
<isd>
ill_logic: haven't you run sandstorm on a private network?
<merz>
no, i dont know how
<merz>
(oh, you were asking him)
<isd>
Yeah. I'm pretty sure this has been done.
<merz>
if its just a matter of port forwards, that can be done
<ocdtrekkie>
You just need to port forward.
<abliss[m]>
i've done it, it doesn't need a public ip at all
<ocdtrekkie>
My home network is even double NAT'd and Sandstorm works fine... I just had to double port forward.
<merz>
that's what I would have to do. same situation
<abliss[m]>
(i mean, you can run it on an air-gapped local network with no access to or from the internet. assuming your client and server can reach each other of course.)
<isd>
Ah, yeah, thought you meant wanting the box to not be globally-internet accessible. I also set up port forwarding.
<ocdtrekkie>
Also note that many home ISPs prohibit hosting sites on port 80 or port 443.
<ocdtrekkie>
So I use a different port.
<isd>
What abliss is talking about is what I thought you were asking about.
<isd>
(I use 80/443 and have not had a problem. YMMV)
<merz>
in my situation, i would need outside people to access it, so yeah
<ill_logic>
@zenhack:matrix.org: @merz: I have not successfully run Sandstorm on a private network. I was looking into it at some point for curiosity.
<ill_logic>
I sort of had that scenario in mind when I packaged Kiwix for Sandstorm.
<ill_logic>
Regarding updating hosts when you upgrade a package - uh, it looks like we upgrade a host every time you reload the page.
<ill_logic>
Which is great for cache busting. Not so great for caching.
<ill_logic>
s/upgrade a host/upgrade host
<ill_logic>
er
<ill_logic>
s/upgrade host/change host/
<ill_logic>
ui-(numbers that change every reload).(subdomain).sandcats.io/(path-to-asset)
<isd>
Huh.
<isd>
Want to open an issue about that?
<isd>
Someday I'd like to have a way for static assets for an app to be cached across grains.
<ill_logic>
Can do. Wasn't sure if that was supposed to be a surprise.
<ill_logic>
Yeah. Though upgrading domain on app upgrade is very useful. Saves me work as a packager.
<isd>
Maybe there's a reason, but worth discussing I guess.
<isd>
Agree.
kentonv has quit [Ping timeout: 264 seconds]
kentonv has joined #sandstorm
<garrison>
"On the client side, Sandstorm isolates apps by requiring every app to run on a separate, randomly-generated hostname. Sandstorm not only hosts each grain at a separate origin, but actually creates a new origin for every session. That is, every time a user opens a document, it is hosted at a new one-off cryptographically-random hostname which
<garrison>
expires shortly after the document is closed."
<garrison>
There might still be a way to host static assets at a hostname that does not change; I'm not sure off the top of the head the security implications of this.
<isd>
Yeah, I know the randomization is intentional. It seems like it's worth asking whether dialing back might improve perf, especially on bad network connections.
<isd>
But static assets are probably the most important thing there.
<isd>
And also probably could be safely moved to something like static-<packageId>.example.sandcats.io
<isd>
apps would probably have to opt-in by adding something to their pkgdef or such.
<isd>
Also, probably it would be some work to actually persist the session across page loads.
<isd>
The only tricky part I see re: moving static assets to a separtae domain is how to avoid leaking what packages are installed on a server; we'd still have to filter that somehow.
<isd>
This reminds me, I started experimenting with a patch to store app filesystems as a squashfs instead of a regular directory, on the theory that this would improve app startup times. I should get back to that.
<isd>
Davros saw like a 10x improvement in startup times from a cold disk cache when it started minifying the server. It stands to reason that packig whole app filesystems into one file would have similar benefits, without having to modify each app.