00:07 <simonv3> kentonv: yeah, I get where you’re coming from. Here’s the use case: I’m doing some touching up on Quick-Survey to get it ready for packaging, and one of the uses of it is that people shouldn’t be able to re-submit a survey if they have in the past. The way to do this (naively) is to store something in the session or local storage. At least this would

00:07 <simonv3> prevent the “page refresh and it’s available again"

00:13 <kentonv> mnutt: Sandstorm's makefile bootstraps a minimal Ekam build so that people don't have to separately install Ekam first. However the bootstrap script doesn't know how to build Ekam with networking -- that requires Cap'n Proto and at that point you need to use Ekam to build Ekam.

00:13 <mnutt> ah, ok. that makes sense

00:14 <kentonv> some day I'd like Ekam to be able to output makefiles.

00:14 <wolftune> Snowdrift.coop is playing with sandstorm… complaint expressed at #snowdrift earlier:

00:15 <wolftune> "Sandstorm does not have an intuitive way (or any way at all? I can't find it) to see previously-shared links"

00:15 <wolftune> "There is a list of "sharing links" that only lists the label. You can change the label! But you can't see what the link text is"

00:15 <simonv3> ^ Oh yeah, I’ve wondered about that too

00:16 <dwrensha> the links are not stored on the server! only a hash is.

00:16 <kentonv> wolftune: In fact, Sandstorm is incapable of reproducing the link after the fact. We only store the hash in the database. That way, someone who manages to get passive read access to the database cannot forge tokens.

00:16 <kentonv> however, we plan to add a trick to the UI where you can generate a new link that claims to be the same link, since a lot of people ask for that

00:17 <kentonv> (so it won't create a new row in the table; it will behave as if it were the same link, but the key will actually be different)

00:20 <wolftune> hmm okay

00:21 <simonv3> will people with the old link still be able to use that link?

00:21 <kentonv> simonv3: yes

00:22 <simonv3> oh right, cause the hash is still stored and points to the right place

00:24 <wolftune> kentonv: so, am I to understand there's no way to have the same sort of situation as with just etherpad running on its own? i.e. where a public link can be posted and anyone who sees it can read the pad…

00:24 <kentonv> simonv3: regarding anonymous users, not sure what to say. We've thought about storing a tracking token in the Sandstorm shell's local storage mostly for the purpose of counting how many unique users have accessed a sharing link (helps detect if it was leaked widely). We could maybe generate a one-off user ID from that to report to the app but we'll have to think carefully about privacy implications.

00:24 <kentonv> wolftune: you can do that with a sharing link

00:25 <wolftune> kentonv: but if you send it to someone, and forget to copy it, there's no way to retrieve the same link again without asking that person if they still have it?

00:26 <simonv3> kentonv: yeah, it’s not critical. I doubt most people would refresh the page anyway (that might be a web developer ingrained thing), and it would still work for people who use Sandstorm internally. Thanks for the thoughts!

00:27 <kentonv> wolftune: you can always create another link. It may look ugly filling up the table but there's not much actual harm.

00:28 <kentonv> simonv3: feel free to file a feature request for reference

00:29 <simonv3> kentonv: would that just be on https://github.com/sandstorm-io/sandstorm/issues ?

00:29 <wolftune> kentonv: would it be feasible to have a function for a visible link totally open to the public to read that would use maybe a shorter URL (maybe custom even) and then *do* store that in the DB?

00:29 <kentonv> simonv3: yes

00:30 <kentonv> wolftune: yeah, we'd like to add something like that

00:33 <kentonv> wolftune: for the time being, one way to accomplish that is to feed the sharing link into your favorite URL shortener. Eventually I'd like Sandstorm to have a built-in feature for that, but I'm not sure when we'll get to it. Patches are welcome if you'd like to try implementing it. :)

00:36 <wolftune> kentonv: okay thanks for the perspective

00:39 <kentonv> wolftune: np, let me know if you have any other feedback

00:44 <wolftune> sure, thanks

01:23 <shachaf> hi wolftune

01:24 <wolftune> shachaf: howdy

01:29 <wolftune> I'm off folks, thanks though, may be back here at times, I can commonly be found over at #snowdrift

