Indieauth for WordPress 3.3 Released

The 3.3 branch of IndieAuth for WordPress is now available.

  • PKCE Support is now present in Indieauth for WordPress. PKCE protects against intercepted authorization codes by ensuring a token endpoint can confirm that the client attempting to redeem an authorization code is the same client that requested it.
  • Token generation is now done using SHA256, as opposed to the built-in WordPress Hashing.

WordPress hashing combines key stretching with eight passes of MD5. MD5 by itself is not very secure, but the WordPress hashing is much more so. The reason why a hash that isn’t more secure isn’t in WordPress Core itself is the fact that the features require newer versions of PHP than WordPress’s minimum version.

The change to using SHA256 bumps the minimum PHP version of the plugin to PHP5.4. That said, WordPress itself has scheduled finally upping its minimum to PHP 5.6 in WordPress Version 5.2 scheduled to be released next month, and will be looking to leverage anything useful in those versions. That may also cause WordPress itself to change its hashing to something less controversial.

The 3.0 branch of IndieAuth has added a lot of useful features.

The last release added profile support for returns, which allows a client to get the name and avatar of the user associated with the token, for display. The WordPress plugin was the first IndieAuth endpoint to adopt this experimental option, which is still under development, and Quill had to be updated to support it as a reference implementation.

IndieAuth is a fairly stable plugin, but there are still opportunities in future for expansion. A few things I’d like to do in future.

    • Invalidate Tokens when a User Changes their Password
    • Bulk Actions to Expire Tokens
    • Implement Scope Support – Right now this is handled by whatever is being accessed, not the Indieauth plugin itself. This would be possible by mapping scopes to WordPress user capabilities.

Curious what others might want to see.

Indieweb Post Kinds 3.2.0 and Micropub 2.0.8 Released

Tonight, two releases of WordPress Indieweb plugins.

Micropub 2.0.8 was released, adding some minor changes to support the new check-in option offered in Indigenous for Android.

Indieweb Post Kinds 3.2.0 was released. It switches from SVG sprites to inline SVG icons, removes some extra files that were bundled as part of the plugin but only needed in the development version, and adds a basic template to display events and itineraries published via Micropub.

It also includes the latest version of Parse This, which handles the storage of microformats in WordPress as well as parsing and processing data from URLs for the link previews.

This adds a bunch of fixes to functionality, despite the fact that this is an incremental update to Post Kinds itself, it should be a better experience, as the ability to get title and data out of Youtube is back, along with enhancements to extract author information out of additional sites.

RSVPed Attending IndieWebCamp Online

IndieWebCamp Online 2019 is a gathering for independent web creators of all kinds, from graphic artists, to designers, UX engineers, coders, hackers, to share ideas, actively work on creating for their own personal websites, and build upon each others creations.

RSVPed Attending IndieWebCamp New Haven

IndieWebCamp New Haven 2019 is a gathering for independent web creators of all kinds, from graphic artists, to designers, UX engineers, coders, hackers, to share ideas, actively work on creating for their own personal websites, and build upon each others creations.

Thinking about Bridging

I am writing this post on my phone, which is a challenge in itself.

But at Indiewebcamp Austin this past weekend, I was trying to explain the realization that I had back at the Summit in June.

Bridgy, the prime example of that, was launched in Indieweb form in December 2013. It creates a bridge between Indieweb protocols and proprietary APIs. So you can post on your site, post the same on another site like Twitter(or ask Bridgy to do it for you). And any responses are sent back using Indieweb protocols.

This philosophy encourages inclusivity. It connects those trying to adopt Indieweb principles to those who don’t know what that is seamlessly.

Building these connections between the Indieweb and other systems means you don’t have to give up those systems to join the Indieweb.

Other similar initiatives cannot say that they place such a priority on this. It is a better way to build. It has brought people to the community in my opinion.

The Indieweb principles of modularity suggests you build your platform on pieces that can be swapped out. This was referring to devices, storage methods, etc.

Several large companies are collaborating on the Data Transfer Project, to allow you to move your data from one platform to another with one click.. but they aren’t necessarily thinking about syncing to keep usable backups in multiple places.

But between it and plurality, which suggests we encourage a variety of approaches and implementations, we didn’t as a community explain our principles of connecting things even if they don’t follow these principles. We have just done it.

I have come across this in trying to help implement a Microsub endpoint, which turns any input into the same format, so you can read it in a client that doesn’t have to know about the original format.

Trying to turn RSS, Jsonfeed, Microformats, etc into a single type of output is a challenge I am still working on. But I could go farther with that.

If you make everything interoperate, you don’t have to cut yourself off from one group, one data source, etc. You can bring everything together and the part of it that is yours is still under your control.

Indigenous for Android now supports a feature that was added in the version of Simple Location I just released. As part of the recent private geofencing feature I released, it now sends when the location is not to be disclosed to Indigenous, who sets it the interface appropriately(though it can still be overridden). Also released a few minor bugfixes.
Replied to https://micro.blog/the/2470134 by the the (micro.blog)

@dshanske Hmmm, Siri says my elevation is “about 42m.” Does that vary during the day with the tide? Does it vary over the lunar month? (Enquiring minds and all that.)

The altitude reading on phones is not necessarily the most precise and can vary. It is GPS based, with some calculations done. I compared it to the altitude showing on the in-flight map and it isn’t that close. When there is no altitude data, my website actually uses an elevation API to provide an estimated altitude. For example, it is estimating my house is 29 meters above sea level, but I don’t display altitude unless it is significant.
Replied to https://micro.blog/nitinkhanna/2469677 by nitinkhannanitinkhanna (micro.blog)

@dshanske I was just pulling your leg! Whenever I think about interesting features on blogs, these two names come up, and now yours. How does private geofencing work?

Well, geofencing is the idea of triggering an event when something enters, leaves, or is inside an area. The biggest issue I had with adding my location to posts was that sometimes, I didn’t want to be specific as to where I was. Now, if you are inside one of these zones, it will hide the actual location automatically and replace it with a text description, such as ‘Home’, or ‘Work’. (Like this post on my website).

Simple Location 3.6.0 Released

There is a new update to Simple Locations which adds some new features.

  • A query option for Micropub was added in a prior version and adjusted in this one. This is currently only supported in the Indigenous for Android app.  It allows the Android app to query the plugin for the name of the current location, to display and edit in the app.
  • Wikimedia Maps was added as a map provider, which is displayable without an API key
  • There’s a new setting that only shows altitude above a configurable height.

The biggest feature is Zones. Zones is a geofencing feature. If your location is inside the zone, it will not display the exact location, only a textual description.

Zones consist of a name, a location, and a radius around that location. If you are posting in the UI, it will replace the actual location name with that of the zone, and set the visibility to protected to add the actual coordinates.

If you are posted via Micropub, it will set the same, unless the location visibility property exists, and then it will follow that. Currently, this property is only supported by Indigenous for Android.

So, what does this mean? It means I am safe to post to my site and know that if I’m in one of these locations, it will obscure it unless I say otherwise. This is the first step to more granular visibility of location allowing me to store it in all posts, knowing that it won’t be shared specifically in areas I don’t want it to be shown in.