Jamey Sharp @jamey@toot.cat

@nightpool @jalcine Ah, maybe I never got to that sentence since the rest of the pile of specifications was overwhelming… 😅

To be honest, I wish we were just using WebSub and WebMention, like the IndieWeb folks advocate, but with Atom, which puts me at odds with both major camps 🤷

@nightpool @jalcine That sounds like an argument in favor of "LitePub", ActivityPub without any of the JSON-LD references, if there are already two implementations where that aspect doesn't matter.

Making it part of the spec means implementors have to discover for themselves that they don't have to do it to interoperate, which is all kinds of badness in terms of barriers to adoption.

@joeyh I was gonna say, that is a fantastic typo.

@zwol @noemi I did not know about that, so apparently I need to have a chat with Leonard sometime. 😁

I think it's exactly the right model, where the actual recommendations are computed locally at the user's request. But I also think it's complementary to what I'm trying to do, which is to give people a safe way to publish aggregate statistical data about "people who like this also like that", which would be useful input to something like Ultra Gleeper.

@joachim Oh, neat. Now I have questions about Cast Rewinder. 1) Is the idea to trickle just a few episodes per week to your podcast client, like https://archivebinge.net does for webcomics? 2) Do you rely on the upstream podcast feeds having all the episodes in one feed document, or do you have some magic for finding older episodes? (Lately I've been advocating for publishers to adopt RFC5005, "Feed Paging and Archiving", to solve the latter issue.)

@noemi I've been researching approaches to privacy-preserving distributed recommendations, but I haven't got the math quite right yet. I'm pretty sure it's possible to get the benefits of "algorithms" for content recommendations without actually sharing anyone's private data with anyone else though. As a first step, I wrote up some of the related research recently: https://jamey.thesharps.us/2018/07/10/private-secure-multiparty-histograms/

@garbados Browser security is full of half-measures too. For example, people realized that iframes plus CSS enabled click-jacking attacks. So rather than preventing input events from passing through a CSS box into an iframe it occludes, they decided that servers should be able to declare, "please don't put me in an iframe", which became default advice in frameworks like Django. Then browsers implemented this with no visual indication of why your iframe isn't rendering. 😤

@aaronpk Hey Aaron, I've been thinking about WebSub for intermittently-connected clients, and here's a thought I want to run by you:

A hub could allow stateless WebSocket connections, and treat them as subscriptions that last for exactly as long as the connection stays open. Ideally you'd multiplex all subscriptions at a hub onto the same socket, I think.

Do you think that would be a useful/desirable extension to WebSub?

@gcupc @djsundog Yeah, when the client participates voluntarily I think that's ethically just fine. Which is why I'd like a standard way for the client to signal that they're expecting the proxy to terminate the TLS connection, rather than trying to do it transparently… sigh.

I also had trouble configuring Squid for the caching policy I wanted, last time I tried to do this. But for old-browser purposes it's probably fine?

@alex @charlag You might not even need tools, at least to get a little extra time until you can get the brakes replaced. This looks like a good guide for the kind of adjustment I've done occasionally: http://www.holliseaster.com/p/adjust-bike-brakes/

@gcupc @djsundog Thanks for the pointer! You're referring specifically to the SslBump configuration? Ugh, I'd feel a lot better if the client was expecting the proxy to be in the middle, rather than getting a random untrusted server certificate as the only clue.

I think this was actually possible with HTTP/1.0 proxies, because the protocol was you send the entire URL, including scheme, in the request line. I feel like HTTP/1.1 is worse in this one way.

@gcupc @djsundog Is there any standard way to set up a proxy that terminates TLS? As far as I can tell, asking any HTTP client today to use a proxy for HTTPS means the client uses CONNECT mode so the proxy has to just forward the raw TLS byte stream. Which seems like a good idea generally, but I actually really want to be able to have a private caching proxy that can cache HTTPS requests too…