00:31 <isd> No, but that's not a blocker as it wouldn't be a regression. Though I plan on it.

00:34 <isd> Good news is that it doesn't seem to be prohibitively annoying to do a separate request per URL (as opposed to per host).

01:52 <isd> https works. Still hunting down a bug where it doesn't actually pull stuff in on the first go; you have to do debug feed -> force refresh

01:59 <JacobWeisz[m]> I'm confused about per url vs. per host...

01:59 <JacobWeisz[m]> Is it asking about each individual article?

02:00 <isd> ocdtrekkie: It's asking for each distinct URL ttrss tries to fetch.

02:02 <isd> But it does not appear that ttrss actually tries to fetch the upstream articles, at least from the web UI; the short version is included in the feed which is one request, and if you click to open the article it pops out in a new window and just has you visit the article directly.

02:03 <isd> ...so it only actually needs to make one request once it's worked out the feed URL.

02:07 <JacobWeisz[m]> I am curious how well that will work when you try a feed like Kotaku which embeds images.

02:08 <isd> Have a few images in the feed I tried. It looks like the server doesn't actually download them, the web UI just links to them direction in the page it renders

02:08 <JacobWeisz[m]> Ah, so the client side loophole.

02:08 <isd> yep.

02:08 <JacobWeisz[m]> Fine for now, I guess then.

02:08 <isd> Yeah.

02:10 <isd> I wonder if we can detect missing images via CSP's reporting mechanism, and then display a banner "images have been blocked for your privacy. [load images]" like you see in email clients that support HTML...

02:10 <isd> (The [load images] button would cause the page to refersh with a loosened CSP)

02:11 <isd> As far as I can tell there's no way for a server to tell the browser to block webrtc though.

02:11 <isd> I'm not sure the kind of isolation we were going for is actually even possible with modern browsers as they stand...

02:13 <JacobWeisz[m]> Can we like block client-side loading and then have the server load them through the Powerbox and serve them? Without requiring an app be rewritten from scratch?

02:14 <JacobWeisz[m]> I mean, otherwise we just detect Chrome and warn people that they should switch a browser with tracking protection. Which is literally every browser not made by an ad company.

02:15 <JacobWeisz[m]> Like, the stuff I used to have to depend on Privacy Badger for is mostly now just... standard behavior for browsers by responsible developers.

02:16 <isd> If we have the server load them we somehow have to rewrite the client-side html to point to the right URLs.

02:16 <isd> I think the CSP solution I outlined is more promising in terms of compatibility.

02:17 <JacobWeisz[m]> Seems reasonable.

16:44 <TimMc> I love the idea of CSP reporting looping back and causing a UI update.

19:58 <isd> So, realization: TTRSS ships with a couple "example feeds" already subscribed to. This means it's going to need to prompt for access to those immediately on first run, which is kinda annoying.

19:58 <isd> It is not doing this now, presumably because of the bug I mentioned above, but once I fix that it will become a problem.

20:12 <TimMc> What if that were changed to a first-time onboarding experience that could be skipped?

20:14 <TimMc> "Would you like a demo? [Add an example feed] [Skip]"

20:14 <TimMc> (I'd *love* a way to say "I know this app and don't need sample content" especially for things like Davros.)

20:17 <isd> I wonder if ttrss has a config option for this.

20:18 <isd> That sounds like a reasonable flow, but also a lot more work.

20:18 <isd> I half considered writing my own RSS reader; you could do much better on Sandstorm integration than ttrss currently allows. But I have way too many projects already

20:19 <isd> ...A sandstorm-first reader could just use the powerbox as the prompt for the feed URL in the first place, so you wouldn't need an "extra" permssion prompt.

20:20 <isd> The current experience is janky in a lot of ways, but I only want to write so much php.

21:51 <JacobWeisz[m]> I am still sad we have sample script in Etherpad, but I think the discussion was that it was the preferred way to distribute the app. Even though it's kinda annoying as a regular user.

21:52 <JacobWeisz[m]> But yeah, my personal preference is not to add example anything by default on a new grain, unless we add some sort of API to determine that it is a user's first grain with that app or something.

22:32 <abliss_> for my part, I finally managed to get a working (?) spk built, so it's read yfor testing (attn JacobWeisz[m] ): https://github.com/abliss/Tiny-Tiny-RSS/releases/download/sandstorm-1.13.0/ttrss.spk

22:32 <abliss_> This is a merge of upstream/master into jason's port, with none of ian's fancy new stuff

22:56 <abliss_> Shoot. this spk doesn't work correctly to upgrade an old DB. So you can only test with new grains for now.

23:03 <abliss_> ok, got a fix, uploading the next RC

23:34 <JacobWeisz[m]> Cool, let me know when it's ready! Though I am guessing with Ian's work sounding like it's close to ready, hopefully we can focus on the modern version soon.

23:35 <JacobWeisz[m]> (I am both really excited about a TTRSS update and the idea of having a good example best practice app for using the Powerbox with an app that needs arbitrary-ish domains.)