Watching the New York Gilbert and Sullivan Players live stream of HMS Pinafore.
Been hanging around my grandparent’s apartment, where I’m visiting, setting up the infrastructure I had to move out of my parent’s apartment due renovation. Added some new tricks. Running a wireguard gateway off a travel router, and pumping my DVR back at home through it so I can watch TV. Relocated the weather station, offline since May as well, need to get the sensors back online as well.
Nothing like a midnight flight…
Going through my list of itineraries over the last decade to add limited records of where I’ve been to my site. I think I also have paper tickets and old boarding passes as well somewhere I can merge in. Right now, these are just simple posts with the location and the time keyed to the departure time of the flight.
I don’t know. I get lost in a lot of those specs. I made a point to say it wasn’t bad
Send webmention, make POST request with parameters source and target. Receive webmention, verify source links to target and decide how to display. Specs often make things sound more technical than they are.
Well, the IndieWeb folks and the standards folks like more complex solutions (not saying they are bad) to a lot of the simple things that were working then and you lose some of the charm https://indieweb.org/Webmention
How is webmention more complicated vs trackback? It just adds verification? Trackback lacked any spam control.
IndieAuth for WordPress 4.2.0 Released
Decided to dive into the unknown with the IndieAuth spec. The WordPress plugin now supports the latest in the standard, some of which has been merged, and some of which is pending merge. This will be visible if you visit the spec repo, but has not been deployed to the spec page yet.
The first change is the introduction of the metadata endpoint. This means that instead of a Link header for every endpoint, there is one endpoint that has parameters for all the other endpoints. This means even if an extension like Ticket Auth(which requires another endpoint) is optional, it won’t require another header.
This is something we have in Micropub, where the media endpoint does not have its own link header(although there is a proposal to change that). But it does mean you have to make two requests(caching aside) instead of one in discovery.
The metadata endpoint also provides some configuration information on what the endpoints support, such as which scopes, which can be useful.
The introspection endpoint, introduced in 4.1.0, as a result, is no longer sharing a URL with the token endpoint. The side effect of needing to implement proof of concept….as the introspection proposal has yet to be merged. Until it is, it is considered experimental.
The new revocation endpoint allows this feature to be separated from the token endpoint as well. The old method still works for the foreseeable future.
The final endpoint added, the userinfo endpoint, is just a way of getting a refreshed version of the profile info returned when you make the initial request. This also being experimental till merged.
All of this, as well as some minor tweaks and optimizations, works, and is fully backward compatible. At some point in the future, when adoption changes, will be looking to deprecate older methods.
All of this is a step along the way of making IndieAuth not so much a separate protocol, but what it is described as….an identity layer on top of OAuth 2.0(or increasingly on top of the proposed OAuth 2.1), with the changes meaning less custom code.
Trying to prevent humidifier lung. Didn’t realize that I might be causing problems by not cleaning my humidifier often enough.
I made my way to Rovaniemi too.
Making friends
Happy Chanukah
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.
I read it when it first came out. Very shocking and powerful book
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.