After declaring my intention to help iterate on the Ticket extension to IndieAuth, I built an experimental ticket endpoint, which is available on my test site. I was able to test it using Martijn van Der Ven’s test form for requesting a ticket., after some troubleshooting on both sides. Still have some tweaks to make and questions to answer for expansion, but it turned out that adding support for receiving and redeeming a ticket was relatively easy.

Thinking about Ticket Auth

During this month’s Pop-Up event, as part of the overall topic of sensitive data we were discussing the continual challenges in getting a method of having private posts on one’s site. As a community, nothing has gained enough traction for adoption.

Last summer, a conversation on the most promising at the time, AutoAuth, prompted a new contender Ticket Auth. Ticket Auth turns the relationship in the other direction.

Let’s use our favorite two example people, Alice and Bob. Alice has a post on her site which she doesn’t want to be public. For most sites, the default is public. Alice wants to share her post only with Bob.

AutoAuth doesn’t get into the idea of how Bob, or the client Bob is using, decides he wants to get access to Alice’s post. Ticket Auth, by comparison, puts the onus on Alice. Alice, when she decides on her audience, sends a ticket to those she wants to have access. Bob has to have a ticket endpoint…the place he received tickets.

The ticket is a code that is available for a limited time, that can be exchanged for a longer term token to access the information. It is, essentially, an invitation you are free to accept or ignore.

In trying to develop more, this is a good place to start. Once we start sending and receiving tickets, we can iterate on this and figure out the next questions.

  • Can you ask for a ticket and how?
  • How can you give the ticket or the token you redeem to your reader or other client?

But first things first. Let’s build something.

 

 

Working on expiring tokens for the WordPress IndieAuth endpoint. This would be a breaking change, as currently, tokens issued by the endpoint never expire. This is a security concern, if you keep issuing tokens without ever expiring them. With the new system, you can renew a token, or even disable expiry in the admin if you need a long-lived token. There is a way to have the client get new tokens regularly that I could implement, but currently no client supports it.
In November 2018, we went to Orlando to perform the Parkeology Challenge.  We came close, but did not succeed. We had always hoped to try again, but illness, as well as the pandemic restricting travel, had pushed it off. Now one of the team is no longer with us(the one who took the photo).

I’ve never been particularly good at speaking of those who have gone, and the stories I might choose to tell are probably would not do justice to the memory.

There is little to say when someone is taken from their friends and loved ones too soon. When we were kids, he, being a few years older, was primarily my brother’s friend, but we all did things together…our families frequently got together. It is hard to accept I will not see him again.

The best I can think of to do that would please him is to finish this one thing we never completed someday.

Just a few updates from the last week.

  • Updated the Parse This library to optionally flatten the location parameter, as Indigenous and other Microsub readers do not recognize a nested location parameter.
  • Fixed a Simple Location issue where it was not setting the location taxonomy on Micropub post.
  • Simplified some of the Location interfaces
  • Minor bug fixes.