busybee fluffy rambles Notes

I agree that this is a massive pain point and it’s something I’ve talked about a lot on this blog.

At present, I use a combination of 1 (via isso) and 4 (via webmention.io + webmention.js). The integration on 4 is also helped by using Bridgy and Bridgy Fed to receive webmentions from Mastodon and many of the silos, which strikes an okay balance for me, although it’s far from perfect.

One of the biggest problems with webmention, IMO, is that it doesn’t provide a good story for protected/private responses to protected/private entries. Ticket Auth might eventually provide that, but adoption of that protocol has been slow-going, to say the least, and there’s still open questions about how to actually manage the credentials in an unsupervised flow (especially when using a third-party webmention endpoint). An older WIP called AutoAuth had a much better story for that use case but the protocol was incredibly complicated and implementations never progressed beyond the proof-of-concept stage.

For me, isso as my primary comment system remains the least-bad option of a lot of bad options.

how the fuck was this amazing parody of 2020s tech trends made in 2013

Pretty good overview of the current social media landscape, especially with how it relates to journalism.

Based on their literature, Paintbrush provides a $50,000 loan with a very low-friction application and a fast decision. But the total repayment amount can be as much as $75,000, tied to a personal founder guarantee. That means that if your startup doesn’t work, you as a founder are required to pay that amount back at an amount pegged at 15% of your pre-tax income. For example, if your total income was $150,000, you would pay back $22,500 a year. That amounts to around 22% of what your post-tax takehome pay would be before payments like health insurance and rent.

So basically this is all of the downsides of traditional VC with none of the upsides. Yeesh.

In traditional VC, it’s the investors who are taking the risk of funding the company. This scheme is doing none of that and is instead what amounts to a payday loan.

A great little rant about how “better than nothing” isn’t really the right frame of mind for considering ChatGPT et al.

Had you ever considered just using history rewriting in git itself?

Ben Werdmuller posed a question:

If your company gives its employees a space to blog or journal internally, what platform do you use? What do you think of it?

eg: Confluence has blogs; at Medium they have a whole internal version of the site called Hatch; etc.

Back in the day, Amazon had an internal Movable Type site for internal blogging purposes, although it went mostly unused. When I returned for a couple years in 2012 it was still there although even more completely unused. I posted a couple more entries on it that nobody saw as far as I know.

Nowhere else I’ve worked has had formalized internal blogging (although a couple places had public blogging platforms that were mostly used by marketing folks), although a lot of people certainly would treat Slack as their personal blog.

The core need being expressed by millions of users isn’t “get me a decentralized protocol that nobody owns where I can have my choice of algorithms and apps”. It’s “get me a platform that works consistently, with less abuse”. Sometimes it’s also appended with, “where I can build a following for me / my brand / my employer and measure my progress.”

[…]

Many of us have been wanting decentralized social networking for a long time — I’ve been a part of these conversations for around twenty years. It’s tempting to feel like people finally get it. But that’s a trap and a mistake. As always, quite rightly, most people want something that works for them.

Reminder that Usenet has been around since the 80s and was a toxic hellhole even then. Decentralization isn’t the answer to social media problems, it’s just an implementation detail.

Or, as I keep on saying: The problem with Twitter isn’t that it’s centralized, but that it’s Twitter.

Yes, Publ supports TicketAuth for authenticated feed subscriptions. At least in theory. It passes manual testing and I think a couple of folks have implemented test consumers that have been verified to work with it, but I don’t know of anyone who actively follows my blog with a TicketAuth-enabled feed reader.

My feeling with how Microsub would interact with TicketAuth is that the ticket endpoint would be responsible for relaying the bearer token along to the Microsub implementation, perhaps via some sort of credential store, or maybe that the token store would be expressed by the Microsub endpoint. I haven’t super thought it through, mostly because there’s a couple of reasons I’m not a fan of Microsub and if I ever get around to implementing the reader I want to implement I was planning on it just being a fully self-contained application that you happen to sign into using IndieAuth (it could support Microsub as a data store for other reader clients but it’d be intended to be used as its own client as the primary interaction model).

Or I guess another way of looking at it is that the reader I want to build would be a reader UI, Microsub endpoint, and TicketAuth endpoint all in one single integrated implementation, just because it feels easier in terms of how I want stuff to work.

The big security concern with TicketAuth (or any authenticated feed mechanism other than private/individual feed URLs, which has its own set of problems to contend with) is that as soon as anyone has any credentials for a feed that multiple people are subscribed to, you need to make damned sure that you’re retrieving/parsing/storing the feed separately for each credential. It’s for that reason that I haven’t just hacked TicketAuth into Feed-On-Feeds, because its fundamental design would make this rather inconvenient.

This article raises some good points, but there’s another reason I’m not all-in on Webmention: comments on private posts.

Post privacy is incredibly important to me, and supporting webmention on a privacy-post context requires that the comment (and notification thereof) be visible to the receiver’s endpoint, without it being visible to the world at large. This is okay with “unguessable” private URLs, but if you are doing a login-requred thing you start running into issues where you have to either let endpoints through to see the data (which means that any bad actor could also do the same), or you need the endpoints to support the authentication protocols (via e.g. AutoAuth or TicketAuth), and given how difficult those have been to get any meaningful adoption, I’m not terribly optimistic about that changing any time soon, especially with how many people farm their webmentions out to webmention.io which isn’t really in the business of managing things like authentication tokens.

But also, if you live in a world of webmentions for replies, that also greatly increases the chances that someone’s reply will be accidentally posted in public. I already see enough issues where friends will reply to my unauthenticated “stub” entries on Mastodon, rather than posting native comments onto my blog.

The more I get annoyed with Internet comment mechanisms, the more I think that email really is the way.

I removed Feedly from my Get Blogging resource for people who want to read and write blogs.

If you’d like to read blogs, there are some great other feed readers recommended in the list. I start every morning with Reeder and NewsBlur.

Molly White has written a great summary of why I can’t endorse Feedly anymore:

In a world of widespread, suspicionless surveillance of protests by law enforcement and other government entities, and of massive corporate union-busting and suppression of worker organizing, Feedly decided they should build a tool for the corporations, cops, and unionbusters.

I cannot support union-busting in any form, and it’s very disappointing to see a tool like Feedly attempt to capitalize on corporations who would like to engage in this activity. So it’s gone from the list, and I’d like to suggest: while they offer this product and cater to this market, please don’t use Feedly.

Personally I’m still a fan of self-hosting Feed on Feeds, which is pretty straightforward to do if you have even basic PHP webhosting. It isn’t the fanciest thing but it’s reliable and won’t sell your data to others, and it’s got the exact UX I want in a reader app (YMMV of course).