Year: 2021

Map
My biggest problem in wanting to share trips is timing. I enjoy taking pictures on trips, but I don’t want to spend time while on the trip going through the steps of choosing what to upload and uploading them. But when I upload later, the time and location data isn’t aligned unless I do so automatically.

So, what I’d like is the ability to select from the photos and decide which ones to upload, and have my site take care of posting them, rather than a one-by-one flow. I can probably build a basic version of that into my site, but I’d prefer a mobile app(of course, I won’t be creating one).

IndieAuth Popup 2 2021

In October, we had a second IndieAuth popup session to finish off what we didn’t in the first one.

Some of the items from the first popup remain unmerged due some questions, but a lot are affected by the now merged Metadata Endpoint.

The idea is this…instead of having multiple values in the header, you have one value, rel=”indieauth-metadata”. This, URL, when retrieved, provides a full JSON configuration for all the IndieAuth endpoints. The old headers will have to stay for a bit for backward compatibility, but eventually can go away.

This changes the idea for the introspection endpoint, which no longer needs to overload the token endpoint. The same can be said for the revokation endpoint, which is an overload of the token endpoint. So both of these can have their own endpoint. This would in the future deprecate the existing methods of doing this(such as action=revoke).

The OAuth2 Server metadata spec, which we adopted with minor modifications, has fields for all of these, so we can simplify the IndieAuth standard and make it more OAuth2 compatible.

The idea of moving closer to OAuth2 means existing OAuth2 clients can be modified with a minimum of issue to work with IndieAuth.

The as yet unsolved problem for me is that the revocation and introspection specs we’re adopting are rather similar…both use POST actions, with the parameter token. However, they both require authentication. It was decided that how this works would not be specified at this time.

So, this makes it a bit hard for my implementation, as I haven’t decided what out of band method I’ll use. I may leave it unauthenticated for now with a warning.

The final addition is the pending proposal for a User Information endpoint, to also be added to metadata. This would have the same return as the profile property during the flow, and allow any token that had the profile or email scope to refresh its profile data without having to go through the flow again.

 

Just used a $25 travel router flashed with OpenWRT to create a permanent Wireguard gateway from my grandparent’s old apartment to my apartment so I can access my server. Usually I use site-to-site between routers, but their building contract doesn’t allow for using your own router.