04:04 <mnutt> I went ahead and published the new davros version

04:06 <aerth> im stoked

04:06 <aerth> haha, all about fresh sandstorm apps

04:12 <JacobWeisz[m]> Probably should do some robust testing with the new version on experimental.

04:12 <JacobWeisz[m]> I owe some serious app testing time.

04:15 <aerth> i trying to make app where user can upload binary web server, run it with command line arguments and it serves using PORT and ADDR and reverse proxies to the usual appid****.host.sandcats.io , like a heroku of sorts. probably totally unsafe

04:17 <aerth> i use caddy server for reverse proxy, very easy to add something like https://mynewdomain.example { reverse_proxy * https://appid***.host.sandcats.io } to get full https benefits and host everything in the sand cloud

04:17 <JacobWeisz[m]> On one hand? Probably totally unsafe. Sandstorm is designed to assume apps may be hostile though, so if you actually get it to work, it may be kinda not totally unsafe.

04:18 <JacobWeisz[m]> By all means, let us know if you have questions or are wondering why something doesn't work or if there are roadblocks you come across.

04:18 <aerth> ive made a chat bot i can send youtube links and playlists and it youtube-dl's them and then a root cronjob to mv any new mp3s into my groove basin grain's sandbox/music dir

04:19 <aerth> auto dj on

04:19 <JacobWeisz[m]> That sounds unholy and I kinda like it.

04:20 <JacobWeisz[m]> I like that music is DRM-free now, and I don't mind buying it. But I find it sad music videos are still generally locked to YouTube from a legal sense.

04:20 <aerth> added to home screen chrome app on android, works great

04:20 <JacobWeisz[m]> I feel like being able to use the music video as visualizations alongside your music player is a thing that should just work and not be encumbered by DRM.

04:21 <aerth> using inspect element i could copy the curl command (with cookie headers) for the /stream.mp3 file. i'd like to publish that so that a listener doesnt need cookies (and can open in a music client) is that possible?

04:23 <aerth> or so i can forward that stream onto a icecast server

04:25 <aerth> a truly public link to a grain's asset or whatever

04:45 <mnutt> Back when we had an office we had a slack channel where you could drop youtube links and it'd queue them up to play, we had a client machine that sat on the slackbot's web UI as it used js to drive embedded youtube views and piped music through the kitchen. Funny enough by the end of the first day someone had queued up Darude - Sandstorm [10 hours] and on the second day I had to write "skip this track" controls

04:46 <mnutt> chatbots seem like a fun use of sandstorm, assuming the chat system uses webhooks

04:49 <isd> I should revive one of my IRC bouncer projects

04:50 <isd> ...because I don't have too many projects already, clearly

05:04 <JacobWeisz[m]> I still feel like we need a good nonadmin network access story before a lot of people would benefit from the IRC bouncers.

05:05 <aerth> very nice, chrome --app=https://local.sandcats.io

05:06 <aerth> its possible to route all app outgoing network through a socks proxy at this moment?

05:08 <isd> For the IRC bouncer's purpose, I think: we should be able to powerbox request a TcpPort, rather than all of IpNetwork, and I think it's probably fine for TcpPort to be non-admin

05:10 <JacobWeisz[m]> Yeah

05:11 <JacobWeisz[m]> I also feel that if there's a class of apps that can work by Powerboxing individual TcpPorts, we should not accept to the market ones that call IpNetwork instead.

05:11 <JacobWeisz[m]> Issue being, of course, TcpPort is not yet implemented.

05:12 <isd> Yeah. I think that's not a hard patch.

05:16 <isd> aerth: I don't think we have any good tooling for plumbing stuff through socks proxies

06:31 <aerth> got sandstorm postfix on 127.0.0.1 and another on 0.0.0.0 and want to relay the 0.0.0.0 unknown users to sandstorm users , possible?

06:32 <aerth> info@myhost.example -> shell user , <grainID>@myhost.example -> sandstorm postfix

06:33 <aerth> seems it can be done with 'luser_relay'

06:36 <aerth> https://stackoverflow.com/questions/23738705/postfix-relay-on-multiple-local-smtp-servers

06:37 <aerth> transport_maps

06:58 <aerth> it works

07:02 <aerth> (instead of smtp[localhost]:25 i put relay:[127.0.0.1]:9925 ) and in /etc/postfix/transport have full email address match for the few real system users, other mail gets forwarded to the sandstorm smtp server

08:48 <aerth> any app for contact form type email notification thing? i see sandforms but it seems like i have to login and check for that

08:48 <aerth> if i could cgi or php in hacker cms or something that would work too i guess

12:43 <JacobWeisz[m]> Ian, did you adjust your blog in some way this morning?

