Aaron Parecki

Nice, I think that'd be great! There are some interesting implications around doing this in a distributed environment where I am not in control of the player, as opposed to Instagram who is in control of the source of the data as well as the player. For example when I publish something to my story, my intent is for it to be visible for 24 hours, but there isn't really anything stopping someone from downloading a copy and keeping it. Is that okay? Maybe? I also kind of think I'd prefer that my story content is only visible to people I know, so I want to tie it to whatever system we end up with for authenticated feed fetching. Ultimately though all we're really talking about is sharing a photo or video with some expiration date so it should be doable!

I'm still trying to understand the appeal of stories, but I do post my own stories on my website! When there is one available, there's a glowing ring around the profile photo on my home page! :-)

OwnTracks is probably the best option for that, but I haven't actually set up the server myself before.

I link to my Atom feed from my home page, but all of my feeds are also available as Atom by adding .atom to the URL. I don't have h-feed markup because I haven't gotten around to it and things seem to be doing okay looking at just the list of h-entrys on the page.

I wish sorting were the problem, but i already know there are a few dozen high priority things I need to respond to 😖

This is really interesting. I'm generally wary of adding encryption into a protocol at this level, instead, preferring it at the transport layer for example by providing an HTTP Authorization header. But you've made some interesting arguments about being able to reuse the existing WebSub mechanisms that are worth exploring more.

I think my main concern, which you sort of hinted at, is that the feed will essentially leak info about how many followers someone has, as well as this potentially including a _lot_ of data as someone's followers grow to the hundreds.

Have you seen the work going on around making IndieAuth work in a server-to-server environment without user interaction? The idea with that is to let a feed reader fetch a private feed on behalf of a user. https://indieweb.org/AutoAuth

Nowhere near as many as some people I know, but I realized I didn't have a list of all of them so I started compiling one! It's still rough but it's a start: https://aaronparecki.com/conferences/ Thanks for the nudge!

Sorry it's not super obvious. Go into a channel in Aperture, then click "New Source" and you can enter a URL to subscribe to.

yesssss it is still my main bike! The only times I don't ride it are when I have to haul 60 pounds of boxes and I use my cargo bike instead.

omg yesss! HWC re:invent!

Viewsonic actually! One of the last non-smart TVs, so I'm glad it isn't actually broken!

on the train

I did it. I found a TV and survived the crowds and carried the TV back to the MAX station.

Shoulda brought my cargo bike. That's a long way to carry a TV box if this works

sometimes people say nice things about you on twitter too

That does look nice! I hadn't heard of it before. I just downloaded it and went through the tutorial, not bad! I'll try to use it for my next project.

On Wed, Nov 7, 2018 at 7:20 AM Joseph Heenan <joseph at authlete.com> wrote:

> It may be worth slightly rewording 7.2 as it may encourage a growing misconception that all native apps must be public clients. With many devices now having embedded HSMs, we’ve seen increasing interest in mobile apps being dynamically (per-install) registered oauth2 private clients, and that model has a lot of advantages. (I’m not sure if we might see a similar model evolving for web apps.)

That's a great point, thanks. I've removed the reference to native apps being public clients since it doesn't really add anything to this spec if I have to caveat the description.

On Thu, Nov 15, 2018 at 12:58 PM Torsten Lodderstedt <torsten at lodderstedt.net> wrote:

> > > First of all the AS decides whether it issues refresh tokens or not. Having the ability does not mean the AS must do it. If you feel it’s safer to not do it. Fine.
> > Sure, and this should be mentioned then somewhere (either in the threats doc or in this proposed best practice doc). Not all end developers using these protocols fully understand the ramifications.
> @Aaron: I suggest this goes to the SPA BCP since this is client specific.

Thanks, I agree that this document should include some recommendations around refresh token handling. Looking at the discussion in this thread, it seems there are a few different strategies folks are taking. Since it seems like there isn't a strong consensus, it sounds like this would be better suited for the "Security Considerations" section, and to not make MUST/SHOULD recommendations, but rather just point out the issues. Any thoughts on that before I take a stab at writing something?

I've incorporated some of the other feedback here and published an updated version:

https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-01

Thanks for the feedback so far.

yesss i want to know how this goes

Pulling out of the gate to the runway front first and taking off with no wait feels way more like riding in a car that can fly than an airplane

looked up MIDI versions of as many Beatles songs as I could find