if you’re in tech, do you have a personal website? bonus points for why. 😇
byfantastic ms. • posted archived copycurrent

I do! I actually wrote this reply to you from my site (heavy lifting done by brid.gy). I like having a place where I can point to people and say, “I did that. It might not be awesome, it might look weird, but I DID THAT”. And then put a photo of myself doing that on that site, lol.

Having a website allows a level of digital personal expression that's becoming more and more rare as more things tend to get more sterile and less “hand-made”.

Thoughts on BlueSky's "Self Authenticating Social" Protocol

Got a chance to read https://blueskyweb.xyz/blog/3-6-2022-a-self-authenticating-social-protocol. It starts off pretty good, speaking on popular open protocols and approaches. It then brings up scale and Twitter's experience, which is really more of a concern for commercial identities—information gets where it needs to be when it can be routed there. The need for “always accessible AND high speed AND high throughout handling” really is a demand of capitalism and not that of people, so I readjusted how I perceived this from that framing going forward.

The fact that the only explicit link to the IndieWeb is to the death of witches.town is wild, but go off. This is within the “Portability” heading, which does a good job of pointing out the failings of relying on someone else to hold your information. We all still do this today—I do it by trusting DigitalOcean to keep my leased server running, files intact and connected to the Internet, DNSimple to keep resolving my domain names and maintain my lease on domain names. The Web is rented for the most part and as it stands, it has to be. I can't beam information to the UK without relying on probably ten other companies to route that information there. That's done transparently to the users involved and is mainly run by private entities, so there's no raw ability to audit such a connection without having a deep understanding of network engineering. I say all of that to say that you have to draw the line somewhere when it comes to who to trust, and I stopped at "running things for me". I didn't want people writings software for everything for me, so I tend to use freely licensed software and make whenever I feel like (like this site). That requires time, patience and a deep interest in doing so. Not a lot of people have that, so I'm deeply curious how the Bluesky team aims to solve that techno-sociological problem before creating a new set of them.

Scale is the part that screams, “we need to find a way to subtly profit from making something in the leasable commons”. Especially this part:

Existing decentralized social protocols default to local conversations because it’s a natural fit for a decentralized architecture, but our goal is to make global conversations possible while preserving the freedoms users gain from interacting through an open protocol.

Local conversation isn't only a “natural fit” for decentralized architecture, it's a natural fit for humans. Dunbar's number hints at the notion that we can only reasonably interact with about 200 people, so attempting to keep someone up to date on about 200 people daily sounds like trying to remake existing systems, but now it just lives on your devices as well. I know that for things like Lwa and even Lighthouse, keeping it from being super spam-tastic is going to be a critical feature. Like it shouldn't get to a point where you're scrolling infinitely—you have better things to do.

I really like this idea:

The premise of Bluesky, however, is to work towards a transparent and verifiable system from the bottom up by building a network that is open by default. We’ll do this by giving users ways to audit the performance of services and the ability to switch if they are dissatisfied.

This is something I want for the IndieWeb as well—other communities have it and can do it indirectly by using NodeInfo since a lot of the federated Web already uses it. Being able to have sites self-report about their public capabilities also gives people to vet the community and gives them a sort of report card. I think extending it to other systems is interesting. Especially in the case of “aggregation” or “feudal” systems, being able to take all of your information and work within a new system is still very hard. And it might not be completely a protocol or standard issue, it's similar to the situation of backups—you know they work when you use them, but can you reliably test every backup from the point of initial creation? That aside, I'm very in favor of sites handling levels of self-reporting on capability. Shock has NodeInfo reporting as a potential feature so I can see a service that can find IndieWeb features there can then run a set of semi-SWAT0 tests against the site. On the point of transparency, I think this is less of a problem for the IndieWeb, but still can be addressed. I know that for Lighthouse, every nudge of feed control that I can provide while keeping the abstractions put in place is going to be provided. Like if a post has been filtered out, I want people to know why and be able to issue 'block' statements. It's something I'm going to be working on for Lwa but I think this is something that should be baked into Microsub as well.

I'm glad that they admit later on that it's a “do what you want, but understand the risks” with their long-term goals. I do think that having backups / synchronization built into the system early can dramatically reduce the worry of data loss—it's kept as redundant as possible. However, the notion of aggregators being the place where things like search indices and metrics lie is a bit worrisome to me. There's definitely a level of local computation that we should employ on more powerful devices and give people a choice—the theme of my life. Again, this gives an opportunity for more explicit trust in these services and allows people to go full sovereign if needed. I do appreciate them calling out the immaturity of the cryptographic primitives in this space and how it'll need more work.

All in all, I hope that this stuff works on the actual Web, doesn't reinvent too much of the wheel and works to extend versus rebuild.

