Enjoying endangered gardens
Enjoying endangered gardens
Thanks to Matthew for reading my post on recent IndieWeb discourse and adding a new section with his responses and notifying me about it via email.
There are certainly a number of things in Matthew’s response that tempt me to respond, but I’d like to focus on this:
I am, nevertheless, a little annoyed by the exhortation to “talk with us”. What does it look like I’m doing over here, anyway? Oh, no, it’s not good enough to post one’s opinion on the web. I’m supposed to use one of the IndieWeb’s chats, either IRC, Slack, or Discord. […] I am already talking with you. I’m doing it here, on my own website for all to see, in the best IndieWeb tradition. And you are talking to me if you quote me on your own website or email me.
I don’t consider my post a reply to Matthew’s post. I do not see his post as an invitation to conversation. I read it as a “take” - an opinion piece intended to make the reader feel a certain way and then close the topic, complete with clickbait headline.
I shouldn’t have to point out that bloggers-blogging-at-bloggers has a long history of unproductive conversation. Reducing the impact of unproductive conversations is part is why there’s not an IndieWeb mailing list. It’s easy in these formats to go hard on the abstract, and to spend time constructing arguments instead of asking questions.
That’s not to say that posts can’t inspire change. In the past day or so indieweb.org/discuss has been updated to mention right in the opening sentence that the IRC, web, Slack, and Discord chats are all bridged. Discussions have also kicked up (not for the first time) around making the homepage more welcoming, focusing on principles first, etc.
Those changes are being decided in the real-time chat, where you can meet and talk with the individuals (all volunteers!) who make up the IndieWeb community. I reckon it beats trying to reverse-engineer that community from a wiki.
Sharing for my fedi-peeps. That’s a term, right?
Has the IndieWeb become discourse, again? https://martymcgui.re/2024/08/29/141602/
I recently read Has the IndieWeb Become Irrelevant from starbreaker.org.
The post does a great job linking to and summarizing a spate of posts that I will call “people being mad at the IndieWeb”, while also being one of these posts.
These posts accuse “the IndieWeb” of being elitist, exclusionary, overengineered, complicit, and unnecessary, among many other things.
There are some common threads I noticed among these posts:
Folks that would like to try a turnkey website hosting service, where:
I don’t see eye-to-eye with its creator Manton Reese about everything, but micro.blog is a great example of a real world service that makes use of IndieWeb building blocks in ways that customers benefit from without having to build anything!
I think many of other complaints, from being “overengineered” to (paraphased) “POSSE makes IndieWeb complicit with the corporate web”, come from misconstruing the IndieWeb wiki at indieweb.org as the entirety of “being IndieWeb”.
When I discovered indieweb.org (in maybe 2015?) I was intrigued and nearly instantly overwhelemed. Trying to absorb all the concepts there would be nearly impossible. Understanding and implementing all the techniques there is actually impossible.
That’s because indieweb.org is not a presciption or a cookbook or an exercise plan. It doesn’t tell you how to “be IndieWeb”. It’s a collective memory of experiments, some successful and some not, from a group of experimenters that has changed greatly over time.
For example, I find that criticisms like “f*ck the corporate web and f*ck IndieWeb for interoperating with the corporate web” don’t really hold up when a lot of that stuff doesn’t even work anymore.
Automatic POSSE, syndicating posts from your own site out to your profiles on social silos, only ever barely (and briefly) worked for Instagram, was turned off for Facebook a few years ago, and was all but destroyed for Twitter shortly after its last acquisition. backfeed - pulling comments and likes from these platforms to display on your own site - has similarly been blocked by technical measures.
These were experiments that worked for a time. People used them for a time. That time has passed and the people have moved on.
Some folks have replaced their Twitter usage with something like Mastodon, or Blue Sky, or Threads, and amazing people like Ryan have stepped up to help experiment with bridging personal sites and federated services.
People don’t have to move on for purely technical reasons. Even before Twitter closed their APIs, many in the IndieWeb community were shuttering their Twitter accounts and removing posts. They moved on from Twitter, despite all those documented pages on the IndieWeb wiki, because they didn’t want to use the web this way anymore.
And to me, this is actually what “being IndieWeb” or “doing IndieWeb” is about: using the web in ways that fit your wants and needs, being mindful of when (and to whom) you give up control over your stuff and your connections.
Figuring out how you want to use the web is a daunting task, to say the least! The IndieWeb wiki is full of interesting examples and ideas - but as a logbook of ways of using the web, it can be inscrutable. It was never intended that every way of using the web would be suitable for everyone. A collective memory is extremely hard to keep up-to-date and to signpost for navigation. Trying to rely on the wiki alone is a recipe for frustration.
I freely admit that the community has fallen into some serious prescriptive traps over time. Like with tools like indiewebify.me that offer a checklist of implementation details, without accompanying reasons why you might want these features.
This isn’t the first time this has happened, by any means, and it won’t be the last, but the criticisms of these tools and models do make their way back into the collective memory. (see: generations and IndieMark)
That’s why the IndieWeb chat exists. It’s a place where real actual people, who are working to use the web in ways that suit them, are ready to help in whatever ways we can. We love to share what is (and is not) working for us, what we’re trying, and so on. More importantly, we want to help you find ways of using the web that work for you.
Are you safely stowed away during eternal Caturday?
Are you giving it your all during eternal Caturday?
Are you a member of the 🕸️💍 IndieWeb Webring? Or have you wanted to be, but you couldn't sign in because it strictly required IndieAuth for sign-in?
I was recently gently reminded that the IndieWeb webring at one time allowed you to verify your identity using an alternative sign-in mechanism. For instance, by making bi-directional links between your home page and your GitHub account, you can delegate the step of "proving" that you are the person in control of your homepage to GitHub, and let them worry about storing and checking usernames and passwords.
This concept is called RelMeAuth (because it works by embedding links in your homepage let look like <a rel="me" ... >). The original version of the webring would first check to see if your site specifies its own IndieAuth provider and, if not, would fall back to using Aaron Parecki's indielogin.com, which handles checking for these rel="me" links to supported sites. It also supports sending codes to your email, if you prefer!
Yeah! I, uh, broke it when I moved the site over to PHP some time ago.
It should! If your homepage has no IndieAuth server specified, but has rel="me" links to your GitHub or an email "mailto:" link, you should be able to sign in to the webring using those methods!
😅 it was fixed within a day of someone telling me it was broken!
Here are the updates I added today to enable indielogin.com support. Some of it is a little hacky until indielogin.com is updated to allow the full client_id URL for the webring, but it works OK!
Okay that's it, for now! Thanks for reading, imaginary interlocutor! As always, feel free to reply to this post on your own site, or feel free to drop me a line in the #indieweb chat (I’m schmarty there)!
IndieWebbing requires fuel
Chill vibes achieved
Ok we finally internalized the deal of this place and had to go right now.
Decided we should spend our energy before the rain!
Cocktails, food trucks, outdoor seating!
Time to start existing for the day!
EWR ✈️ PDX
Flying requires fuel
Continuing to EWR
NYP 🚈 EWR
Looking forward to spending some quality time with some quality IndieWeb folks! 💖
Excited for my first in-person IndieWeb event in quite some time!
Are you anxious about packing during eternal Caturday?
I just posted Sticky Scribbles to Glitch as a Glitch Jam entry for August 2024. The prompt got me thinking about some old web art projects that have come and gone, so I picked one up, dusted it off, dropped it on the floor, stepped on it, cut myself on the pieces, bought expensive raw goods from the store, and rebuilt a nearly unrecognizable new version that does the same thing.
I thought I’d post the write-up on my blog, as well.
Need to erase? A page refresh will clear all scribbling.
The fonts are vector strokes suitable for plotting. They’re called Hershey fonts and their story is pretty interesting!
You can also find the full source and history on GitHub.
Inspired by the August 2024 Glitch Jams prompt of “#justdraw”, I remembered an old project from 2011.
Back then I worked for MakerBot Industries and, at the urging of my friend Matt Griffin,
had started a descent into madnes- pen plotting. For me, that meant using the
MakerBot Unicorn a tool for the MakerBot Cupcake CNC that replaced the plastic extruder
to turn a 3D printer into a loosey-goosey pen plotter.
As with most DIY 3D printers of the day, the Cupcake CNC was driven by G-Code - short instructions sent over a serial port to tell it how to move its motors, etc. When I started playing around, the process for going from some vector artwork to G-Code was pretty labor intensive and required multiple tools.
The work area for the Cupcake CNC is 10cm square, which is just a little bit bigger than
a pad of 3"x3" name brand sticky notes. So, these easily becamie a target for my madnes making.
In February of that year I particpated in “Thing-a-Day” on Posterous (RIP), and worked on several projects to try and boost the ease of use of this whole ecosystem.
Mashing up some example Python code from the Unicorn release, and the Inkscape driver for Evil Mad Scientist Laboratories’ EggBot, this extension let you save (simple) drawings as G-Code that you could plot using a Cupcake CNC + Unicorn.
While I made this Inkscape extension to serve a very niche machine, I ended up continuing to improve it here and there. I was surprised to see it adopted by some DIY CNC projects from all over the world!
Unfortunately, I never made much of a habit out of using my own extension, so when the extension interfaces changed for Inkscape 0.91.x, I ended up marking it read-only.
There are over 100 forks, though, so maybe somebody picked it back up!
Matt introduced me to Hershey fonts, a set of vector fonts designed for the U.S. government for use on CNC machines for plotting or engraving. These were in a somewhat legible format, so I became a little obsessed with using them for plotter projects.
I’d love to share gratuitous details about rewriting bits of this little tool. Unfortunately, I worked on it live on my site that entire time without any version control. 😭
(Where was Glitch in 2011?? lol)
While you can find the entire history on the sticky-scribbles GitHub,
I had a good time figuring out how I left this ~13 year old project and choosing ways to “modernize”
or at least “make it less bad to my eyes”.
The drawing canvas markup can be summarized like this:
<svg> with background image of the stick note
<g>roup with a painstakingly trial-and-errored transform that made rendered Hershey
text look “mostly right”
<g>roup for the actual rendered Hershey text<g>roup for the scribblesWhen we scribble onto the canvas, the pointer coordinates don’t account for that transform, so
if we save them as-is, they’ll be skewed from where they appear on the sticky note preview.
Previously, I tried to do a bunch of math on my own, which worked out really badly.
Since then, I realized that if I have an existing transform, I can:
When we add the transformed coordinate to our scribble, it now visually lines up with the preview on the sticky note! Miracle.
The 2011 version of this demo used Jeff Wood’s jQuery SVG plugin
to rebuild pretty much the entire contents of the <svg> any time something changed.
However, the main structure of the SVG described above doesn’t change at all! So I moved the
<g>roups that contain the transform to make things line up with the sticky note, and its
inner <g>roups for the rendered Hershey text and pointer scribbles into the markup on the page.
There were still a couple of useful utilities for creating <g>roup and <path> elements in the
jQuery SVG plugin, so I made my own version in a little ES module svg helper
There were lots of jQuery-isms that I vanilla-ized and in many cases modernized.
$('#someid') with a single document.querySelector and a variable$(someArray).each(...) with for (const item of someArray)hershey.js font parsing and rendering helper as an ES module.
async and Promises to get rid of some messy setTimeout calls around font loading.var declarations with let and constOne of the biggest changes was extracting the handling of events and (re-)rendering out of a big spaghetti ball and into self-contained bits. I did these as web components that don’t actually manage any child HTML. Instead, their attributes tell them which elements on the page they should hook into for events or render onto.
The <svg-scribbler> component is interesting because I have it lean more into using the DOM as
new scribbles are added.
Previously: as the user draws a new scribble, they’re pushed into an array, and on every change we basically call a “render” function that throws out the SVG contents and re-creates it.
The new component simply creates a new <path> element when the user starts drawing and updates the
d attribute as the user draws. When they stop drawing, the <path> is already in the page and done.
When the user starts drawing again, we a new <path> element is created without disturbing any
existing <path>s from previous scribbles.
Take a look at js/svg-scribbler.js for details.
Similarly, the <svg-hersheytext> component takes care of listening for changes as you type
in the <textarea> and re-rendering the <path>s for the text contents.
One wrinkle here is that we have a <select> dropdown to let you select a different Hershey
font. Previously, a jQuery change handler on the <select> for choosing a Hershey font would load
the newly selected font and then call what amounted to a top-level “render” function to draw
all Hershey text and scribbles again.
The updated version uses a simpler event handler that emits a custom HersheyFont:updated event.
<svg-hersheytext> elements listen for that custom events on the window object, and re-renders.
If you haven’t used them, I think Chris Ferdinandi does a great job explaining the how and why of custom events.
Wrapped up in the previous spaghetti of “render-everything” style calls was a stop to generate
an SVG string and slap it in a <textarea>.
Now that the most of the SVG stays around in the page, I’ve replaced that with a MutationObserver that kicks off whenever elements are added or changed down in the SVG tree. I love this!
pointer* events handling does unexpected things on multi-touch devicesFor example, this two-finger drag makes kind of a zig-zaggy filled-in area instead of two distinct lines:
I think this is fun and weird, actually.
inkscape-unicorn is deprecated!Yeah so the tool this was designed to make drawings for isn’t really a going thing in 2024.
Um. Sorry? Enjoy your SVG scribbles anyway!
Are you waiting for something during eternal Caturday?
