ecloud_ has quit [Remote host closed the connection]
axx_ has quit [Ping timeout: 246 seconds]
axx_ has joined #sandstorm
jemc has joined #sandstorm
frigginglorious has quit [Quit: frigginglorious]
jemc has quit [Ping timeout: 260 seconds]
raoulzecat has joined #sandstorm
sauko has joined #sandstorm
<sauko>
hi!
<sauko>
Does anyone have any tip on how to install sandstorm in a pi with raspbian?
<zarvox>
Sandstorm only runs on x86_64, so short of running it in a VM (which I don't recommend for performance reasons), I think you're out of luck running it on the pi.
<zarvox>
We only support x86_64 to avoid fragmenting the package ecosystem, since packages ship binaries, and because mongodb, which we use, currently only supports x86_64.
<sauko>
oh :(
<sauko>
ok, thanks zarvox. Just trying to create a small app server for a collective... tried yunohost, but I think sandstorm is much better, that is why I was trying
<zarvox>
You can totally spin up a VM for a Sandstorm install on Digital Ocean or another cloud provider, or any x86_64 server you might have running around. :)
<isd>
So I had a thought. It occurs to me that most mobile carriers provide the ability to send sms to a phone via an email address, e.g. (in the US at least) mail sent to <phone-number>@vtext.com will be delivered to <phone-number> as an sms, provided that it's a verzion number.
<isd>
I realized the only thing stopping one from absuing the email login on sandstorm to do sms login is that the email it sends is like ~250 charsr
<isd>
*chars
<isd>
But the token would easily fit in something that looks a lot like your standard two-factor auth texts.
rgrinberg has joined #sandstorm
frigginglorious has joined #sandstorm
amyers has quit [Read error: No route to host]
asmyers has joined #sandstorm
jemc has joined #sandstorm
sknebel has quit [Quit: sknebel]
sknebel has joined #sandstorm
rgrinberg has quit [Ping timeout: 252 seconds]
frigginglorious has quit [Quit: frigginglorious]
frigginglorious has joined #sandstorm
rgrinberg has joined #sandstorm
frigginglorious has quit [Quit: frigginglorious]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 252 seconds]
frigginglorious has joined #sandstorm
kecors has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 240 seconds]
asmyers has quit [Read error: Connection reset by peer]
nwf has joined #sandstorm
pili has joined #sandstorm
<pili>
I'm trying to get my sandstorm back up after installing Jitsi on the same box. I already uninstalled jitsi and nginx but am still getting address in use error http://pastebin.com/u7Yk2pUQ
<asheesh>
Howdy pili
<pili>
hey asheesh
<asheesh>
I believe this is because of an nginx process or similar. How about we take this to private messages? I'll PM you.
amyers has quit [Read error: Connection reset by peer]
amyers has joined #sandstorm
iangreenleaf has joined #sandstorm
<iangreenleaf>
Has there been any interest in porting Huginn to Sandstorm? It looks like it would be a great project to have on the platform, and it's in need of good deployment options.
<dwrensha>
Timers are part of "progres on the Powerbox"
<iangreenleaf>
Yeah, scheduling tasks + ability to handle incoming API requests ought to take care of it. It certainly complicates the integration, though.
<dwrensha>
iangreenleaf: I think you mean "outging API requests"?
<asheesh>
Well I think iangreenleaf means, "the app wakes up when e.g. github web hook pings it" which depending on the huginn integration, is adequate
<iangreenleaf>
right
<dwrensha>
I think we can already handle that
<asheesh>
Exactly.
<dwrensha>
I guess I'm just confused because the use case that I've always imagined is Huginn controlling twitter bots
<dwrensha>
for which you would need outgoing api requests
<asheesh>
Yeah, for that, indeed.
frigginglorious has quit [Quit: frigginglorious]
<Mitar>
I am more curious how to handle real-time twitter stream inside sandstorm
<Mitar>
which seems to me to require always-on program
<Mitar>
which seems also a common use case for huginn
<isd>
Two questions: (1) I've seen references in issues to the ability of an app to keep itself from being stopped, but am having a hard time finding relevant docs; where would I look for that? (2) Is there a provision in sandstorm for an app to just get a raw tcp connection to somewhere?
<dwrensha>
^ this test app is the only thing that uses wake locks, as far as I know
<dwrensha>
and I don't think there is any documentation yet
<isd>
dwrensha: thanks
<dwrensha>
isd: an admin user can get a hold of `IpNetwork` and `IpInterface` capabilities and pass them to a grain.
<gwillen>
hello sandstormers
<gwillen>
has anything happened to alpha that I should know about?
<dwrensha>
gwillen: have you noticed anything about alpha that we should know about?
<dwrensha>
it looks like usual to me
<gwillen>
well, I got logged out, and I logged back in, and I can't do anything or access anything
<gwillen>
"Unauthorized! :("
<dwrensha>
eek!
<gwillen>
and I can't see any of my grains
<gwillen>
and my one grain that I have a link to (tinyrss) says I don't have permission but can request it
<dwrensha>
gwillen: what login provider are you using?
<gwillen>
email
<dwrensha>
do your grains show up in the grain list?
<gwillen>
nope, it's empty
<gwillen>
I did double-check that I have received an email from alpha at this address in the past for login purposes
<gwillen>
but I still suspect I have somehow accidentally been deposited in an account that is not the same account
<gwillen>
and that the real account exists somewhere in accessible
<gwillen>
inaccessible*
<dwrensha>
yeah, that sounds consistent
<gwillen>
oh, it also directed me to the 'fill in your profile' page when I logged in
<dwrensha>
did you have any other identities linked to the account?
<gwillen>
not that I remember
kecors has quit [Quit: Leaving]
<dwrensha>
also, note that emails are case sensitive in sandstorm land
<gwillen>
and I thnk I had previously set my pronoun to 'he', and it is now 'they', which is consistent
<dwrensha>
right, it sounds like you have been dumped into a fresh account
<gwillen>
hmmmmm, that sounds hazardous when combined with "no way to see if you have an account" / "no distinguisher between logging in versus creating a new account"
<gwillen>
seems like a lot of people are likely to end up with multiple accounts
<dwrensha>
is it possible that the email you entered was not exactly the same as the previous one?
<gwillen>
it's unlikely but I can't rule it out
<gwillen>
but I have never entered it with any caps before on purpose
<gwillen>
and the email from a year ago has it spelled the same as now
<gwillen>
I feel like, because it seems to have been a whole year since I last had to log in, there's lots of potential for any sort of change in how email addresses are represented or canonicalized to cause this outcome
<zarvox>
did you previously use Google or GitHub login and start using email address login?
<gwillen>
zarvox: I do not believe so, and I do also have an email-login email from a year ago, which I believe represented a successful login at the time
<gwillen>
hmmmmmmmm zarvox I was lying I think
<zarvox>
gwillen: I vaguely believe your use of alpha predates email token login as a feature
<gwillen>
it seems like my real login was with github
<gwillen>
so it's actually fine
<gwillen>
but now I'm puzzled
<zarvox>
well, you can link the accounts now!
<gwillen>
because I do have a token-login email from a year ago
<gwillen>
perhaps I went through this exact same problem a year ago
<gwillen>
and then forgot
<zarvox>
Heh.
<gwillen>
I can definitely link them but this seems like there are some usability questions here
<dwrensha>
we should detect when accounts have matching confirmed email addresses
<gwillen>
that would have worked here
<gwillen>
my primary email on the real account was the email I was trying to log in with
<gwillen>
if you detected my accidental account creation as a login attempt
<zarvox>
That seems like a reasonable heuristic
<zarvox>
For organizations running their own internal server, I expect most will only enable a single login provider
<gwillen>
I do also feel this is some kind of argument for maintaining the traditional notion of a distinction between "create accout" and "log in"
<gwillen>
I assume that someone is opposed to that distinction, since sandstorm does not mostly seem to maintain it
<dwrensha>
gwillen: would it have been better if the profile editor that popped up had some clear message like "Hello! this is your first time on this Sandstorm server! please enter this profile information."
<gwillen>
dwrensha: well, it would have been a clearer warning that I had committed a mistake, although I was already pretty sure that that had happened
<dwrensha>
I'm trying to understand what you want from a "create account" / "log in" distinction
<gwillen>
I want to not have to play guess and check with all my email addresses and login providers
<gwillen>
with a 5 minute email delay or a password lookup after each one
<gwillen>
I assume maybe you're going for the posture that having the server reveal the existence of an account is a security problem
<gwillen>
which does pretty much rule out any solution to my UI complaint
<gwillen>
but I do think it's a bad experience
<zarvox>
it's hard with delegated auth, because we can't check in advance of you attempting to log in if you already have an account associated with e.g. that GitHub user
<gwillen>
(also, I do feel like I'm currently getting the "but _why_ in particular do you not want us to drop heavy things on your toes" treatment, which I do find annoying but I'll bear with it because I know you guys are generally flexible and willing to listen)
<zarvox>
the preemptive check only works if you can uniquely identify the user to test existence *before* the redirect
<gwillen>
hmmmmm, interesting
<gwillen>
I see where for not-email things it's harder
<gwillen>
for email of course you can tell immediately without making them wait for the token to show up
<zarvox>
I agree that the flow has its flaws
<zarvox>
for email we can plausibly do better
<gwillen>
yeah for nonemail it's an interesting problem
<zarvox>
Hopefully that adds some context.
<gwillen>
in my specific case, "has logged in on this computer before" is a big hint
<gwillen>
like, you could suggest what I used last time
<gwillen>
that will probably solve it in a lot of cases
<gwillen>
where it's only one person on one computer and the only problem is session expiration
<zarvox>
Yeah, you could stuff something in localStorage, but I'm not sure how to hint that in the UI. And then yeah, there's the multiple-users-sharing-a-browser problem.
<gwillen>
right, in the presence of multiple users it's harder without something like a chooser UI
<zarvox>
A button in the Log in: "as <last-identity-used>" at the top of the list? possibly wraps awkwardly
<gwillen>
like, "log in as <list of people who have logged in before>"
<gwillen>
like the OS X friendly login dialog
<dwrensha>
maybe we could put something in localStorage *only* in the case where the logout was due to session expiration
<zarvox>
show the identity card
<gwillen>
I'm sure Windows and various fooDMs have something similar
<gwillen>
zarvox: yeah that would definitely work
<gwillen>
at least in the one-user case
<zarvox>
I think we lose track of the icon asset url
<zarvox>
though maybe we could save that in localStorage too
<gwillen>
icon asset?
<zarvox>
the avatar icon
<gwillen>
ahhh
<zarvox>
it's part of your "identity card" which is the name we gave to the button you click when you're choosing which identity to open a sharing link as, for instance
<gwillen>
I realized while writing it up that our work sandstorm instance uses email-token exclusively
<gwillen>
which is why I was so sure that's what I used
<gwillen>
because I've used it repeatedly within recent memory
<zarvox>
:)
<gwillen>
(also because that's what I _would_ have used were it available.)
<zarvox>
gwillen: I imagine most company-internal deployments will use a single login provider
<gwillen>
yeah, this problem is probably totally solved with corporate SSO
<gwillen>
although if they do use email, a one-click button to refresh an expired session is still helpful
<zarvox>
LDAP or Google or SAML or even just always-email
<gwillen>
yeah
<gwillen>
for not-email it will be one-click no matter what, but for email this proposal reduces it from "enter address and click" to one-click
<gwillen>
(modulo actually retrieving the token from your email but that can't be reduced)
<gwillen>
also, at work we have a situation where we have a legacy domain that we have to use with google apps because it can't be changed
<gwillen>
and a not-legacy domain we use with everythign else
<gwillen>
so even in a corporate setting with email, one may have to look up WHICH email.
<zarvox>
Yeah. There's one catch, which is that if you have a GitHub identity and you're currently signed into (i.e. have cookies on github.com for) a *different* GitHub account, the identity card will do a possibly-confusing thing
<gwillen>
yeah, I thought about that and noted it in the writeup as a thing
<gwillen>
I concluded that the user, who was JUST reminded by the identity card of who we think they are, will hopefully be guided through the github picker by that reminder
<gwillen>
but it's definitely a possibility for confusion
<gwillen>
if you assume that sandstorm and github session expiration are not synchronized, there's a _good_ chance that the identity we have for you will be available in the github picker list
<zarvox>
Yeah. Sadly GitHub's login API doesn't allow you to hint the desired identity/reject a different identity.
<gwillen>
yeah, sadness
<zarvox>
I guess we could also hack around that with more localStorage recording - save expectedLoginIdentity and check if they match when you return
<gwillen>
and then pop up a box saying "we through you were A, but you're B -- continue or retry?"
<gwillen>
or something?
<gwillen>
we thought*
isd has quit [Ping timeout: 246 seconds]
<gwillen>
I was sort of figuring at that point you'd just go with whatever they picked, but ... it gets messy either way :-\
<gwillen>
'go with it' probably works poorly and makes a confusing situation even worse