My old assumption about my “multiple independent but integrated apps” theory was that the apps had to do a ton on their own. I was thinking of it mostly on a technical and individual product level: divide the apps into totally separate packages that don’t really need each other.
This assumption is proving false when I consider the overall suite design on a user level. For example, we have Write.as for writing blog posts and Snap.as for photo hosting — separate apps that work well independently and together. But while this means we can do interesting things on a per-product basis — like photographer profiles exclusive to Snap.as — the separation can be frustrating when you need to use the two together, like when I’m composing a Write.as post and need to insert photos. In that case, I can either switch apps or use the Snap.as browser extension — but this is still too abstract for many users. We need a different level of abstraction.
So I’m working on that now. For example, coming soon to our Classic editor: inline uploads, powered by Snap.as:
I was aiming to have made some progress on Remark.as by this point in 2021, but as tends to happen, other priorities took over — namely, some large migration projects that have spanned several months, some long-standing bugs that have grown too painful, and the continual waves of various SEO spammers from around the world.
I recently shared that the timeline on it is indefinite for now. But the topic got me thinking about it again in spare moments over the last few days. Coming at it fresh, with a “weekend project” state of mind, I came to a new design that basically resembles a link aggregator site like reddit or Hacker News.
This was what I imagined for the “social space” — basically, you head to Remark.as when you’re ready to read comments and shoot the shit with other people. Discussion happens around links back to the original content, rather than hosting the content on Remark.as itself; a close integration with Write.as means we could automatically “post” your articles over there, and we can dynamically link from your blog posts to the discussion, e.g. showing the number of replies you’ve received. Overall, of course, the goal is to keep the social space separate from the composition and publishing space. And I think with this design, for those who want a more social atmosphere, Remark.as would replace Read Write.as as their daily destination.
#remarkas #design #ideas
Yesterday I made some progress on general #WriteFreely maintenance. Reviewed some pull requests, added some quick fixes, and moved the repo on GitHub, as announced. I also figured out what was causing the “availability issue” — just some too-tight restrictions we recently placed on the API.
Just updated our demo WriteFreely instance to the latest on
develop (thanks @email@example.com for the reminder!). If you want to try things out, you can create an account with this invite link, valid for the next three days: https://pencil.writefree.ly/invite/VTDTcP #WriteFreely
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.
I also came across the Malleable Systems Collective and the people related to it, and finally looked into Solid after hearing about it for so long. Plenty of things to think about…
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 @firstname.lastname@example.org) 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 @email@example.com 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.