I guess I'm wondering if every Mastodon server also has some non-ActivityPub API.
Systems are made of parts.
If you have too many parts, the odds of one of them failing go up.
If you have too few parts, any single part failing has a larger impact.
THEREFORE,
Arrange the parts in multiple phases over time. Like bulkheads, failures get isolated to a single phase.
Within a phase, use few parts to improve your odds.
Example: use git to generate your site, but host it on Netlify. Now you can build without Netlify and serve traffic without Github.
I wanted to give the kids a Paint program, so I did a quick Google in my current favorite framework and found https://love2d.org/forums/viewtopic.php?t=87469. Ran great and was loads of fun, but looked a bit.. off. Some of the colors were missing, and clicking on the black rectangles sometimes abruptly changed the color. Turns out:
“In versions prior to 11.0, color component values were within the range of 0 to 255 instead of 0 to 1.”
— https://love2d.org/wiki/love.graphics.setColor
Before:
After:
I'd always felt bad that my Linux-only programs excluded Windows users. But I didn't realize they were excluding me as well. In this way I come back face to face with the oneness of all things.
Is this Mu or Teliva?
So now they know that there are other programmers on the planet.
Software benefits from testing. If you use software with few users, it's almost certain to be under-tested.
I also can't just ignore all the considerations of industrial software.
I can't just do it from scratch because I don't have all the skills. Deciding what to depend on is also thorny. Pulling in irrelevancies vs excluding people.
5% of software lasts a long time. (Analogy with food breaks down there.) Hard to tell which 5% it is. (Analogy with building roads/bridges breaks down there.)
If I were to ever have any success, I'll be dealing with awkward requests, the risk of burnout.
One thing is clear: the dream/temptation to "scale up" is poison. But it's unclear what's left. We end up with a few people scattered in a humongous state space mostly building stuff for ourselves, nibbling at the margins of the software industrial complex, while unable to actually extricate ourselves from it.
You can have both kinds of software, the kind that's unreliable because the authors are indifferent/malicious or the kind that's unreliable because the authors don't have enough support.
[1] https://www.gwern.net/docs/technology/2004-03-30-shirky-situatedsoftware.html
[2] https://www.robinsloan.com/notes/home-cooked-app
https://escapingflatland.substack.com/p/christopher-alexanders-architecture
using fork() and pipe(): https://www.cs.dartmouth.edu/~doug/sieve/sieve.pdf
in C using tasks and channels: https://swtch.com/libtask
in Lua using tasks and channels: https://github.com/majek/lua-channels/blob/master/examples/sieve.lua
in Python using a more efficient but less interesting algo because Python lacks full coroutines: https://github.com/majek/lua-channels/blob/master/examples/sieve.lua
It might be fun to try this in Wireworld.