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 🤓
Thinking about this again, it does feel like this could be something that the Micropub server does but would be invoked by some external process. Like if it’s a property (like
) that needs to change, then the remote service could perhaps trigger this (could happen from getting a Salmention).
Have you read over the IndieAuth spec? I did read the WebID spec some time ago, back when people were toying to expose it in Mastodon and it never went through because it’s not friendly to portability (people change names, identities [think trans, non-binary folks, ex-pats]) nor is it friendly to being used offline
According to this incubating spec https://www.w3.org/2005/Incubator/webid/spec/ and https://www.w3.org/ns/auth/cert, it does require certificates (I never said TLS) to insure that it’s secure. Otherwise, you’d be reintroducing the era of FireSheep https://en.wikipedia.org/wiki/Firesheep.
Also IndieAuth would literally require only one of those “rings”.