00:00 <isd> You could try just adding the functionality right away, rather than re-write it later.

00:05 <TimMc> Haha, "Allston Christmas" is on the SandCal screenshots. :-D

00:07 <isd> I'm glad someone appreciated that :P

00:14 <abliss1> Ian Denhardt: is it possible to hack on the JS without rebuilding the rest of sandstorm? I've switched dev machines, and I don't have the spare 2+ days it would take me to get the c++ /ekam stuff building again.

00:14 <isd> You need to build node-capnp at least once, unfortunately.

01:16 <isd> ill_logic: so I've got like 85% of an app written that will let us share a tmux session and hit the same local dev install with a browser.

01:32 <abliss1> might be a good use for tailscale?

01:50 <isd> Eh, at this point I just have to slap an offer iframe on it and I'm done.

01:50 <abliss1> how does it get out of the sandbox?

01:54 <isd> There's a cli tool used by both users to connect to the grain via a websocket.

01:55 <isd> So it doesn't have to do outbound connections.

01:57 <abliss1> ah. there's also https://github.com/maxmcd/webtty I suppose

02:05 <isd> Somewhat similar. But this also let's you connect to the remote user's local sandstorm dev install.

02:05 <isd> Anyway, it's done, modulo a bit more testing.

02:06 <abliss1> how does that part work? tunnels an extra port besides the one sharing tmux, and the remote user bounces it back to the sandstorm?

02:06 <abliss1> (i can't test webtty because they don't provide an arm binary and its 'go get' is broken because of the golang module tirefire.)

02:09 <isd> Yeah, it tunnels both the tmux socket and the one the local sandstorm is listening on

12:36 <abliss1> another keybase alternative: cyph.com (they just emailed me an invitation)

12:45 <TimMc> I have to say, I instantly dislike it after just looking at their main page.

12:45 <JacobWeisz[m]> Wow, yeah, video as a background...

12:45 <TimMc> With motion and flashing.

12:46 <TimMc> and imagery reminiscent of the most eye-rolling hacker scenes on TV

12:49 <abliss1> yeah, the presentation certainly lacks the "authentic programmer-ui simplicity" appeal of keybase.

12:50 <abliss1> but maybe "savvy marketing -> sustainable business model" is how you avoid getting aquihired by zoom.

12:51 <TimMc> On a more substantive note, they use five different post-quantum cryptographic primitives, and I've only heard of any of them because I had a coworker who was contributing to the supersingular isogenies effort.

12:53 <TimMc> There's a risk in using quantum-crackable stuff, and there's a risk in using post-quantum algorithms and implementations that haven't been studied very much. There are reasons to go either direction, but... I'm not comfortable with the post-quantum stuff yet, personally.

13:00 <TimMc> I'm disappointed to see that they still promote it as being safe to use in a browser even though their WebSign model relies on HPKP, which basically all browsers have stopped supporting. And they don't have a browser extension as a replacement for it yet.

13:00 <TimMc> I don't see *anything* explicitly saying "and here's why you don't have to trust us".

13:02 <TimMc> I guess the question is what aspect of Keybase you want to replace.

13:16 <abliss1> the email claims it's a full alternative, and links here for a comparison: https://www.cyph.com/blog/cyph-pgp

13:27 <TimMc> Interesting.

13:28 <TimMc> Oh man, they actually patented the HPKP Suicide mechanis,.

13:28 <TimMc> *mechanism

13:29 <TimMc> They're not free-licensed, either.

13:29 <TimMc> Plus side: They actually seem to have a business model, maybe?

13:37 <abliss1> what's the suicide mechanism?

14:08 <TimMc> As I understand it: First load is treated as trusted and loads a core signature-checker library, and given an infinite cache lifetime. Second request gets an HPKP header that rolls to a nonexistant key, so it's impossible to load a new one.

14:08 <TimMc> The core lib then loads code from a different server and checks the signature on it.

14:08 <TimMc> So the bootstrapper can't be replaced on that browser, basically.

14:09 <TimMc> It's clever, but HPKP is dead.

14:09 <abliss1> but doesn't that still require the browser to honor hpkp for the bootstrap? or is it relying on the infinite cache lifetime?

14:10 <TimMc> It's relying on the cache lifetime to prevent the browser from trying to refetch it (which would break the whole app), and the HPKP backstops that by making sure that if it *is* refetched, the browser will treat the certificate as invalid.

19:18 <isd> I got an email about it a week and a half ago too.

19:23 <isd> I skimmed the website a bit and wrote it off after determining it wasn't open source, and the website made no mention of solutions to the problems that were the impetus for keybase in the first place -- I don't really want another bloated encryption swiss army knife, and social-media-as-trust-path was really the only reason I was ever interested in keybase.

19:23 <isd> ...and I'm not about to bite on any similar solution that requires a central, non-federated server

19:24 <abliss1> Word.

20:01 <isd> As it turns out, "module a bit more testing" found some bugs :(

22:04 <isd> For the past few days my sandstorm box has been seeing a lot of spikes in CPU activity -- mostly from mongo, but some other sandstorm related processes too. Has anyone else noticed this, or is it just me?

22:06 <isd> It's been seriously degrading the responsiveness of the server, and I don't think I changed anything.

22:12 <isd> hm, definitely not sandstorm -- still getting spikes from other processes after stopping it.