kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
<blowfist>
mnutt: uploading to subdirectories is broken
<mnutt>
ah shoot, I'll take a look
<blowfist>
JacobWeisz[m]: nice find, I too seldomly actually use subdirectories
<JacobWeisz[m]>
I always use them, I just forget to test them...
<isd>
No, drag & drop did not work on 0.25
<isd>
Or, at least consistently anyway
<JacobWeisz[m]>
I know it still worked for me when I tested it. But then when trying to upload to my subfolder, it didn't. And I didn't make that connection.
<JacobWeisz[m]>
There might be other oddities to discover though, considering.
<JacobWeisz[m]>
TTRSS update is live now
<mnutt>
ok, davros 0.26.1 is publishing, fixes the subdirectory issue
<JacobWeisz[m]>
Woo!
<mnutt>
drag and drop works ok for me in firefox and chrome, but I haven't compared it to any previous versions
<mnutt>
one issue I noticed just right now is drag-and-drop a whole directory in firefox just creates a file with the directory name :-/
<JacobWeisz[m]>
If everything works on the latest, what was broken when is mostly academic.
<JacobWeisz[m]>
That sounds fun. I've never tried drag dropping a folder.
<isd>
In fairness, I only tested this because at some point somebody said it was broken. I don't normally even use a graphical file manager.
<JacobWeisz[m]>
I use Davros like you use FileDrop.
<JacobWeisz[m]>
I also do some mild web publishing from a Davros grain, it's my home automation system's update repo.
<isd>
I want a command line tool that will just take a file path on my local machine, create a fresh davros//filedrop/whatever grain, and print a sharing link to stdout.
<isd>
There's some machinery needed to make that happen.
<isd>
But I think it would be really cool
griff_ has joined #sandstorm
<JacobWeisz[m]>
Davros 0.26.1 is now approved
<JacobWeisz[m]>
I might play with the WebDAV side a bit more now that it's been patched up.
<blowfist>
isd: I agree with you, the ability to make new grains/sharings/etc from the command line would be absolutely fantastic
<blowfist>
JacobWeisz[m]: I just use curl and gzip in my shell script webDav implementation :)
<JacobWeisz[m]>
Note Ian that Davros shows file modified time, unlike FileDrop ;)
<JacobWeisz[m]>
blowfist: You shared that script, yes? Log has gotten crazy long today.
<JacobWeisz[m]>
It feels like 2016 in here today.
griff_ has quit [Quit: griff_]
<blowfist>
JacobWeisz[m]: I don't think I did share it, let me link it (I don't yet have a git repo for it, so it's going to be a direct link)
<isd>
ocdtrekkie: yeah, I'd been thinking of switching for exactly that reason, but uploading is kindof a critical feature I wasn't wiling to do without :P
<JacobWeisz[m]>
I would definitely post this somewhere you can share with other Sandstorm users easily!
<blowfist>
yeah, I'll set up a git repo for it
<JacobWeisz[m]>
The mailing list might be a good place to announce it to others when you do!
<blowfist>
you just need to call it with the webkey as the first argument, I usually just make a new script like this : webkey=https://api...#... \n sh ~/path/to/davros.sh $webkey $@
<blowfist>
so you could set up a different entry script for every webkeys you want
<blowfist>
JacobWeisz[m]: good to know, I'll make sure to do that :)
griff_ has joined #sandstorm
<blowfist>
btw JacobWeisz[m] I'm nniro
griff_ has quit [Quit: griff_]
<isd>
So, besides ttrss I don't think anything still uses HackSession.httpGet or HackSession.getUiViewForEndpoint; how long do we wait before deleting those?
<JacobWeisz[m]>
Sadly I don't think Kenton's opt-in telemetry gets package versions, since I don't see that on the statistics tab.
<JacobWeisz[m]>
Probably wait a few months for people to update TTRSS?
<JacobWeisz[m]>
What does getUiViewForEndpoint do?
<JacobWeisz[m]>
httpGet I think is a high priority thing to delete.
<JacobWeisz[m]>
I wonder if Kenton would have any insight on the likelihood of private packages existing that use it.
_736b has joined #sandstorm
<isd>
getUiViewForEndpoint() gets you a capability that you can use to make http requests. It is strictly more powerful than httpGet, which only does Get and (due to being a method on the session itself) requires a user connected to it.
<isd>
I don't know what if anything uses it.
<isd>
I left a comment on the relevant GitHub issue; we can discuss the policy more there.
<JacobWeisz[m]>
I think then it's similarly critical to delete. As long as Sandstorm apps can invisibly call these, it presents a potential trust issue for hostile apps.
<isd>
+1
_736b has quit [Quit: \0]
griff_ has joined #sandstorm
michaeln3 has joined #sandstorm
xet7 has joined #sandstorm
xet7 has quit [Quit: Leaving]
xet7 has joined #sandstorm
_whitelogger has joined #sandstorm
griff_ has quit [Quit: griff_]
<JacobWeisz[m]>
I submitted a website PR that probably works.
abliss_ has quit [Read error: Connection reset by peer]
griff_ has joined #sandstorm
griff_ has quit [Quit: griff_]
<isd>
Reminder, office hours in ~20 min
<isd>
Going to be a minute or two late.
<JacobWeisz[m]>
My phone is gonna drop soonish, so my participation will be spotty.
<JacobWeisz[m]>
Driving through an area we refer to as "the forest" around here shortly.
<abliss>
but if chrome ends up obscuring all urls, then it becomes less of a concern i suppose.
<JacobWeisz[m]>
I'm hoping that attempt dies like the last one.
<JacobWeisz[m]>
Substituting the address bar with a search engine is a terrible choice.
<JacobWeisz[m]>
The latest Firefox makes it very hard to disable, even if you have a separate search bar.
<JacobWeisz[m]>
Internal network addresses get searched for instead of being resolved by default.
<kentonv>
blame AT&T for running a DNS service that resolves all words to its own "DNS helper" bullshit
<JacobWeisz[m]>
You have to individually remove search suggestion providers from settings so there are no valid ones, and then it will just error instead of searching if it doesn't like the URL.
<kentonv>
browsers can't tell what's an internal service vs. AT&T's DNS hijacking...
<JacobWeisz[m]>
But that's part of the ISP service. Big tech's prevailing opinion that Google is good and AT&T is bad, so we should just redirect everything through Google is inherently harmful.
<JacobWeisz[m]>
A lot of very bad browser behaviors are justified essentially by that worldview. That Google implementing a service is better than your ISP doing it.
<JacobWeisz[m]>
Your ISP is not a monopoly though, and Google is one.
abliss has quit [Disconnected by services]
<kentonv>
unfortunately, most ISPs are, in fact, monopolies
abliss has joined #sandstorm
<kentonv>
within their particular service areas
<JacobWeisz[m]>
A small regional monopoly is much less worrisome than a global monopoly.
abliss has quit [Disconnected by services]
abliss1 has joined #sandstorm
abliss has joined #sandstorm
<JacobWeisz[m]>
Essentially this is another act of harmful decentralization, where things that should be handled by your local ISP are getting shunted off to the evil empire direct.
<JacobWeisz[m]>
centralization*. My phone likes the antonym more, obviously.
<kentonv>
AT&T and Comcast aren't exactly small regional players. If all ISPs were like Sonic.net or US Internet then I'd be pretty happy.
<abliss>
Break Up Ma Bell!
<kentonv>
though my problem with AT&T is they are subverting DNS into being a search engine which just breaks tons of things. I'd be pissed if any small player did that too.
<kentonv>
(well, just one of many problems with AT&T, but the one that was mentioned above)
<isd>
Verizon does this as well.
<kentonv>
Google is more of a vertical monopoly, where AT&T and Comcast are horizontal (within the regions they control)
<JacobWeisz[m]>
But now my browser is hijacking my URL bar to be a search engine instead. I don't see how that's better.
<JacobWeisz[m]>
Especially when it does it even when I enable the separate search bar up top.
<kentonv>
Personally I like the UX of a single bar but it does seem like a bug if enabling a separate search bar doesn't turn off searches in the URL bar.
<JacobWeisz[m]>
The problem is the single bar frequently leaks internal URLs to outside parties.
<JacobWeisz[m]>
Which is, in an enterprise environment, horrible.
<kentonv>
you mean hostnames, not full URLs, right?
<JacobWeisz[m]>
Nope
<JacobWeisz[m]>
Whatever is in the bar
<kentonv>
Seems like a pretty serious Firefox bug if it's not recognizing fully-qualified URLs and avoiding sending them to search...
<kentonv>
specifically, anything with a "https://" prefix should not be sent to search
frigginglorious has joined #sandstorm
abliss has quit [Remote host closed the connection]
abliss has joined #sandstorm
<abliss>
another wild (and probably bad) idea: could we embed an auth token inside some subrange of an ipv6 address?
frigginglorious has quit [Remote host closed the connection]
<abliss>
Ok, I threw some words up on the linked sandMD doc. I gotta run, and don't have time to do a good job, but at least it's not blank. All edits welcome.
<abliss>
(is sandMD the right platform for this? I like how Google Docs gives revision history and threaded comments in the sidebar. Does etherpad have those yet?)
griff_ has joined #sandstorm
<abliss1>
Ian Denhardt when you get a chance, i'd love a link / doc / example to using a grain's webkey in the url path.
abliss has quit [Read error: Connection reset by peer]
<JacobWeisz[m]>
kentonv: I shouldn't have to enter https:// to avoid sending URLs to search.
<JacobWeisz[m]>
"sandstorm.io" doesn't trigger a search, but "host.internal.tld" does.
<kentonv>
but you said it wasn't just hostnames...
<JacobWeisz[m]>
If you have path after that, it behaves the same.
<JacobWeisz[m]>
Explicitly typing out https:// is the only way to avoid everything in the URL bar from ending up in a search query for an internal URL.
<JacobWeisz[m]>
And prior to this, I haven't had to type that out since the 90s, generally.
griff_ has joined #sandstorm
<JacobWeisz[m]>
"host.internal.tld/full/path" triggers a search.
<TimMc>
Setting keyword.enabled=false should put a stop to that.