william's blog

For those of you who missed it, Starship shut down on the 16th (two days late, whoops!). If you've still got data you forgot: don't fret, it isn't gone and won't be for another month. That being said, if you really do have missing data: please let me know now.

If you have no clue what any of that meant and what it has to do with Muzak, you don't have any missing data. If you're curious though, read my last blog post. Starship was a sort of open-source groupware-meets-social-network experiment that lasted 4 years.

Muzak

Right now, I have four things on my plate. If I had to break it down, I probably spend about 50% of the time I spend doing “work” on Muzak, 30% on my schoolwork, 10% on my game, Boing, and the last 10% on my responsibilities at the Linux User's Group.

Personally, I don't actually have a problem with this. But I'd like to be able to start working on the GPUI documentation I'd promised several times, and a couple people had expressed that they'd like to contribute to Muzak, so I've been cleaning up the code. The two goals have been to make the Muzak code easier to work with and to make it more reliable on more setups.

Here's everything I've done and plan to do in service of this:

  • Refactoring to use let ... else ... instead of let if when applicable (thanks AgentElement)
  • Improving Windows support (fb784c1)
  • Handling channel mismatches (1cb0b56)
  • Handling device destruction gracefully (195cbb3)
  • Improving documentation (in progress, partially complete in 7d1d479)
  • Implement graceful error handling (not yet done)
  • Do a general code quality pass on the entire project (not yet done)

I hope to have all of this done by the end of next week.

Muzak 0.1

My requirements for an 0.1 release are as follows:

  • All of the aforementioned work is done (so Muzak is stable)
  • #11 (Search should handle scan events) is closed
  • The final release and album listing views are in place
  • Track artists are tracked and the database is capable of upgrading itself to handle this
  • The mute button at the bottom of the screen ought to work
  • Muzak needs a better name – if you have any other ideas, please let me know, I'm terrible at names and don't want to name it YAMP.

The current release and listing views aren't generic: they can't be used outside of listing tracks in a release and listing albums in your library. Plus, they aren't that great in general: you can't change the sorting order in the album list, and you cant see track artists in the release list. My goal for 0.1 is that everything that makes it to the 0.1 release can stay for a while, so the track listing in the release view needs to be reusable by playlists, the album view needs to use a generic table component, and the usability of all of this ought to be a little better. Expect work on this bit to be started after the big refactor I mentioned before is done.

The mute button is simple, I just haven't decided if storing whether or not something is muted is the responsibility of the UI, playback thread, or the used DeviceProvider. It's not been fixed because I don't care much for mute buttons in audio players, but it's the first thing that almost everyone I've shown the player to has noticed, so clearly some people do care for them.

As for the other two, these are just the two things that are bothering me right now, and I'd like there to be less things that bother me in the stable release.

I hope to have a stable version of Muzak by the end of March. This isn't really a fixed goal, and I'm not sure I'll be able to hit it, but that's what I'd like to happen. The stable version won't mean that the latest release goes away, though.

Muzak 1.0

Obviously, 1.0 is a ways away. Everything in the README file's planned feature list should be done before 1.0 comes out, plus some smaller things like having a proper menu bar, the command palette, proper hotkeys, etc. I'd also like to do a design pass on the entire application, since there's some elements that I don't love but aren't a priority right now.

Post 1.0

I have some bigger ideas that cost a lot of money and require a lot of work and I don't have a job right now. One of them includes allowing you to losslessly stream files from your computer over the network to other Muzak users, so you can have a Spotify Jam type session but with music you made or something. TURN servers cost a lot of money, so don't expect that any time soon.

I also have a pipe dream of starting an open lyrics database (like Musixmatch), but I'm not sure of the legal feasibility of it.

GPUI Book

I really like GPUI. It's one of the best UI frameworks I've ever used, if not the best. I have a few complaints about it (image dropping and blur effects when) but they're mostly around it being pretty unfinished.

A lot of people use Muzak or Zed as GPUI references, and I'll be honest, neither are great references. Both programs have a lot of complex state and synchronization, and the Zed code base is massive. Most of what I've learned of GPUI is just pure brute force or from asking questions in the #gpui Discord chat, since the examples could never really cover the entire surface area of GPUI.

I see a lot of the same questions in the Discord server, so my goal is to cover the “basics” like Entities, Render vs RenderOnce, what the hell a “SharedString” is, and how to make an element (which there are no really good examples or documentation for but is actually really important), just to give you an idea.

I don't know when I'm gonna start this, because I already have a lot on my plate right now, but it's definitely something I hope to get the ball rolling on soon.

Boing

For those of you who don't know, I've been working on a game called Boing for a while. It's sort of a cross between Ricochet (the Valve game no one's ever played), Super Smash Bros., and Team Fortress 2, and it's been stuck in sort of development hell because I am (very predictably) incredibly unhappy with most of the game engine offerings right now. I think we're going to stick with this new version that I'm working on in Unreal Engine 5, though.

I haven't been making much progress on it lately because Muzak got much more popular than I thought it would much faster than I thought it would, and it's been my main time sink for a while. Once I get 0.1 done I hope to get a build out for play-testing (for those of you with access) of the new Unreal version, since the current Godot version is pretty deeply unstable. Unfortunately, starting the GPUI book comes first, so it'll be a while yet.

