I like the playlist idea! I’m listening to yours now.
I made a couple mix CDs back in the day that I was proud of. That was always fun, but I’ve not carried that over to making playlists for some reason... yet.
Come down now
Jimmy Eat World’s setlist from last night:
- Futures Intro
- Bleed American
- All the Way
- Hear You Me
- No Sensitivity
- Chase This Light
- Big Casino
- Sure and Certain
- Night Drive
- Praise Chorus
- The Middle
#indieweb-dev chat reminded me that HTTP Status can be returned in <meta> tags. Verify and test that this module can handle that scenario.
I have slowly but surely been working on an IndieAuth module for ProcessWire. IndieAuth lets you sign in to applications using your domain name and grant access to read/write to your site. I initially set up a version of this in 2016. My understanding of IndieAuth was limited at the time and it really only let you use IndieAuth to sign into your own site. There are some interesting possibilities there, but it was premature.
So what does this module actually do?
1. Authentication: When you visit a site like indielogin.com and enter your domain name, you will be taken to your ProcessWire admin area to approve the request. If you approve the request, you will be returned to the site and logged in as your domain name.
2. Authorization: When you visit an application like Quill, it needs to also get your permission to post to your site. You will be taken to your ProcessWire admin area to approve the request and the scopes that the app is requesting (create, update, delete, etc.). If you approve the request, you will be returned to the app, logged in as your domain name, and the app will have an access token for your site.
- Browse the applications you have granted access tokens to. See when each one was granted, last used, and will expire.
- Revoke any application’s access tokens
- Set the default expiration period for new access tokens. The initial default is 14 days.
- During authorization, confirm and change the scopes granted to the application. For example, an app may request “create” and “delete” scopes, but you can grant only “create.”
- During authorization, you can also choose to grant an access token with no expiration
Try it out!
I have been testing the new module and think it is almost ready to release in the ProcessWire modules directory. I would like to have a few more people beta test it and provide feedback first, though. If you’re interested, follow these steps:
- Download ProcessWire IndieAuth from Github and follow the instructions there to install it
- Test Authentication: visit indielogin.com and enter your domain name. Follow the prompts to authenticate and you should end up back on indielogin.com with a success message.
- Test Authorization: visit Quill and enter your domain name. Follow the prompts, noting the additional fields for scopes and expiration. After successfully authorizing, you should end up back on Quill with a success message.
- Go back to the ProcessWire admin area of your site. Visit Access > IndieAuth and you should see an entry for the access you just granted to Quill.
Optionally test access tokens
To test access tokens, you will need a module that accepts them. I have set up a minimal Micropub module for that purpose. All it does currently is verify the access token and shows a debugging message indicating the request was received.
Follow the instructions to install the Micropub module. Go back to Quill and try to post a short note to your site. Quill is expected to respond with “Something went wrong,” but scroll down and the section labelled Micropub response should show “Debugging: Micropub request received.” If you see that, it means the Micropub module successfully received and verified the access token!
The Micropub module will eventually be fully functional so you can publish to your site using a variety of Micropub clients, but that is a separate project that is going to take me some more time. I wanted to get the IndieAuth module out there instead of waiting to release both at the same time.
If you’re interested in more details on IndieAuth, I recommend “OAuth for the Open Web” by Aaron Parecki. If you are interested in implementing IndieAuth in your project, see the IndieAuth specification.
Currently reading: The Infinite Future by (ISBN 9780735224339)
Today at work I came across an old web form that a client still uses with this warning about Netscape browsers.
If you use Netscape 6.0 or above as your Browser please note before proceeding: Netscape (6.0 and above) has a bug which may cause a security flaw when submitting your listing. To avoid possible errors, we recommend that you access an older version of Netscape (5.0 or below) or a different Browser.
For context, Netscape 6 was released in November of 2000. This form has been around 21 years!
Bought my first ticket for an in-person concert since the pandemic. Weird feeling, but excited. Chvrches in December!
I have been using Sublime since v2 and still really liking it. v4 has been nice so far, but I haven't dug into the new features yet.
Want to listen: Good Christian Fun podcast: Mark Lowry (with Justin McElroy)
Today I dipped my toes back into IndieWeb land (lake?) by joining the pop-up session, “Respectful Responses.” I didn’t go in with a specific goal; it just sounded like a good topic:
How do we enable more positive serendipity & discovery via our websites, between both existing friends & family, and new positive interactions. And how do we raise barriers to spam, harassment, and other unpleasant social media interactions.
The session got me thinking more about the commenting experience for people without personal websites. David talked about the experience of leaving a comment and expecting it to appear immediately. Some sites will display a message that the comment is pending moderation, and some will even show the commenter a preview of their comment. My site does the former if I have not approved a comment from your email address before. I had not considered that could be a negative experience for some people. The more I thought about it, I realized that many times when I link an article on Facebook or Twitter, people will come to my site to read it then go back to the social site to leave a comment instead of using my local comment form.
This could be for various reasons. The most obvious is probably the ease of posting on the social site. It’s one text field, the comment appears immediately, and that is how people interact online the majority of the time. My local comment form with fields for name, email address, website, and comment is tedious by comparison. I realize the required email address field is off-putting as well.
I like the idea of changing that experience around so instead of a comment form that’s always public, comments are allowed from a trusted audience. That audience could be as broad as “people who have logged in to my site.” I think the barrier of logging in would still mean people would go back to the social sites to respond, though. I am not sure how to get around that. That is often the challenge with IndieWeb: creating experiences that are at least as easy as the silos.