<zarvox>
so to join a node to the network, you just have to introduce it to one other node, and have one other node know about it so it can push to your new node
<awans>
right
<zarvox>
which I guess is two copy-pastes of URLs
<awans>
should be just one -- there's a bootstrap node hardcoded into the app
<awans>
so you just have to announce yourself to the bootstrap node
<awans>
and then you'll get happily integrated
<zarvox>
ahhh, so just one copy paste to yourself, and once we lock down the HTTP hack get, one powerbox interaction to publish that to the bootstrap node, and if your hardcoded bootstrap node ever goes away, or people want to run a disjoint network, sad users?
<awans>
haha TODO(awans)
<awans>
just wanna get it working at all first :)
<zarvox>
Heh, fair. :)
<awans>
from a UX perspective, I'd ideally like some sort of permission-grant sys UI.. it's hard to imagine much else really making sense
<zarvox>
The Sandstorm platform is a bit forceful about the "make apps work regardless of what happens elsewhere" thing
<zarvox>
ideally this would be something that can be mediated through the powerbox
<awans>
right, that sgtm
<awans>
bonus points if it can give me HTTP POSTs as well as GETs :p
<zarvox>
so a user can provide their favorite social bookmarking bootstrap node to their grain
<zarvox>
(with an option for the grain to suggest a default one?)
<awans>
right.. if i really wanted the app to like properly support multiple networks, there'd be a bit more work as well to prevent them from "accidentally" merging
<awans>
but i'd like to have app-level settings for overriding the nodes that your node chats with
<awans>
(i don't think sandstorm-level settings are really going to make sense)
<zarvox>
but if nodes will happily talk to anyone, then it doesn't matter what you let your node talk to, so long as those nodes talk to everyone else still, the network is still connected
<zarvox>
and if the design is signed messages, then you don't really care where the messages come from; you trust some keys and not others, right?
<awans>
that's right
<awans>
which is why i say multiple networks isn't really supported
<zarvox>
*nod*
<zarvox>
I guess I'm missing what benefit being able to pick which nodes your node will talk to
<zarvox>
I guess I'm missing what benefit being able to pick which nodes your node will talk to is meant to provide
sh_smith has quit [Remote host closed the connection]
<zarvox>
or more precisely, what being able to disallow your node from talking to any particular node is meant to accomplish
<zarvox>
(be back in a bit, dinner at the office)
<awans>
the only benefit i can see is if the bootstrap node dies, it'd be good if people could override it
<awans>
so people can like resurrect the network at some point down the line
aldeka_limechat has joined #sandstorm
<zarvox>
ahhh, so more of a "connect somewhere else" not a "disconnect from this previously-made connection"
<awans>
right
<zarvox>
my vision would be that your app makes a powerbox request to speak HTTP to some host/port, with a default value of (the bootstrap node's origin), and then the user grants that request, or picks their own URL and grants the request, and your app gets a capability that it can make calls on
<zarvox>
I guess maybe the app needs to also be able to send that server a capability at which to receive replies?
<awans>
well, i'd like the user's node to connect to many other servers
<awans>
vs just the bootstrap server
<awans>
ie.. it should say, "Hi bootstrap, I'm awans.org/cool-server"
<awans>
bootstrap says "Hey awans.org/cool-server, here's some bookmarks <splat>, here's some other nodes you might talk to"
<zarvox>
ahhh, introductions!
<awans>
and then awans.org starts gossipping with those other nodes..
<awans>
another thing is... while i'm targeting sandstorm, i'm currently running the server outside of sandstorm
<awans>
and i'd like to keep it possible for people to run the service without sandstorm and connect to the network
<awans>
(which means i'm not always gonna be able to pass around capabilities, i think)
<zarvox>
Awww, why not?
<awans>
haha because writing HTTP APIs is a lot easier than cap'n'p APIs?
<awans>
but maybe i'm missing something..
<zarvox>
Heh, well, there's certainly a lot more tooling around HTTP APIs :)
<awans>
right, and better bindings ;)
<awans>
(yeah, tooling)
<zarvox>
I believe kentonv has a vision for making an HTTP transport for capnp rpc
<awans>
haha i also have more confidence about HTTP sticking around than capnp
<awans>
..and i truly mean no offense by that!
wolcen has joined #sandstorm
<kentonv>
I dunno, I find capnp APIs a lot easier and cleaner. :P
<kentonv>
but yeah I plan to develop a JSON/HTTP<->capnp bridge
<awans>
so, in the long run, i'd like my app to get granted via sys-UI an arbitrary get capability and an endpoint URL where other nodes can talk to it
<awans>
but that sys-UI doesn't exist, and offer templates are awkward / more work for me and users than hack-session
<awans>
so do i have any shot at convincing y'all to bring back generateApiToken?
<awans>
until i can get it via powerbox?
<awans>
(if not, i'll implement offer templates i guess, it'll just be janky)
<kentonv>
sorry, that method broke our security model
<awans>
fair enough. lemme know if you guys have any brilliant ideas to avoid the textbox copy paste, or at least make it less awkward!
aldeka_limechat has quit [Remote host closed the connection]
<kentonv>
"something something imbued text"
<kentonv>
(idea that you can ask Sandstorm to substitute capability tokens into outgoing request text)
<kentonv>
(not a well-formed idea currently, though)
<kentonv>
the problem is that we want an app to be able to share capabilities to itself without having the ability to obtain a token to itself, because a token is just bits and can be leaked via covert channels
<kentonv>
everything is fine when the app communicates on capnp interfaces that are capability-aware
<kentonv>
awans wants his app to send a request to an external HTTP server and wants the request contain a token that can be used to call back to the source grain
<eternaleye>
Can allow instantiating an FST, where the input language is strings, the output language has a slot that's late-bound to a cap, and the FST is executed over the message
<kentonv>
if the grain could send an HTTP request and say "dear Sandstorm, please generate a new token and insert it into this request at this position", then it can share a token without being able to self-generate a token
<eternaleye>
Lexers are probably the most commonly seen example of finite state transducers.
<awans>
kentonv: FWIW, in the gossip protocol, it's gonna get its capability back eventually from other servers anyway
<kentonv>
awans: that's fine, if the remote side wants to share the bits back, it can do so
<eternaleye>
So effectively, someone would write a lexer, and then say "this token gets replaced with a cap"
<kentonv>
as long as the grain needs external help to get a token to itself
<kentonv>
and if I connect the grain to a service that I trust to enforce confinement then I can feel secure that my grain is still confined
<awans>
i see; that makes sense
<kentonv>
whereas if a grain can arbitrarily create a token to itself then confinement is effectively impossible
<kentonv>
I mean, alternatively, we could have a way for a grain to simply request permission to break confinement, and then it gets a capability to create tokens to itself. But the nice thing about using "imbued text" is that we can trace exactly which outgoing request caused any particular token to be minted, and can audit/revoke them
<awans>
right.. i guess.. are you guys interested in supporting grains that don't want to be confined? like distributed apps :p
<kentonv>
of course, with the user's permission
<awans>
right, yeah, in this app's case (and in any gossip network), audit/revocation isn't going to be very meaningful
<awans>
because the cap is gonna get spread as widely as possible
<awans>
it's sort of best if the app has exactly one cap representing "let everybody talk to you" that gets revoked wholistically
<kentonv>
that may be, but I want to be cautious about giving apps a total escape hatch because it would be sad if developers tended to use that hatch in cases where something more disciplined could have worked
<kentonv>
I think the imbued text thing should work.
<awans>
so long as the app can have the same cap injected each time, i agree :)
mnutt_ has joined #sandstorm
<awans>
otherwise it's gonna spawn oodles of needless caps
<kentonv>
by "same cap" do you mean "same target object" or "same token bits"?
<awans>
i'm not sure i understand the distinction, but probably "same target object"
sh_smith has joined #sandstorm
<kentonv>
actually it sounds like you mean "same token bits" -- if you don't want a database entry being added each time
<awans>
yeah, the server likes to announce itself whenever it has new stuff to offer the network
<awans>
so that can happen sorta arbitrarily often
<awans>
if it's cheap, then /shrug
<awans>
but if not, then it'd be good to re-use
<kentonv>
we can probably do a de-dup thing.
<awans>
(i'm pretty out of my depth here..)
<kentonv>
nice... if I accidentally call setState() inside a react render() method then it crashes the browser tab