Manton has a book that's available online and as print at https://book.micro.blog/. Been reading https://book.micro.blog/interview-tantek-aaron/ and noticing a lot of things that are cyclic when it comes to the IndieWeb space.

Namely, getting from “I need a Website to be on the IndieWeb” to “I use this as my presence online”. Hosting is a solved problem, but it requires quite a bit of investment up front and the funds to hold down things for people. I still think we require some sort of “linting” tool for sites to make sure they at least allow for some baseline discovery and interoperability. Angelo's working on something like this but not completely. I might end up doing this to help people onboard when they use Lwa but it'd also help to explain what can get you into an app before using it. Or at least interoperating with other sites and apps. A bit of the XMPP problem, but at least there's a registry and a way to check your implementation for support via https://compliance.conversations.im/.

I guess the main part I find confusing is setting it up with GitHub Pages as there are loads of plugins like the WebMentions plugin and Syndication Links plugin there's only a certain amount of themes. How do you set up Bridgy to crosspost Twitter and GitHub Pages?
byToyin Ariyo • posted archived copycurrent

I think it'd help to figure out what it is you want to do. Like it sounds like your biggest concern is being able to https://indieweb.org/POSSE. If you don't have an issue tying some things together, there's a lot of existing prior art for stuff at https://indieweb.org/projects. https://micro.blog/ also does a lot of this for you with client apps.

All this time, my representative h-card was missing a link back to itself to prove that .. it was the representative h-card. Marty said something in the chat that I can't find but some sort of "MF2 linting" for post type discovery is definitely needed (and I can see such a tool making the lives of newcomers and experienced people alike a lot easier).

I published a new version of the IndieWeb Rust crate that has logic for a passing implementation of the Webmention endpoint discovery flow. Aiming to work to decouple the explicit use of ureq, so people can bring their own HTTP client.

I should probably get back to working on release for the Rust crate for the IndieWeb. And probably move the Elixir library into the community repository on GitHub if I can do that. Need to keep the ecosystem healthy! I could even make a demonstration app on how to use it with Elixir so others can try it out.

Screech - a micropub client for podcasting

Screech - a micropub client for podcasting

I've been working on my idea of what IndieWeb podcast publishing looks like for some months now, both with the improvised We Have to Ask comedy podcast that I make with Jonathan Monroe and more recently with the This Week in the IndieWeb Audio Edition that I started producing last month.

In addition to following standard IndieWeb-friendly practices like using microformats2 feeds, backfeeding social interactions from Twitter and Facebook with bridgy, and exploring other interesting audio markup tricks, I wanted a tool that made it easy for me to publish new content to my sites via the Micropub protocol, which supports sending audio media files.

I didn't see another micropub client in the wild that supported audio files in the way that I wanted, so I made my own.

Screech is an audio-publishing-focused micropub web client with a Python server component built on Flask. Screech supports logging in with your own site using indieauth and posts to your site's micropub endpoint.

It's still a work-in-progress, but the basic flows work well enough for my needs.

Screenshot of main Screech posting interface with form fields.
Screech interface before posting an episode of This Week in the IndieWeb Audio Edition

One fun feature of Screech is that once you select an MP3 file for upload, it uses the jsmediatags library to pull out information about the track, such as its duration, track title, album and artist info, etc. This info is outside the scope of the Micropub standard, but if you want to add support to your server, you'll see those properties arrive with names like "id3-title", "id3-artist", etc.

Edit, March 17, 2017 — Screech is available at screech.schmarty.net. If you'd like to run it yourself, add features, or fix bugs, you can find the source code and instructions on GitHub.

There are many TODOs yet on my plate for Screech before I'd consider it "done", such as micropub media endpoint support, syndication support, adding a photo to the post as a "poster" image, and more.

I'd love to hear feedback from the IndieWeb community! What do you think it means to be an "IndieWeb podcaster"? What features would make Screech useful for you?

byMarty McGuireMarty McGuire • posted archived copycurrent
Going to see if I can use this to make my own little 'net cast' on my site (or in a sister site).
I hope that new form of Indigenous is nice. I should try building it and running it for myself. I figure I'd have to learn Dart. I think I have language fatigue because learning Clojure, gaining proficiency in Rust, wrangling JavaScript and trying to not forget Python feels like a lot.

I don't know if I want my site to federate just yet. I do want to reduce the number of accounts that I would have to manage but there's still quite a bit I want to solidify on the IndieWeb front. I think I got Koype and Shock in a good place. Right now, I'd want to work on the social reader idea since that's the easiest thing to do (client-side wise). But I do want to start working on Webmentions, mainly on how to handle the filtering and the stuff I want for it.