<ill_logic_>
A little while ago I asked here how to use powerbox to share a file in FileDrop with another application. I was told that this feature was hopefully a couple weeks away.
<dwrensha>
Filedrop would need to be updated to use it
<ill_logic_>
Word. Okay thanks. I guess I'll work around it for now.
<ill_logic_>
That's exciting! Did somebody create Filedrop especially for Sandstorm?
<ill_logic_>
i.e., is it up to somebody at SS to implement this?
<ill_logic_>
I'm working on a great use case for this at the moment. I plan to make my app basically depend on it once it's available.
wolcen has quit [Remote host closed the connection]
<dwrensha>
ill_logic_: I think that on the FileDrop end this would just involve adding a bit of metadata in sandstorm-pkgdef.capnp
<dwrensha>
I suspect zombiezen would be happy to accept a pull request adding that
<ill_logic_>
Really? Wouldn't it need some sort of api plugin?
<kentonv>
well, the HTTP API for "download a file" is probably very simple. :)
<ill_logic_>
I see.
<ill_logic_>
okay what the hey. I'll give it a shot today.
<kentonv>
though there's a problem currently
<kentonv>
which is that the present implementation in http-bridge doesn't allow for the app to display a picker... it can only export static APIs
<kentonv>
for filedrop you'd probably want the app to display a picker to pick which file to connect to
<kentonv>
unless you wanted the whole set
<ill_logic_>
Hmm.
<ill_logic_>
Actually, the whole set would probably work out fine for my needs.
<ill_logic_>
It's something I'd probably want to have as a feature eventually, so I may as well have it out of the gate.
<ill_logic_>
afk for a bit
<kentonv>
hmm, then I guess FileDrop will need to export an API for a "set of files", which includes some sort of index that lists all the files, which is *slightly* more complicated but not much.
<kentonv>
actually maybe you want Davros here. It already implements WebDAV, a standard protocol for all this...
<kentonv>
... though then you may rut into the problem that the http-bridge code doesn't cover DAV at the moment (though that should not be too hard to add...)
FredFredFred has joined #sandstorm
FredFredFred_ has quit [Ping timeout: 258 seconds]
neynah has joined #sandstorm
<ill_logic_>
Can you upload files to Davros from the web?
<ill_logic_>
Or does it require a local Owncloud?
<TimMc>
ill_logic_: You can upload via the browser, yes.
<ill_logic_>
okay I gotta head out. I guess I'll pick this up when I get where I'm going. Thanks for everything so far!
<kentonv>
ill_logic_: Ross, who wrote FileDrop, works for Google
<kentonv>
Googlers tend to assign copyright of all their open source projects to Google, because it makes the approvals process easier
<kentonv>
and for open source code, who cares who owns the copyright...
ill_logic_ has quit [Ping timeout: 240 seconds]
<TimMc>
Google apparently has pretty draconian IP contracts. A friend of mine there said he isn't even allowed to contribute to AGPL code, even outside of work hours and without using work resources...
<TimMc>
I suspect that wouldn't hold up in court, but it's pretty gross.
funwhilelost has joined #sandstorm
<kentonv>
TimMc, in my experience the "open source program office" at Google is pretty willing to approve things. But I guess it may have changed in the last four years.
<kentonv>
and yeah, technically in California and some other states, they cannot legally claim rights to things you do in your own time on your own hardware... *unless* they relate to your work. Unfortunately almost everything software-related relates to Google somehow so it's very gray-area.
funwhilelost has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
losingkeys has joined #sandstorm
pdurbin has quit [Ping timeout: 240 seconds]
ill_logic_ has joined #sandstorm
<ill_logic_>
I'm trying to run filedrop in spk dev mode. Filedrop has no .sandstorm directory.
<ill_logic_>
But the stuff that would be in that directory are in the root.
<ill_logic_>
How do I do this exactly?
losingkeys has quit [Quit: Leaving]
<ill_logic_>
In fact, `spk pack filedrop.spk` doesn't work as described in the README.
<kentonv>
ill_logic_, filedrop doesn't use vagrant-spk, so you'll need to use the raw "spk" tool on a Linux machine or VM.
<kentonv>
you may need to run spk dev once and open up the app in dev mode before spk pack works. In dev mode the spk tool will track what files the app uses, which will then be included in the pack.
<ill_logic_>
So, how do I get the `spk` command?
<ill_logic_>
I have `vagrant-spk`
<ill_logic_>
The instructions call for `spk`
<ill_logic_>
oh I guess I got vagrant-spk from a git repo. I should just find the one for spk.
<kentonv>
ill_logic_, spk comes with Sandstorm
<kentonv>
you'll need to install Sandstorm directly on the Linux machine where you want to run spk
<kentonv>
probably you should choose a dev-mode install for this purpose
<kentonv>
(option 2 in the installer script)
<ill_logic_>
Yeah I'm not ready to install Sandstorm on this machine yet.
<ill_logic_>
So I guess I'm not sure what you're describing with these instructions.
<kentonv>
you need sandstorm on the machine to run spk, since it will register the app with the local sandstorm server for testing
<kentonv>
(normally vagrant-spk does all of this inside a VM)
<ill_logic_>
Okay. And filedrop can't do this in a VM for whatever reason.
<kentonv>
filedrop was developed before vagrant-spk existed, I think
<ill_logic_>
Is Sandstorm planning on normalizing the ways that development is done?
<kentonv>
the raw "spk" tool came first, and vagrant-spk was later built as a wrapper around it
<ill_logic_>
I feel like I've seen a few different setups in repos.
<kentonv>
vagrant-spk is the standard now but some apps haven't been updated.
<kentonv>
(and some people like raw spk better because it's lighter.)
<ill_logic_>
okay. well, it looks like davros won't have this issue.
<ill_logic_>
Maybe I'll just move right on to that. It sounded like you were saying it'd be easier in some ways anyway.
<kentonv>
yeah, Davros already implements a well-defined and standardized API, WebDAV
<kentonv>
but we'll need to extend sandstorm/bridge-proxy.c++ to support the WebDAV methods. Shouldn't be too hard.
<ill_logic_>
I guess I've yet to understand what all that means. The bridge-proxy is the communication hub between applications?
<kentonv>
I bet mnutt (Davros author) will be interested in working on this.
<kentonv>
bridge-proxy implements an HTTP proxy visible to the app, through which it can make HTTP requests to other apps.
<kentonv>
it converts HTTP requests into Cap'n Proto requests to send over Sandstorm's Cap'n Proto bus
<kentonv>
then sandstorm-http-bridge on the receiving end converts them back to HTTP requests
<ill_logic_>
So I guess my question for that is, would my app need to have WebDAV-specific code? Or would it work out of the box if, say, somebody implemented file sharing from FileDrop
<kentonv>
bridge-proxy is brand new and currently only supports basic HTTP methods. WebDAV adds some new methods like PROPFIND which will need to be added.
<kentonv>
WebDAV is a protocol for manipulating directory trees over HTTP
<ill_logic_>
It seems ideal to have an interface that works generally.
<ill_logic_>
I get the feeling that this isn't going to be done by the end of the day :-P
<kentonv>
so your app that wants to read from Davros would make a Powerbox request for a WebDAV API, and then the user would choose their Davros grain.
<ill_logic_>
Okay.
<ill_logic_>
So in principle, could FileDrop also implement WebDAV, but just never claim to have more than one level of directory?
<kentonv>
sure. Probably more work since FileDrop doesn't do that currently, whereas Davros already implements WebDAV (since WebDAV is the protocol the ownCloud client uses)
<ill_logic_>
Ah, okay I see.
<ill_logic_>
So what exactly is it that you've implemented?
<ill_logic_>
Recently?
<ill_logic_>
As far as moving files between applications.
<kentonv>
bridge-proxy was implemented recently
<kentonv>
which allows apps to talk to each other via HTTP, after a powerbox connection is made
<ill_logic_>
Oh. That wasn't possible at all before, okay.
<ill_logic_>
Powerbox only let you share with other users before?
<kentonv>
up until the end of December, Powerbox could only allow you to share a whole grain through another grain, e.g. adding a grain to a collection or sharing it to a rocket.chat room.
<kentonv>
It did not allow grains to connect to each other's APIs
<kentonv>
so grains could not talk to each other
<ill_logic_>
Okay. So it gave you an icon and let you delegate permissions?
<ill_logic_>
So people in that RocketChat room could look at the grain of that file?
<kentonv>
yes, Rocket.Chat could reshare the grain to users in the room, but could not access the grain directly
<kentonv>
pretty sure mnutt will be excited about this so figured I'd file an issue
<ill_logic_>
So basically I need to make Davros listen on the proxy? Or how exactly does this work?
<ill_logic_>
Or I need it to register what it will do via the proxy?
<kentonv>
the only Davros change needed is a change to sandstorm-pkgdef.capnp to define what APIs it supports. But bridge-proxy.c++ (in the Sandstorm repo) will need to be updated to enable *other* apps to consume the API.
<ill_logic_>
ah right, you mentioned that
<kentonv>
bridge-proxy is actually used by the app that calls the API, so not Davros
<kentonv>
(technically an app written directly against the raw Cap'n Proto interfaces wouldn't need any bridge-proxy changes)
<ill_logic_>
Is there documentation on how to edit the bridge proxy?
<ill_logic_>
Sorry
<ill_logic_>
how to configure for the bridge proxy
<ill_logic_>
in the pkgdef
<kentonv>
there's two things here. There's modifying Davros's pkgdef, and there's fixing bridge-proxy for use in the client app. These are actually separate.
<kentonv>
so you don't "configure bridge-proxy in pkgdef"
<kentonv>
what http-bridge does, in the client app, is it automatically sets the HTTP_PROXY environment variable when starting the app
<kentonv>
to point at the proxy implemented by bridge-proxy
<kentonv>
most HTTP libraries should respect the HTTP_PROXY variable automatically
<kentonv>
and so will make their requests through the proxy
<kentonv>
there's also a process you need to go through to request access in the first place. Unfortunately it's not documented yet. That's something I need to do soon...
<ill_logic_>
Well I mean, for modifying Davros, you configure *for* the bridge-proxy. That is, describe what I expose to it.
<ill_logic_>
Yes?
<kentonv>
no no, Davros doesn't use the bridge-proxy. It just exports an API. The client app uses bridge-proxy to help it use the API
<ill_logic_>
I thought the bridge proxy goes between Davros and my app
<kentonv>
the bridge-proxy lives in your app, set up by sandstorm-http-bridge.
<ill_logic_>
Okay. I got the bridge and the bridge-proxy confused. Let me re-read what you said.
<kentonv>
it's a compatibility tool. Technically you don't have to use it, if you use Cap'n Proto directly.
<kentonv>
so Davros doesn't actually know if you're using bridge-proxy or not.
<kentonv>
sorry, there are a lot of parts here. It might make the most sense to hold off until I get a chance to write some docs...
<ill_logic_>
So apps could have talked directly if they wanted the whole time?
<ill_logic_>
Okay.
<kentonv>
direct powerbox became possible in late december.
<kentonv>
but required raw Cap'n Proto -- for both the server and client apps
<kentonv>
bridge-proxy makes the client app not need raw cap'n proto
<kentonv>
for the server app, there's some new config in pkgdef that makes sandstorm-http-bridge take care of powerbox requests
<ill_logic_>
I see.
<kentonv>
these are two separate components that work together
<kentonv>
(and are actually both parts of sandstorm-http-bridge)
<ill_logic_>
A "powerbox request" is just a request to establish permissions? Or does it actually send data?
<ill_logic_>
Actually, I don't want to take your time explaining all this if you're going to write docs anyway. (Unless you particularly feel like explaining)
<ill_logic_>
Sorry for my lack of knowledge here. I'm happy to continue on this path, just let me know when you think it's a good time to try again.
<kentonv>
mostly just permissions. The requesting app does a window.postMessage() to Sandstorm in the browser, Sandstorm displays a picker to the user, the user picks what to connect to, and the app gets a postMessage() back with a claim token.
<ill_logic_>
In the mean time I'll find a simple file uploader and add it to my app.
<kentonv>
then the app needs to send that claim token to its server side, where it exchanges the claim token for an access token, which can be used to make requests to the other app's API.
HeyItsMeUrIRC has joined #sandstorm
<HeyItsMeUrIRC>
Hi!
<HeyItsMeUrIRC>
I need some help getting my Sandstorm instance working.
<HeyItsMeUrIRC>
I'm moving from another install.
<kentonv>
hi
<kentonv>
what seems to be the problem?
<HeyItsMeUrIRC>
I've backed-up the old server, installed a new instance on the new machine, and replaced the /opt/sandstorm on the new machine with the old install
<HeyItsMeUrIRC>
but it doesn't even open the port
<HeyItsMeUrIRC>
I can't connect
<HeyItsMeUrIRC>
I've allowed port 80 connections and used netstat, but it doesn't open anything
<HeyItsMeUrIRC>
(the config file is set to port 80)\
<kentonv>
are there any interesting errors shown in /opt/sandstorm/var/log/sandstorm.log?
<HeyItsMeUrIRC>
uh
<HeyItsMeUrIRC>
let me put this in a hastebin
<HeyItsMeUrIRC>
you'll immediately see the problem
<kentonv>
hmm this looks like the logs for a functioning server that is accepting requests. What's the timestamp on the log? Has it changed since the transfer happened?
<HeyItsMeUrIRC>
nope
<kentonv>
so it seems like Sandstorm never actually started
<kentonv>
what happens when you do `sudo sandstorm start`?
<kentonv>
and then `sudo sandstorm status` after that, to see if it's running?
<HeyItsMeUrIRC>
Sandstorm started. PID = 5498
<HeyItsMeUrIRC>
status tells me it's not running
<kentonv>
now that you did that, does the log have anything new at the end?
<HeyItsMeUrIRC>
tells me the server monitor dies
<HeyItsMeUrIRC>
and that the install directory isn't owned by rot
<HeyItsMeUrIRC>
root
<kentonv>
ah hah
<kentonv>
it sounds like when you transferred the files, you didn't keep the ownership exactly as it was before
<HeyItsMeUrIRC>
oshit
<HeyItsMeUrIRC>
should I just chown it?
<kentonv>
normally you need to use e.g. `cp -a`, or use tar's `o` option, to keep ownership.
<HeyItsMeUrIRC>
ah
<HeyItsMeUrIRC>
okay
<kentonv>
well, the problem is that there's a tree of stuff and some needs to be owned by root and some by the service user
<kentonv>
you need to make it match what it was on the old machine...
<HeyItsMeUrIRC>
okay we can fix this :P
<HeyItsMeUrIRC>
I still have the .tar and the old install on the machine
<kentonv>
I think tar usually saves ownership details by default, but then doesn't apply them by default when un-tarring
<kentonv>
but if you use the `o` option when untarring (and you are root), then it applies
<kentonv>
it might only work if the user IDs and group IDs are the same (numerically), though.
<kentonv>
if not you might have to go through and manually fix things. :/
<ill_logic_>
Hmm. I just tried to "vm up" on davros and I got
<HeyItsMeUrIRC>
now I can actually do my schoolwork
<kentonv>
ill_logic_: whoops, that sounds like a bug in Sandstorm!
<kentonv>
HeyItsMeUrIRC: Hooray!
<HeyItsMeUrIRC>
nice and fast now
<HeyItsMeUrIRC>
it moved from a 9 year old compaq I had laying around to a 48-core 156-GB RAM PowerEdge
<kentonv>
ill_logic_: sandstorm-http-bridge-internal.capnp shouldn't be used by Davros, so that's strange. Thanks for finding that. I'll make sure it is fixed in today's release.
<ill_logic_>
happy to help
<HeyItsMeUrIRC>
question for you tho: what do you think of gaming on sandstorm?
<ill_logic_>
there are games in the app store
<ill_logic_>
a couple
<HeyItsMeUrIRC>
I've been thinking about porting a few games over but I don't think they'd be used that much
<ocdtrekkie>
I always thought it'd be fun to have more games on Sandstorm.
<digitalcircuit>
WebGL might be an interesting attack surface for a Sandstorm app, though there's probably not much one could do with it by default.
<HeyItsMeUrIRC>
mostly thefounder.biz
<HeyItsMeUrIRC>
also, I'm working on a desktop and mobile client for sandstorm
<HeyItsMeUrIRC>
that's not a web page
<ill_logic_>
I heard about an open source MMO similar to second life. That would be pretty rad.
<ill_logic_>
Forgot what it was called.
<ill_logic_>
Just as a demo anyway.
<HeyItsMeUrIRC>
also; powerbox is awesome
<kentonv>
as you might expect of the owner of http://kentonshouse.com , games are a thing that interest me... :)
<HeyItsMeUrIRC>
shame that rocket.chat is really the only one really using it atm
<kentonv>
HeyItsMeUrIRC: We recently fully-implemented the ability for apps to export APIs via the powerbox, and other apps to use them. So there should be more powerbox usage coming soon.
daemoen has quit [Ping timeout: 240 seconds]
daemoen has joined #sandstorm
<HeyItsMeUrIRC>
you guys should add a temporary 'supports powerbox' section to the app store to encourage powerbox support
<kentonv>
heh, well, "supports powerbox" could mean so many different things
<kentonv>
I think a lot of apps are eager to support powerbox so now that it's there I suspect they won't need too much encouragement. :)
<kentonv>
we haven't actually announced it yet
<HeyItsMeUrIRC>
¯\_(ツ)_/¯
<kentonv>
at least the new app-to-app APIs part
<HeyItsMeUrIRC>
sandstorm's really all coming together and it's awesome
<HeyItsMeUrIRC>
I've been running it since early 2016 for almost everything
<HeyItsMeUrIRC>
also
<HeyItsMeUrIRC>
I can make app icons
<kentonv>
:)
<HeyItsMeUrIRC>
I honestly can't tell if that was sarcastic or not
<kentonv>
my smiley? Not sarcastic.
<HeyItsMeUrIRC>
:D
<HeyItsMeUrIRC>
but sandstorm's genuinely great
<HeyItsMeUrIRC>
and you guys need to set up a donate box or something
<HeyItsMeUrIRC>
I'd send a few litecoin your way
<kentonv>
the best way to "donate" is to sign up for Oasis (even if you don't plan to use it). Unfortunately we don't support cryptocurrency yet, maybe we'll add it at some point.