01:29 <wolftune> shachaf: ciao

16:51 <ocdtrekkie_> XgF: I couldn't find a superb reason to not use VB. The sample code I built off of was VB, and I've probably skipped out on a lot of debugging because I understand it fairly well. It saved me time. And hey, alledgedly, it'll run on Linux now?

22:05 <maurer> dwrensha: btw, is there a way to listen on two different channels in gj?

22:06 <dwrensha> define "channel"

22:06 <maurer> I've got my tcp socket, where I want to service capnp requests

22:07 <maurer> I also need a command channel (currently mpsc, but I could change it to be something else) so that I can instruct the thread to exit the event loop and kill itself

22:08 <dwrensha> yeah, there's currently no interop with std::mpsc

22:08 <maurer> Previously, I was checking the command channel for commands, then blocking on an accept on the tcp socket, and just making sure to accompany all commands with a dummy connection

22:08 <maurer> doesn't need to be mpsc, I can use any kind of channel

22:08 <maurer> in an ideal world though, I'd basically get to do the equivalent of select/epoll over the tcp socket and some command channel I can send stuff to from my main thread

22:10 <maurer> In any case, I'll probably just keep using a dummy connection to cycle the loop for now, but it'd be cool if gj allowed something like this, and I'm not really seeing it

22:10 <dwrensha> I would construct the command channel as a cap'n proto connection over a unix socket

22:11 <dwrensha> I think GJ should have such a thing

22:11 <dwrensha> channels for cross-thread communication

22:11 <maurer> dwrensha: That seems super overkill for what this is, the only commands are Shutdown and Pause

22:11 <maurer> I'll just use dummy connections for now, and maybe I'll convert it to a capnproto object if I have copious free time some day

22:17 <zarvox> hi asheesh!

22:20 <asheesh> I was going to just write a short 3-sentence blurb about the new site but I ended up with https://oasis.sandstorm.io/shared/_lRQgZT15Vjg418Br25PS4ZWDwaRY6gIK9Eywfik0GS

22:24 <maurer> dwrensha: Actually, just to verify, even if I did make it a capnproto object on a unix domain socket, I think I'd still be stuck with the same problem

22:25 <dwrensha> maurer: heh, or you could have a unix socket with a simple single-byte protocol. If you receive the byte 1, then shut down. if you receive the byte 2 then pause

22:25 <dwrensha> what's the problem?

22:25 <maurer> dwrensha: namely, I can't .accept() on the tcp stream and the unix socket simultaneously

22:25 <dwrensha> accept() returns a promise

22:25 <dwrensha> so make two such promises

22:26 <dwrensha> and collect them with Promise::all()?

22:26 <maurer> Hm, yeah, that could work

22:26 <maurer> sorry

22:26 <maurer> misread the api

22:28 <maurer> dwrensha: Also, I suspect you don't mean all(), but rather exclusive_join(), since all() would cause it to wait until it received a command _and_ a new service connection

22:29 <dwrensha> oh, maybe I didn't follow exactly what you're trying to accomplish

22:31 <maurer> dwrensha: I want to spin up a thread which has an event loop exposing a capnproto object on a tcp socket.

22:32 <maurer> dwrensha: then, I want to from elsewhere in the application be able to tell that thread that its job is done, and it should clean up and quit

22:32 <maurer> (this interface got created for testing basically - the test thread spins up separate client and server threads which talk to each other)

22:33 <maurer> (then if the client gets back the right answers, the testing thread tells them both to die, and exits success

22:33 <maurer> So, I need some way to cause what is normally an infinite loop to exit. To this end I created a command channel to the thread

22:34 <maurer> which it checks after every new connection

22:35 <dwrensha> OK. Yeah, GJ really could benefit from some kind of cross-thread notifications

22:35 <maurer> Yeah, I'm just going to hack it together with mpsc + a dummy connection for my use case, but I think that adding a thread-thread channel with promise based receipt would be a good addition. I guess I'll just throw up an issue and you can tag it feature request

22:36 <dwrensha> maurer: a feature-request github issue would be nice

22:46 <maurer> ttps://github.com/dwrensha/gj/issues/4

22:46 <dwrensha> thanks