<mwcampbell>
Hi. I just discovered capnproto RPC. Interesting. Has anything beyond level 1 actually been implemented yet?
<dwrensha>
mwcampbell: capnproto-c++ has support for persistent capabilities
<kentonv>
aka Leve 2
<kentonv>
Level 2
<kentonv>
Level 3 is coming soon.
<kentonv>
Level 2 is mostly a convention; apps ultimately have to implement the hard parts.
<mwcampbell>
So would it be feasible to extend Sandstorm so that apps can expose a capnproto RPC protocol, e.g. for mobile and other non-web clients?
<mwcampbell>
IIUC, so far Sandstorm only uses capnproto RPC internally.
<dwrensha>
yes, this is definitely something we want to enable
<kentonv>
mwcampbell: absolutely, that's the plan
<kentonv>
but first we need to define a standard crypto transport for capnp on the web
<kentonv>
TLS is not quite right as-is because it doesn't provide for introductions.
<kentonv>
at least not efficiently
<mwcampbell>
It seems that one disadvantage of capnproto RPC compared to HTTP is that with capnproto RPC, the application has to be aware of connections (and more to the point, disconnection), whereas with HTTP, as far as the application is concerned, each request is independent. And with something like Google's QUIC transport, there are no connections IIUC.
<mwcampbell>
HTTP's statelessness might make it better for some things, like mobile clients roaming between networks
<mwcampbell>
I guess the downside is that there has to be a well-known server to connect to
<kentonv>
mwcampbell: I argue the opposite: HTTP's statelessness makes it incredibly hard to express fundamentally stateful interactions
<kentonv>
with stateless HTTP, it ends up being necessary to sync with the database after every operation, and distributed consistent storage is a Hard Problem.
<kentonv>
so e.g. if you have a photo service, say you want to load a photo, apply several edits, then save it. With a simple HTTP API, you'll probably end up loading and saving the photo for every operation
<kentonv>
(if they are done as separate HTTP requests)
<kentonv>
and you'd better hope that subsequent requests actually get the up-to-date version of the photo and not a previous version. That's actually hard to do in a distributed system without lots of latency.
<XgF>
Thoughts on tunneling over WebSockets or similar for firwewall compatibility?
<kentonv>
but with Cap'n Proto you load, get a capability, apply each operation as a method call on the capability, then save when you're done
<kentonv>
the down side is that one of those method calls might throw a "disconnected" exception, in which case you have to start over from the beginning. Of course, HTTP can have network problems too.
<kentonv>
XgF: yeah, Cap'n Proto over WebSocket is something we'll want to implement, mostly for the sake of browsers
<XgF>
:)
<XgF>
I guess the other option would be SCTP/UDP as WebRTC uses
<kentonv>
but introductions will be slow. My ideal transport allows zero-round-trip introductions, and there just aren't any transports I've found which have considered this case.
<kentonv>
so if Alice intros Bob to Carol, Bob should be able to start sending encrypted messages to Carol without waiting for any round-trip handshake first
<kentonv>
Cap'n Proto cares deeply about avoiding round trips
<mwcampbell>
kentonv: How about Chromium's experimental QUIC transport?
<XgF>
This sounds similar to the pain of layered roundtrip stacking which causes a lot of extra latency for TLS
<kentonv>
mwcampbell: QUIC doesn't have any particular support for introductions.
<kentonv>
it supports zero-round-trip startup when connecting to a server you've connected to recently
<kentonv>
but that's different from an introduction.
<mwcampbell>
Connecting to a server you've connected to recently is the common case, though, so it seems to me that zero-round-trip startup in that case is most important.
<kentonv>
yes, QUIC is great for the problem it is trying to solve
<kentonv>
which is optimizing HTTP interactions
<mwcampbell>
Though I guess what I just said shows a bias toward connecting to a small number of centralized services
<kentonv>
something like that. :)
<kentonv>
in an ideal world, I would want DNS to be replaced by a Cap'n Proto service which _introduces_ you to the requested host.
<kentonv>
and then you could have zero-round-trip on the first connection to a new service
<kentonv>
generally, a lot of interesting designs become possible if introductions are fast
<kentonv>
to support the web stack, we'll also need to support Cap'n Proto over WebSocket (browser-to-server) and WebRTC (browser-to-browser)
<kentonv>
but in those cases introductions will necessarily involve a bunch of round trips
<XgF>
WebRTC is good for browser-to-server too since it's lower overhead
<kentonv>
XgF: hmm, maybe. I need to get more familiar with how WebRTC is actually used.
<XgF>
WebRTC provides a multiple stream, packet oriented, ordered or unordered, reliable or unreliable transport. It's pretty great
<mwcampbell>
I think WebSocket would be better for browser-to-server. A lot of infrastructure assumes that all connections to web application servers from the outside world are over HTTP[S]
<XgF>
mwcampbell: Sure, but if you can prefer WebRTC, its' a better protocol
<mwcampbell>
Any idea how you'll handle NAT traversal for introductions, for the ideal non-browser case?
<kentonv>
ideally the transport should be UDP-based, and then we can (try to) do hole-punching
<mwcampbell>
Presumably you want to support scenarios like Alice's phone on her corporate network being introduced to Bob's phone on his mobile carrier's network, both of which will no doubt be behind NAT
<kentonv>
with a UDP transport we can also automatically deal with IP addresses changing, as long as not both ends change at once
<kentonv>
and we can avoid spoofed reset packets
<kentonv>
etc.
<kentonv>
so, lots of reasons to prefer it. A lot more work, though.
<kentonv>
oops, I gtg -- it's Game of Thrones time. :)
<mwcampbell>
Of course most mobile apps these days don't even attempt direct connections between users' devices, as far as I know; everything goes through a central service, usually HTTP-based
<kentonv>
we should fix that! :)
<XgF>
I'd start with a transport layer over any sequenced, reliable, packet-based transport and expand from there. Start simple :-)
<kentonv>
be back in a few hours. ttyl
bb010g has quit [Quit: Connection closed for inactivity]
bb010g has joined #sandstorm
paroneayea has quit [Read error: Connection reset by peer]
paroneayea has joined #sandstorm
Fernandos has quit [Ping timeout: 264 seconds]
kentonv has quit [Ping timeout: 255 seconds]
jadewang has quit [Ping timeout: 265 seconds]
jadewang has joined #sandstorm
kentonv has joined #sandstorm
gopar has quit [Remote host closed the connection]
paroneayea has quit [Read error: Connection reset by peer]
paroneayea has joined #sandstorm
todayman has quit [Ping timeout: 244 seconds]
todayman has joined #sandstorm
logbot__ has quit [Remote host closed the connection]
logbot__ has joined #sandstorm
logbot__ has quit [Excess Flood]
logbot__ has joined #sandstorm
jadewang has quit [Remote host closed the connection]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 250 seconds]
Fernandos has joined #sandstorm
zarvox has quit [Ping timeout: 245 seconds]
mwcampbell has quit [Quit: Leaving]
zarvox has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 244 seconds]
mquandalle has joined #sandstorm
jadewang has joined #sandstorm
<mquandalle>
Hi
<mquandalle>
I'm trying to play with sandstorm on my local machine, but I guess I'm in a weird state
jadewang has quit [Ping timeout: 265 seconds]
<mquandalle>
When I sudo sandstorm start --verbose it says "Sandstorm started. PID = <something>"
<dwrensha>
ok
<mquandalle>
but then the process is not is ps -aux (and there is no server responding on localhost:8060)
<dwrensha>
is there anything interesting in /opt/sandstorm/var/log/sandstorm.log?
<mquandalle>
this is probably the file I was looking for :)
<mquandalle>
ok, simply removing /opt/sandstorm and reinstalling sandstorm worked
<dwrensha>
I'm not sure what the easiest way is to wipe mongo's state. Usually when I find myself in a situation like yours I just remove all of sandstorm
<mquandalle>
yep :-)
<mquandalle>
So I was able to reproduce my system froze by using meteor-spk dev
<mquandalle>
But this time it seems it didn't corrupt mongodb
<dwrensha>
eek
<dwrensha>
you should report an issue on github
<XgF>
TBH "meteor-spk freezes system" doesn't sound like a meteor-spk problem...
<XgF>
mquandalle: What kernel?
<mquandalle>
4.0.2-040002-generic #201505081529 SMP Fri May 8 15:30:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
<mquandalle>
(reproduced again with meteor-spk v0.1.3)
<dwrensha>
heh, sounds like you may have hit the same bug that zarvox and others have hit
<XgF>
mquandalle: Yes, but that makes a sharing URL, doesn't share to a person
<mquandalle>
you can see etherpad "Share" button as an example
<mquandalle>
I'm trying to do the same thing for LibreBoard
<mquandalle>
hum, yes you are right
<mquandalle>
so currently if someone "unshare" a libreboard grain, I have no way to detect it and to remove the user from the member list
<mquandalle>
firstly because currently “the user” is ambiguous
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 246 seconds]
gopar has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 256 seconds]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 264 seconds]
dwrensha has quit [Ping timeout: 256 seconds]
jadewang has joined #sandstorm
mort___ has joined #sandstorm
jadewang has quit [Ping timeout: 272 seconds]
<kentonv>
mquandalle: Currently you don't get any notification until the next time the affected user tries to open the grain. Note that if they have the grain open at the time of the change then their session will be reset by Sandstorm (forcing a page refresh) so you'll get notification immediately.
<mquandalle>
Yes, my problem if is someone remove a permission to a user
<kentonv>
perhaps some day we'll let apps subscribe to sharing updates, but I'm not sure if we're ready to offer an API at the moment
<mquandalle>
I need to remove the user to the list of board member
<kentonv>
how bad is it if that list isn't up-to-date with the real sharing graph?
<mquandalle>
Not super bad, but its confusing
mort___ has quit [Quit: Leaving.]
<mquandalle>
users will be able to assign someone who doesn't have access to the board
<mquandalle>
+ they will see him in the members list on the right sidebar
<kentonv>
instead of showing a "members list" in-app, would it make sense to rely on Sandstorm to tell the user who has access?
<mquandalle>
That works for etherpad documents, but important features of LibreBoard rely on knowed the list of members
<mquandalle>
eg, assigning a task to someone, doing a @mention
<mquandalle>
filters
<kentonv>
hmm, well those at least work somewhat-ok if past members are still visible. But a bit confusing, yes.
<mquandalle>
and I have the same issue on the other direction, when someone share the grain
erikoeurch has joined #sandstorm
<mquandalle>
I won’t be able to assign a task to someone until he connects to the grain
<kentonv>
yeah...
<mquandalle>
+ I won’t see him in the member list
<kentonv>
we intend to implement share-by-identity at some point
<mquandalle>
share-by-entity is one step
<kentonv>
and then, yes, you need an API to examine the list
<mquandalle>
but I also need a way to be notified of the sharing graph
<mquandalle>
yep
<mquandalle>
if this is not a legacy thing of course :)
<kentonv>
I think it makes sense to have a (permanent) API for this
<kentonv>
though I can also imagine a fancier solution
<mquandalle>
what do you mean by permanent?
<kentonv>
which is to build a person-picker as a feature of Sandstorm
<kentonv>
and the app would invoke that for all these use cases
<kentonv>
that way the user doesn't have to share with them first as a separate action
<kentonv>
by "permanent" I mean not one of the hack APIs we have right now, but something we intend to keep around long-term
<mquandalle>
oh, ok
<mquandalle>
of course there is nothing urgent, I just wanted to share this use case
<kentonv>
yes, thanks... it's not something I'd thought of, but I agree we need to offer something here
<kentonv>
will there be a libreboard package update soon? :)
<mquandalle>
well the libreboard spk is now working
<mquandalle>
but the problem is the libreboard app itself
<mquandalle>
I've changed a lot of things (70% re-write since 0.8)
<mquandalle>
(I'm currently working full time on it, so it should go faster :-))
<mquandalle>
I'm not sure how I can test my modified shell
<mquandalle>
It seems that {stop|start}-fe are here for that purpose
<mquandalle>
Is hacking the shell documented somewhere?
<kentonv>
there's a script "shell/run-dev.sh" that works after you've done stop-fe
<mquandalle>
I think it didn't work, let me try again
<kentonv>
it may ask you to change permissions on your server but it should give you instructions on that
<mquandalle>
it works, I guess I just forgot to sudo
<mquandalle>
you could add a comment on top of this file saying that if you want to hack the shell you have to stop-fe and download the sandstorm dependencies listed in the readme
<mquandalle>
I'm not sure why, but I missed it before
<mquandalle>
do you have any news about pintask on sandstorm?
<jadewang>
they're not planning to go open source after all
<jadewang>
they're waiting for a later version of the app market
<mquandalle>
“they're” is that a team? I thought DenisGorbachev made it alone
<jadewang>
he also has a designer
<jadewang>
I think he has maybe another guy
<jadewang>
they're iterating on things trying to find product-market-fit and taking consulting jobs on the side to make ends meet
<jadewang>
last I heard, they moved to Thailand, which has a lower cost of living
<jadewang>
haven't heard from them in a while
<mquandalle>
oh really? I should contact them
<jadewang>
yeah, i can intro you
<jadewang>
i'll do that right now. :)
<mquandalle>
actually I think I already talked with denis (but not about pintask)
<jadewang>
ah, ok
<jadewang>
(should i not intro?)
<mquandalle>
it's ok thanks, I'll email him
<mquandalle>
kentonv: oh sorry I missed the “Hacking on the shell” of the readme
<kentonv>
blackrock is now happily distributing grains across multiple workers. Grain boot time from cold cache (brand-new worker machine with no prior knowledge about the app or grain) seems about the same as regular Sandstorm, i.e. a couple seconds.
<XgF>
:)
<kentonv>
which implies that Blackrock can move grains between machines fast enough that a user actively using the grain will perceive it as a slightly slow page load.
<XgF>
I'd love to try and convince IT to install Blackrock at work when its' available, though the fact that its' x86 specific may be problematic...
<kentonv>
what do you use for servers if not x86?
<XgF>
AArch64
<XgF>
(not for all, of course, but increasingly)
<kentonv>
may I ask where you work?
<XgF>
A certain CPU design company :-)
<kentonv>
haha, is this dogfooding?
<XgF>
yes
<kentonv>
is aarch64 little-endian?
<XgF>
Yes
<kentonv>
good
<XgF>
(It can be big too. But normally ARMs are little endian)
<XgF>
(Certainly I don't think its' something that would be seen as urgent, but having it on the roadmap...)
<kentonv>
well, I guess mainly we need to build good tools to support multi-arch packages
<kentonv>
and that's a big project
<kentonv>
which we can't afford currently. But if someone external wanted to work on it I wouldn't stop them. :)
<XgF>
Yeah, I guess it would need some sort of VM infrastructure or so
<XgF>
Though given some sort of package "overlay" infrastructure support it shouldn't be too difficult once there are packages for node.js, php, etc, if the actual app packages are arch-independent
<kentonv>
If x86 binaries and ARM binaries manage to match up 1:1, you might get away with letting developers do most of the dev cycle on their x86 desktop.
<kentonv>
and then they'd do an ARM build as a last step, and hopefully find that it "just works"
<kentonv>
I'm not sure how realistic that is in practice
<XgF>
Distros like to move files around and such and have arch specific quirks...
<XgF>
E.G. the glibc soversion doesn't match up across all architectures
<kentonv>
ugh
<Guest9988>
is the issue with kernel 4.0.4 fixed in update 83 ?
<Guest9988>
whoa
Guest9988 is now known as eldios
<kentonv>
eldios: there's no possible fix on Sandstorm's end. Sandboxing features are hosed in 4.0.4.
<XgF>
But certainly for apps written in scripting languages it should be feasible once the language runtime is packaged...
<eldios>
kentonv: did you ever hear back from them then?
<eldios>
any ETA or link so far?
<kentonv>
eldios: my understanding is that the correct patches have been marked for integration into stable. I don't know what the timeline is.
<kentonv>
4.0.5, whenever it lands, will have them, I guess?
<eldios>
I see
<eldios>
well let's hope that'll make it into CentOS7 stable updates soon then
<eldios>
it's a shame since we wanted to start toying with SandStorm realy quick at work, but we also wanted to test with SELinux on on CentOS
<kentonv>
eldios: IIRC your problem is with Linode, not CentOS
<kentonv>
Linode injects its own kernel
<eldios>
ah right
<eldios>
+1 steps towards the goal
<kentonv>
certainly CentOS stable wouldn't be using such a bleeding-edge kernel. :)
<kentonv>
I think Linode lets you choose other kernel versions, though?
<kentonv>
so maybe you can back up to a working version
<eldios>
it does
<eldios>
let me check that
<XgF>
eldios: Known good: Linux localhost 3.19.1-x86_64-linode53 #1 SMP Tue Mar 10 15:30:28 EDT 2015 x86_64 GNU/Linux
<eldios>
wow.. that's a lot of kernels ago :D
<kentonv>
XgF: On the previous topic: Sure, but ideally I'd like a solution that doesn't special-case each language, and doesn't discourage C++/Rust/Go users.
<eldios>
oh wait
<eldios>
I have a 4.0.1
<kentonv>
isn't 3.19 the version immediately before 4.0? :)
<XgF>
3.19 is at least the immediately preceding stable kernel
<eldios>
kentonv: that's two release before 4.0.1! it's ages in computorZ time!
<XgF>
Says someone running CentOS
<XgF>
:-)
<XgF>
kentonv: Sure, though I suspect C++/Rust users at least are a little more inclined to roll their sleeves up (and also there are probably maintainance/security benefits to having overlays for language runtimes and similar)
<eldios>
XgF that's so true.. but at least it's CentOS 7.
<eldios>
at least it's not a Debian. What's the latest stable there? 2.4.26? :>
<mcpherrin>
3.16 :p
<XgF>
A hell of a lot of EDA software is stuck in the world of RHEL6/5/4(!) :(
<mcpherrin>
I had to use RHEL3 recently :P
<XgF>
The curious thing about logging into a RHEL5 machine in 2015 is that it's like being transported back to the Linux that existed when I first seriously started using it in 2005...
<XgF>
I also had to check some software built on Solaris 8, that was really weird
<eldios>
anyway I'd never use on my servers what I prefer to use on my desktop
<eldios>
I only use ubuntu and centos on my servers.. but when I'm free to choose I always pick bleeding edge Arch or Gentoo
<eldios>
though those are a pain to maintain when dealing with "bizniz"®
<kentonv>
Arch refuses to support user namespaces (= no Sandstorm). :(
<mcpherrin>
XgF: heh, I used a SunOS 5 machine a few yars ago to run some ancient mathematics software
<eldios>
so it's best to stick with the more boring and reliable ones
<XgF>
mquandalle: SunOS 5 just means Solaris :-)
<eldios>
kentonv: really? that's weird. why so? They're usually pretty good into incorporating support for new/nice features
<mquandalle>
↑ mcpherrin?
<XgF>
yes
<mcpherrin>
XgF: yeah; I forget the exact SunOS -> Solaris name shift timeframe :P
<mcpherrin>
mm yes wikipedia says "uname" still report SunOS 5, which is how I would have figured out what was running
<kentonv>
eldios: because it has had lots of privilege escalation exploits. (Which we block inside Sandstorm, but if you have a multi-user system where you don't trust some users, then yeah, it's problematic.)