<garrison>
The doc for creating an offer template says "Because it is implemented with an IFRAME, the app cannot read the token out of the offer template, which is good for app isolation." Is there a particular reason an app should not know its API key? I'm trying to better understand why this degree of isolation is necessary. i.e., what is the worst a
<garrison>
sandboxed app could do with its API key?
<kentonv>
oh good. Meteor did a major release of the HTTP package, 2.0.0. And all the Meteor first-party packages require it now, but of course the rest of the world still depends on 1.x. So updating is impossible.
<ocdtrekkie>
Awesome
<kentonv>
remember, folks, the first number in a semver version is the number of times you screwed up.
<ocdtrekkie>
😂
<ocdtrekkie>
Bodes well for Sandstorm still being 0dot versions...
<kentonv>
"Internally http has been replaced by fetch, should still work as previous version, but edge cases might be different. This is to aid you in transition to fetch."
<kentonv>
oh so you bumped the major number for NO REASON, at least as far as you know?
<kentonv>
"The http package has been deprecated, please migrate to the fetch package and new web standards."
<kentonv>
omg
<kentonv>
I'm all for fetch() in new code but this is basically telling everyone to rewrite everything.
<kentonv>
might as well deprecate JavaScript while we're at it and tell everyone "just migrate to TypeScript"
<Corbin>
Sounds like a classic case of trying to make fetch() happen.
<kentonv>
https://github.com/TAPevents/tap-i18n good good, last change 5 years ago. I'm sure if I file a bug asking them to update to HTTP 2.0.0 they will get right on it.
<kentonv>
xet7, have you run into this problem yet? Looks like Wekan uses tap:i18n and hasn't updated to Meteor 2.3 yet.
<xet7>
Those Meteor devs tried to help upgrade, because my own way to upgrade was kind of a joke (well, I forked and changed 40 old mostly deprecated dependencies, to make version numbers play together someway, and it still did not fully work)
<garrison>
I just came across this while looking for this HTTP 2.0.0 package. Any chance it is relevant? I don't know much about meteor. https://github.com/jankapunkt/meteor-http
* garrison
thinks perhaps not after reading #11575 in full
<kentonv>
garrison, yeah not really. If we could just update everyone's dependencies to point at one version it wouldn't be an issue.
<iFire[m]>
Maybe it can help clarify the scope of the work
<iFire[m]>
Some questions about the powerbox integration design
<ocdtrekkie>
So am I correct in summarizing you want people to be able to host the server component for a VR game?
<iFire[m]>
yeah
<iFire[m]>
and even the backend lobby system
<iFire[m]>
if needed
<iFire[m]>
We aspire the whole thing to be something they can setup a server with and with sufficient bandwidth they can be a host.
<iFire[m]>
and we're in a sort of kubernetes hell currently
<ocdtrekkie>
Biggest thing to determine will be whether or not our current network access APIs will work for your use case. In most cases, things that run over plain HTTP requests should be able to work, but other network protocols tend to be nontrivial.
<iFire[m]>
We would require webrtc or open udp.
<iFire[m]>
We are very certain http/1 would not work, but maybe http/2 may work
<ocdtrekkie>
I am not sure Sandstorm is well situated to very high bandwidth situations either, but Ian is the expert in what we currently can and can't do.
<iFire[m]>
Is he someone that is on regularly? It is the weekend and I don't want to impose.
<ocdtrekkie>
I suspect Sandstorm at current would neither support WebRTC or UDP traffic through the Powerbox, but I am not sure what would be involved in adding it.
<ocdtrekkie>
Ian is on regularly, Sandstorm is strictly a community project at this standpoint, so no explicit work hours.
<iFire[m]>
I have two prototypes for udp based proxying methods
<kentonv>
it's important to note that Sandstorm is maintained by volunteers. It is not a business (anymore). So if you plan to build your own business on top of it, you may need to get your own hands dirty.
<kentonv>
that is, help build the features you need
<iFire[m]>
that is ok
<iFire[m]>
I do a technical plan that is possible though
<iFire[m]>
* I do [need] a technical plan that is possible though
<iFire[m]>
So I'm trying to scout ahead for some approaches that can work.
<iFire[m]>
Some opensource projects have "shared hours / office hours" like once a week, so I wanted to ask.
<ocdtrekkie>
There is very little interest for anyone here on picking up Blackrock.
<ocdtrekkie>
Mostly because nobody working on Sandstorm has a use case that would justify it.
<iFire[m]>
oh I was thinking of the bare minimum which is running the standard standalone server as a kubernetes container
<ocdtrekkie>
(I believe the opinion was held that the old paid Sandstorm host, Oasis, probably could've run normal Sandstorm instead of Blackrock, with the activity level it had.)
<iFire[m]>
makes sense
<kentonv>
yeah... never should have built blackrock. I still like the idea but it was the wrong business move.
<iFire[m]>
let me search for a service architecture diagram
<isd>
I am out and about right now, but ping the mailing list and I can reply async.