Doing some #WriteFreely maintenance today, merging long-standing pull requests and fixing some bugs. I'd like to wrap up a v0.13 release this month, ideally. Yesterday I put things in place to support “allowed” apps on the API, and today I need to look into some apparently availability-related publishing issues.
Part of what always excited me about the #fediverse was the chance to see all kinds of interoperable social apps. It fit well with my own idea for “a suite of independent, but connected apps” that I started building with Write.as and Snap.as.
Today I came across this talk, A World Without Apps, and it got me thinking beyond my own collection of composable tools on the web, to all levels of the computing stack. Providing that kind of environment everywhere of course will be pretty involved, but I can already feel it changing my thinking toward the tools I’m making.
Even certain basic concepts of my software that I’ve reused across apps, like “collections” and “posts,” could be used as elemental pieces that users could then combine and piece together however they want. I’m thinking about how I could build a tool that uses these elemental pieces to make brand new tools, and build my suite of apps and experiment with new ideas even faster. Then other people could do the same, and instead of only ever getting a single “official” version of WriteFreely, for example, you could build your own WriteFreely entirely the way you like it. In this way, WriteFreely as a piece of software becomes less of a wind-up toy, and more of a real tool you can use exactly how you want.
Thinking again about Public Bio, a Linktree-ish site builder I started working on in mid-2018. When I left it, it supported a single user and could generate a static site. I had started making progress toward multi-user support, but didn’t quite finish.
Since then, we released WriteFreely (a much larger open source project) and worked out the details of shared / standalone add-on apps for Write.as, like Submit.as. So as I’ve played around with Public Bio again, I’ve started incorporating everything I learned there. Now I’m building it with a common interface that will enable you to run it either as a standalone multi-user app, or as an add-on to a WriteFreely instance, where your users might already live.
This is exactly how Submit.as, Snap.as, and our other apps are built — as standalone Go libraries whose data can live alongside our core WriteFreely data. This way, we can turn each one on or off independently from the others, and serve them wherever we want. You can start up a single application server on its own, or incorporate it into a larger application.
This furthers my long-standing idea of “independent, but connect apps,” but will also mean that anyone else can launch their own suite of blogging, and linking, and other services, depending on what they want to offer their community.
Came across searchmysite.net (made by @email@example.com) the other day, and I’ve been thinking about launching an instance for Write.as. Basically, it would be your standard “search engine,” but only include results from “Public” blogs hosted on Write.as. Then as a user, you’d know you’re always getting some kind of personal writing / non-clickbaity results when you search there. It wouldn’t replace Google, but it might be the first place you go when you want to read something new and interesting.
It could even become the official search engine for Read Write.as — you’d search for topics you want to read about, essentially. And if it had an API, we could leverage it for a Write.as search feature (since it’s already indexing everything), to let people search their own blogs.
As I recently mentioned on the forum, we’re currently dealing with a pretty big influx of SEO spammers. That is, we’re dealing with a ton of automated activity from a small number of human actors.
Of course, countless web services have been through this. You might want to build a signup-free app so people can use and try it quickly — but if it can be used to create content on the internet, it will be abused. You might want to offer user accounts without email registration so people can preserve their privacy — but if that account grants more abilities to create content on the web, it’ll be abused eventually.
I find it amusing that we’ve slowly ended up just doing what many other services do, over our six years. But that doesn’t mean I think we should always pre-optimize for abuse, and avoid building software as if we were in an ideal world, devoid of spammers.
Our platform has attracted its own kind of spam, and I’ve gotten to know it well. So over time, we’ve been able to carve out and mitigate it, while still maintaining those user-friendly and privacy-preserving features I always wanted. Sometimes we get a little heavy-handed (such as with IP bans), just because it’s expedient at the time. But no matter what, moderation actions are easy to undo, and we keep a human around to quickly fix any mistakes — overall, I think, a decent balance.
I wrote my last post on @firstname.lastname@example.org entirely in the new Classic editor, and I’m very much a fan. The writing wasn’t inhibited any more than it is with the plain text editor, but I did find myself casually emphasizing things much more, since it’s just a Ctrl+I away. I was also consistently happy to not have to type out syntax for a Markdown link.
Soon we’ll start including images in the ActivityStreams data that #WriteFreely sends out to the #fediverse, making it so they show up nicely in your favorite decentralized social media stream. This should make WF more useful particularly for photo bloggers.
Here’s what it looks like on the receiving end, in my Mastodon feed:
This should be deployed on Write.as soon, and will be in the next version of WriteFreely (your code review, testing, and feedback is welcome!).
Yesterday I was thinking a bit about Web Monetization, and how it’s a little less ideal for written content than, say, video content. Whereas someone might skim or skip through an article, cutting their time on the page short and thus WM revenue, it’s much easier to passively watch a video.
Later in the afternoon, the thought occurred to me again, and of course it’d make sense to support WM on our own visual platform, Snap.as. So now (well, launching soon), for any blogs with a monetization pointer on them, their equivalent Snap.as profile will also include that monetization pointer.