In the midst of a re-write of how my site works and in passing conversation in the IndieWeb chat, I think about how to 'show' the IndieWeb as something people can invest in versus a collection of things that...
Now that you know why posting for “free” on MySpaceBook isn’t a good idea. Check out Micro.blog. I just paid for another year, again. Totally worth it. Micro.blog is the easy way to #indieweb.
I can very much relate to what Craig is saying here.
Woop woop! Very excited for this 🎉 looking forward to sharing a bit more about what the #IndieWeb is, why you may be interested and what folks can do to get involved!
Reminder that it's #HomebrewWebsiteClub Nottingham tomorrow! I hope to see you there at 1730 for some website stuff! https://events.indieweb.org/2021/03/homebrew-website-club-nottingham-VSpbmyQEbxQZ
Foreword A couple of weeks ago I noticed one of our newer IndieWeb community participants found an example on the IndieWeb wiki that no longer worked, and it was from someone who hasn’t been around for a while. I knew that person had various things come up in their personal life, thus left without...
As part of my attempt to work on something IndieWeb every weekend, I decided to do a bit of a dive into the code for https://github.com/kylewm/silo.pub. It’s known as being a (working) example of using Micropub as a means of syndication. Conventionally, people do this using Webmentions via brid.gy - but I am curious about having such a system automatically add syndication back-links to my posts as well as being able to dynamically use it back-fill posts to my site (since it can do the former with potentially less magic than Webmention parsing).
I notice that in order to use silo.pub
, you forward the entire incoming Micropub request to the remote endpoint (we can call it ‘syndication endpoint’). This feels a bit tricky to implement because I can see it being simpler as the originating site of the request to only just send a URL of the post that needed to be syndicated - part of the appeal of Bridgy is that. But having to forward the whole thing feels interesting. But it also allows for a means of insuring that a particular syndication location only gets what it can support or what’s appropriate for that destination (bookmarks could be formatted more differently on Twitter or how reading progress is reflected).
I think I can “get” with this approach but I’m going to take a bit of a different approach. Instead of forwarding the whole body, I’m going to send it a request to update a post. Something like the following:
POST /syndication/twitter
{
"action": "update",
"url": "https://jacky.wtf/a-post-to-share"
}
With no other arguments, this would tell the Micropub-powered syndication endpoint that it should update the provided post. Being that this one is optimized for Twitter, it could do the work of sending the tweet (or replying, or liking) and then sending a Micropub update to the original post with the change in the syndication URL. A server noticing that could use that as a way to determine that the syndication was successful with no extra need to add asynchronous processing - we get it for free.
Okay, finally ready to make https://jacky.wtf a static site powered by this new Micropub server. You can peek at the code at https://git.jacky.wtf/indieweb/koype-next but I’ll be aiming to use it to redo a lot of sites (like even https://koype.net because if I can’t use it there then I’m kidding myself, lol)
I love, love, love this experiment from Matt—messin’ around in websites!
It was a treat to chat with @jayeless who has so many interesting interests! Have a listen to the latest episode of the Micro @monday podcast, as we cover: Melbourne, indieweb, linguistics and regional English, Harry Potter houses, and of course, Gidget the cat.
Looking forward to talking about all things #IndieWeb, owning your data, and some of the cool open standards and tech we've worked on to take back a bit of control 🤓