Starship is finally shutting down on February 10th, 2025. It's been a long time coming; the last update was over 3 years ago.

Why?

There are a great many reasons. The main technical one is that Ubuntu 20.04 LTS is EOL this year, in April, which also happens to coincide with when the domain renewal is due and I've since switched domain name providers from Namecheap to Cloudflare, since Namecheap isn't so cheap anymore (ironically).

There's also the clamp down on the free and open internet from the governments of several US states, as well as the UK. I can't afford to comply with any of the new Ofcom Online Safety regulations.

The others are more complicated.

Every App is An Everything App

Elon seems to think he's the first person to ever come up with the concept of an app that does every single thing you could ever use the internet for. This was the goal of every single major internet corporation 10 years ago, and it's now coming back in to fashion, as things tend to do. Discord's doing it too, so is Reddit, and Instagram, and Facebook (again). I suppose the logic is “the bigger the app, the bigger the profits”, but every time this has been tried it winds up being that liability and losses scale rather well with app size but user counts don't (since they're already using the damn app in the first place), meaning you don't actually generate any extra revenue.

The problem is that these apps have large user bases that are already commited to them, so while they're off screwing themselves over, the impact on the industry winds up being that they screw everyone else over, until the big companies have screwed themselves over so hard and so many times that everyone just gets sick of it and moves (à la Skype, MySpace, etc.) to a different platform. This usually coincides with a major economic recession. Surely you see where this is going by now. right?

The goal of Starship, as far as actual strategy goes, was to be ready for when this happens. It won't be now.

For the record, Starship was never meant to actually be an “everything app”. Reddit, X (ew), Facebook and co. seem to want you to be able to do literally anything on your website, but I'm not going to Facebook to look up the timeline of the Chernobyl nuclear crisis, I'm not going to Reddit to chat with my friends, and I'm certainly not going to Twitter to get a job. I don't think that trying to make your app do everything is particularly productive. Instead, the goal of Starship was just to give people a place to upload, write, and share what they wanted to, how they wanted to do it. I've grown pretty tired of this whole homogenized post-Web 2.0 internet, and I'd really hoped to give people a place to actually express themselves.

In service of this goal, the scope for Starship had ballooned way out of proportion.

Scope Creep Hell

When I decided it ought to be time to give up on the whole thing, the actual plan for Starship was to create, in essence, the most advanced website builder ever made. The goal was that you could create every component in the current version of Starship, to their current standard, using a component editor. The actual page editor would be similar in both flexibility and functionality to Figma. You'd be able to write backend code using a Scratch-like block system, or, if you wanted to, as actual code. You wouldn't have to do any of that for most tasks though, thanks to a drag and drop data connection system that would generate endpoints for you – allowing you to drag data on to text and image blocks, create auto-updating lists, and upload the results of forms. All of this would be backed by a custom hybrid markup & programming language.

I still think this is all an excellent idea. This would allow almost anyone who can use a design program to create 90% of CRUD apps without writing any code or considering any of the typical scaling and logistical concerns.

Clearly though, it is too much work for one person.

The End

I began prototyping all of this in late 2023. By then, I had worked out most of the workflow I'd be exposing to the user and how it would all be presented.

By May of 2024, I had stopped working on it completely.

It had dawned on me that, while I have the skills and knowledge to do all of this work, I really don't have the time. At the rate it was taking me, it'd have taken maybe 7 years to get to a place where it was fully functional, well-tested, and reliable. I'd hoped to have it done by the end of this year.

In August, I started working on my music player, and I realized that I rather liked working on projects where the weight of the world wasn't on my shoulders. This realization resulted in the end of a great many things, which included the final nail on the great Starship coffin I had accidentally built for myself.

In December, I officially announced that Starship would be shutting down in February.

What's Next

I've started hosting most of the services I was offering (or planning to offer) with Starship in other ways. That includes this blog, which I'd been meaning to start for years but never had because I figured that I would add it to Starship at some point.

At some point, if I find anyone willing to work on the concept with me, I'd like to revisit the concept I had for the new version of Starship. Right now though, my focus is on my game, Boing, and my music player, Muzak. They're easier projects, and I actually have any hope of shipping them.

As for the current version of Starship, I considered revisiting it or finishing the in-progress rewrite. Neither option really made any sense – I don't see the concept really going anywhere, the rewrite is a lot of work, and most of the code for the current version of Starship I wrote in high-school and in my first semester of college. It's not great.

If you're left with no where to go after Starship shuts down, please DM me. I can't promise anything, but I do hope to provide most of what I'm offering right now with Starship to most of the people who used it. My goal for this Writefreely instance and the Nextcloud instance is to start writing themes (which I hope to open source) to improve some UI/UX sore spots in both applications. Eventually I want to make an OAuth provider for everything, so you only need one account, but that's held up by the Matrix server we're using, Conduwuit, lacking support for OpenID Connect.

Thanks for all your support through the years. I probably wouldn't be around if it wasn't for the warm reception of Starship by the ELO community, so I truly am thankful.

So long, and thanks for all the fish.