12:43 <JacobWeisz[m]> Something made me get over 100 old posts of yours marked unread in my feed reader.

12:44 <isd> ocdtrekkie: yeah, I noticed the links all had localhost:4000 in them so in a previous update I must have forgotten to jekyll build before pushing. So I fixed that, but since those links are also the IDs of the posts, it thinks they're all new posts.

12:45 <isd> I had a similar thing happen a month or two ago, but wasn't sure what had happened -- now I know.

12:45 <JacobWeisz[m]> Yeah, not the first time it's happened. ;)

12:46 <isd> I should probably set a cutoff on the number of feed entries.

12:46 <isd> If people want to read what I was writing in 2013 they can go to the website.

12:46 <JacobWeisz[m]> For an infrequently updated blog, ten is usually quite generous.

12:47 <isd> Yeah.

12:47 <JacobWeisz[m]> One thing I've discovered that actually irks me: Many sites that post more than ten times a day still use ten.

12:47 <JacobWeisz[m]> Which is why cron is so important for TTRSS. Checking once daily will leave big gaps in your feed collection.

12:48 <isd> I should blog more. I kinda toned it down in 2017 when iron blogger fell apart, partially because I felt like I'd been writing a lot of filler. But I haven't blogged in a year and a half now.

12:50 <isd> At some point I need to come up with a better name for https://github.com/zenhack/ocap-merkledag

12:51 <isd> It's inspired by perkeep, but I'd like not to be using a working name for 9 years like they did...

14:10 <TimMc> JacobWeisz[m]: There's a webcomic I read that posts in batches of about 25 once a month, and the feed is only 10 items long. -.-

14:10 <JacobWeisz[m]> Sad :(

14:11 <JacobWeisz[m]> An unfortunate victim of very few people considering RSS usability aspects today.

14:12 <JacobWeisz[m]> A lot of sites probably have RSS solely because the publishing platform they use included it by default, and default settings are what you get.

14:12 <TimMc> Of course, the author probably has no idea since they have little reason to subscribe to their own feed... so I should probably write and let them know. :-)

15:15 <isd> Yeah, complaining about a bug in some random unrelated IRC channel doesn't help get it fixed :P

15:28 <isd> The control flow for the CSP thing I'm working on is rather convoluted -- as is the case for anything where we want to trigger behavior on the client in response to something that happens server-side.

15:28 <abliss> remind me again, why is capnp in the browser so hard to achieve?

15:29 <isd> it isn't, just no-one has done it yet. It's on my TODO list.

15:29 <kentonv> isd, I've heard that https://github.com/fasterthanlime/capnp-ts/tree/rpc is basically working

15:29 <isd> Not really any harder than capnp anywhere else. But capnp rpc isn't totally trivial

15:31 <kentonv> I guess this link also has something to do with it: https://github.com/fasterthanlime/capnproto-test/tree/master/ts/src

15:31 <isd> kentonv: ah, didn't know that existed; my last memory of the state was that Julian's implementation had working serialization but no one was working on more than that.

15:32 <kentonv> yeah Amos took Julian's code and added some RPC support

15:32 <isd> I will have to play with it.

15:32 <kentonv> though he says one big problem is it currently requires GC hooking which is only available in node/electron

15:32 <kentonv> IMO capability dropping should not be based on GC finalization anyway, probably just need to add some explicit .close() methods or something

15:33 <isd> Hm, FinalizationRegistry seems to exist in both firefox and chromium on my machine.

15:33 <isd> Maybe that's relatively recent

15:34 <kentonv> oh yeah, that browser feature is newer than this code

15:34 <kentonv> the browser feature arrived just this year. I know because... we have to disable it in Workers, because it is a potential source of non-determinism and therefore side channels

15:35 <isd> But yeah, we have enough APIs where stuff is triggered by dropping caps, so we should have some way of explicitly dropping them, rather than waiting on GC.

16:30 <simpson> abliss: Another point is that the browser's language ecosystem doesn't give us a nice family of types to work with. Integers and bytestrings are both infamous obstacles. This isn't to say that it's impossible, but to say that e.g. it's *currently* impossible in Elm.

16:46 <isd> eh, you can emulate the integer types that aren't there. it'll be a bit slower, but fine for our purposes. Certainly faster than what we're doing now.

16:47 <isd> Also, that work has been done for some time; there's an existing ts/js implementation that's serialization-only. But we want RPC.

16:49 <isd> Fwiw, the ocaml implementation almost works in the browser: https://github.com/capnproto/capnp-ocaml/issues/76

16:50 <isd> Granted, the missing integer types are the only thing missing. But, it's not a huge roadblock so much as a small extra thing.