21:07 <dwrensha> zarvox: two factor authentication at the account level rather than the identity level is an interesting idea!

21:26 <zarvox> dwrensha: it feels like the more appropriate place to put it, when I think about it!

21:27 <zarvox> proof of authenticity as one of your loginIdentities is your first factor, and proof of access to the TOTP secret is the second

21:29 <zarvox> I'd want to look at how the identity-to-account login switcheroo works - I imagine that's where we'd need to prompt for the 2FA token

21:29 <dwrensha> there a method called something like `loginWithIdentity()`

21:30 <dwrensha> and it checks on the server whether the currently-logged-in identity is linked to the account requested

21:30 <dwrensha> `loginWithIdentity(accountId)`

21:34 <XgF> dwrensha: Ooh ooh ooh U2F support?

21:35 <dwrensha> XgF: see https://groups.google.com/forum/#!topic/sandstorm-dev/0oW2uiW9nI4

21:37 <zarvox> XgF: I don't know a ton about how U2F enrollment works; I've done a TOTP implementation before at AeroFS, but I could imagine having multiple kinds of MFA support, given appropriate demand :)

21:39 <maurer> kentonv: So, I finally got some time again, and tried to add the test you wanted w/rspt to an upgraded struct list in canonicalization. However, the current type signature of the canonicalization method makes that make no sense

21:40 <maurer> kentonv: Specifically, the canonicalization method takes in a messagereader or messagebuilder and converts it into a dynamic walk

21:41 <maurer> kentonv: As a result, there's no real way to feed the upgraded struct list reader I've got sitting in my test file to my canonicalizaiton. I can feed the backing reader, or I can re-encode it (causing an upgrade) and canonicalize that, but there's no way for me to canonicalize a message in upgraded form currently

21:43 <maurer> kentonv: As a result, either the testcase is unnecessary, or you implicitly want me to try to expand the interface to work with typed Readers rather than just MessageReaders

21:44 <asheesh> BTW kentonv is afk but will surely be back, probably 4ish pm or 5ish pm Pacific, and will be able to answer then.

21:45 <asheesh> i,i why do people want to make it HARDER to log into their Sandstorm accounts

21:46 <maurer> asheesh: yeah, no rush, I've been dragging my heels on writing up this testcase anyways

21:47 <maurer> asheesh: also, people wanting to make it harder to log into their accounts indicates they're putting things worth protecting in sandstorm :)

21:47 <asheesh> Bah you're an optimist, I'm sleepy today so I'm a pessimist today

21:47 <asheesh> I mean!

21:47 <asheesh> maurer: You're right, that is reassuring and plesant to hear!

21:49 <asheesh> Yay Mitar gave me a Hooray! emjoi

21:49 <asheesh> +/- typos

22:02 <Mitar> :-)

22:03 <Mitar> asheesh: does app store has stats on number of apps installed, how many grains are effectively used, and so on? or should I open a ticket for that?

22:03 <Mitar> also, stats how many people deleted the app and a nice histogram on time people had a grain in use

22:09 <XgF> zarvox: U2F enrollmen works by you calling the JavaScript U2F enrollment API?

22:10 <zarvox> XgF: reading up now :)

22:12 <isd> So, starting to play with talking to the sandstorm APIs in go. Would I be duplicating existing effort by writting wrappers for things?

22:13 <zarvox> Ahhh, enrollment hands me (the relying party) a public key, and then I request that the browser do a sign(), and then I check that the signature matches the enrolled key

22:15 <zarvox> So I think all I have to store serverside is the enrolled publickey. Nice.

22:16 <asheesh> isd: I think that would not be a duplicate of anything. But I'm not sure which APIs you want to wrap etc.

22:17 <isd> asheesh: hadn't really pinned that down, probably a function of what I need first

22:18 <isd> might wrap the HTTP stuff just as a warmup; would be neat to pull sandstorm-http-bridge out of the package, leaving *just* the go binary on the filesystem

22:18 <asheesh> Ross Light is the go-to Sandstorm & golang person, but his work is very sporadic/free-time-y on that.

22:18 <isd> asheesh: links to his stuff?

22:18 <asheesh> isd: I woud dig into the filedrop source code too

22:18 <asheesh> Let me find it one sec

22:19 <asheesh> https://github.com/zombiezen/filedrop

22:19 <asheesh> See also https://github.com/zombiezen/go-capnproto2

22:20 <isd> Yeah, I'd found the latter.

22:23 <isd> Doesn't look like filedrop actually uses any native sandstorm APIs. Well, time to get hacking.

22:23 <zarvox> :)

22:24 <asheesh> isd: If you feel like writing a Mailinator alternative... :D

22:25 <asheesh> Trying to think of what other APIs would be interesting to wrap.

22:26 <isd> asheesh: I'm probably going to need some of the ip networking stuff soonish

22:26 <isd> like I said, probably will be directed by what I end up needing

22:27 <isd> but for a start I think I can get it so you just swap in sandstorm.HTTPListenAndServe(nil) for your http.ListenAndServe(":8000", nil), and you can delete sandstorm-http-bridge

22:27 <isd> Right now I have a hello-world go package that has nothing but the go executable and sandstorm-http-bridge in it, which is kinda neat I think

22:28 <isd> smallest container ever.

22:28 <isd> spk is ~2MiB

22:29 <isd> Immediate plan is to do a thing that idles in IRC for me, that I can connect to from an IRC client on my laptop. Kinda thing people do with screen or tmux or such.

22:45 <asheesh> Nice, isd. You'll presumably end up using the "powerbox" to request real network access, fwiw.

22:45 <asheesh> Let me know if as you need help with that.

23:05 <kentonv> maurer: yep, looks like you're right. Never mind that test then.