MASTODONMUSIC.SOCIAL HAS BEEN SHUT DOWN.  THANKS FOR ALL THE FISH.

The  old domain for this site was https://status.mastodonmusic.social and the new domain for this is https://mastodonmusic.stevetures.com.  What's listed below the line break is an archive of what was discussed, just in case.  Keeping it around is basically free so might as well.  But it's all basically anachronistic as the server is gone so migration options are no longer possible.

Here's a handy list of music-oriented mastodon servers to browse or join:

• https://musicworld.social/

• https://musicians.today/

• https://musician.social/

• https://bostonmusic.online/

or check out other servers to join at https://joinmastodon.org/servers or https://instances.social.

---

July 2024 - I've decided to shut down mastodonmusic.social on 20 Oct 2024 (date per Mastodon covenant guidance).   This should give everyone time to go figure out what they want to do with their data or give everyone a chance to migrate elsewhere.

Options

1. Migrate to another server. 
   
   

   1. Pick a server. The Mastodon application supports moving your info and data to a new location, which is pretty neat.  There's a raft of great well-run servers now, with nice communities.  Take a look at https://joinmastodon.org/servers or https://instances.social/ if you want some ideas on where to move.
      
      

      1. For musicians, https://musicians.today/ or https://musicworld.social/ or https://musician.social/ are all good alternatives.
         
         

   2. Create your account and make sure it gets approved if needed.  Then add your current  account@mastodonmusic.social as an alias at that new server.  I think you also have to make an alias of the destination one at your source account too?  Mine was a little fiddly until I had aliases for each account on both sides (i.e. alias on destination for source, and then source for destination).  Also do note that it's probably not a good practice to either reuse your password from one site to another, or to type your source password into your destination server, which shouldn't be necessary anyways.
      
      

   3. Head to https://mastodonmusic.social/settings/migration to provide mastodonmusic.social with your new  Mastodon account name in the format account@server.domain .
      
      

2. Download your data. 

   1. You can do that in the Import / Export section of preferences on the server.  https://mastodonmusic.social/settings/export 
      
      

3. Do nothing.  All this migration stuff is optional, though do note that once the server is down, migration options will no longer be available.

Reasons?

Well, I'm happy to talk about them.  None of them are catastrophic, but they aren't what I would consider to be reversible. In other words, with respect, I'm not really open to debating these, but just leaving them here for historical reasons.

1. Mastodon is pretty messy to administer.  It's a delightful hodgepodge of F/OSS technologies, which, ah, really takes some getting used to.  Package hell can happen if you're not careful or you don't know what you're doing with your underlying OS.  If I were to do it again, I'd probably do the docker version rather than running directly in the host OS's root partition (err well you get the idea).  Every update is sort of a nail-biter as you worry you're gonna blow up something or that your backups, while they exist, aren't very well-tested.  I'd probably very consciously set up a dev and prod instance if were to do it again, though that means more money.  Also cost, wow $200+ a month on GCP, which is nicely available and comes with G's nice legal team to make sure that frivilous search requests are turned down, but wow also pricey.  I can afford it, but this morning I found myself asking "why though"...
   
   

2. Doing it right means finding at least one or more other persons to trust.  For this instance, it's always just been me rather than put my users at risk of someone I don't fully know having access.  But if something were to happen to me, you all would be stuck, floating on a sinking ship with no security patches, no backup, no restore, no one paying the bills, etc.  It would go badly pretty quickly. There's some moderation tools for allowing trust, but as for actual sysadmin work, you really have it being all or nothing on finding someone you trust both technically and morally, as well as have the time and inclination to help.  I personally have a high bar for all of this trust, and so I worried a lot about the bus factor on my instance.  I had friends who probably meet the technical and moral bar, but are busy people who already voiced their concerns just with the generic idea of owning a mastodon server.  All the technical, moderation, administration, moral and legal questions are pretty hard to ignore.  I basically just did it anyways and ignored parts like the technical (timely patching), moderation (wow moderating trends is a PITA and I didn't want to come up with fairness standards for topics, so basically didn't even do the work) and legal (do I register with DMCA?  what do I do if someone sends me a legal letter?).
   
   

3. Probably the happiest reason for this is part of why I started this instance, was that the Mastodon community was in bad shape in late 2022, and it was particularly bad for musicians.  There wasn't instance that was functional that had the string "music" in the server name, which is what made me say "well dammit, guess I'll have to make one".  Additionally, all of the popular instances were melting, and I felt like helping out.  These days, things are a lot better, with shared moderation lists to ban terrible instances, better guard against spammers, regular patching, more people than just Eugen working on Mastodon (!!), great moderators, well-run large instances, integrations with other services like Threads (for better or worse, I do hope they figure out what to do around moderation to make sure that Threads doesn't spoil the party once Threads users show up on Mastodon post / comment pages) and many many more things that are legitimately great.  So I'm glad things are a lot better than they were 1.5 years ago.
   
   (Also, get rekt Elon.  While Twitter/X isn't gone, it sure seems like a spammy heinous wasteland with plenty of terrible people making the service bad every day.  Turns out being terrible to others is bad for business, who knew?)

So there it is.  Take care, and should the need and the motivation ever arise, I'll be here to help pitch in and do what I can for musicians.  Musicians have had such a shitty run for the last couple decades, even with so many people loving and depending on music in their lives, I hope the world gets back to paying musicians fair amounts, and that touring endlessly isn't the only way for musicians to survive.

Just for future, if you need to contact me, I'll still happily be on Mastodon: https://mastodon.online/@stevetures

29 April 2023 - Blog Post

State of Mastodon Music

Been a while since I wrote down my thoughts on things. So here's some stats. 

• We're at 155 active users.  If one's comparing it to the below stat, instances.social says we have 386 users, so we haven't technically lost a couple hundred users, and still what I would describe as growing at a normal rate.  It remains a good mix of musicians, ~independant record labels, and music fans.  We're held this trend for about 2-3 months at least without things slipping one way or the other.

• Moderation.  Thankfully this has been very light on duties.  Since starting this, I've only had to handle 6 reports, where the root problem was invariably a blatant breaking of the server rules (spam, not labeling NSFW properly, etc) usually by an account on another instance, so suspending that user's behavior on mastodonmusic was an easy call.  I also caught exactly one programmatically generated account using a very supicious mail server that permitted temp email addresses, and dealing with them was trivial.  So far so good.

• Technical Updates.  Haven't had anything particularly earthshattering happen there.  Each updates has been preceded with a dump of the db as well as archival snapshots of the disk juuuust in case.  I don't feel particularly compelled to rock the boat yet with a technical redesign of the site as it remains responsive and reliable.  I have alerts for paging me if the site is down for 5 minutes and I believe the only time it paged was the huge 3.5.3 -> 4.0 update that took a few hours to complete (see previous post).  Things seems stable.  A huge rush of users could change that.

So, again, how can you help?

The costs are quite stable month-to-month, so I don't feel compelled to request donations.  What I'll continue to say is that, if you can afford it, please consider using any donation money you would have sent me instead on buying an artist's physical or bandcamp release or some swag or a concert ticket at a worthy small venue. Go do it right now, so you don't forget. 😉

I'm lucky to continue to be in a place where I can pretty comfortably afford the $140USD/mo that this site and the translation service costs.  Rearchitecting the site might reduce the costs in some way (cheaper storage and db), but also raise a lot of concerns that might lead to site performance issues for actions like the typical media cache cleanup operation, or for basic searches for users.  So again, for now, no change.  If something happens to birdsite or my own income, or some popular music celeb appears on our site, then I'll let everyone know how we're going to end up dealing with things and commit to sinking a weekend into some migrations or standing up a way to enable donations.

19 Nov 2022 - Blog Post

Well, it's been a wild 2 weeks of owning Mastodon Music.  I'm glad I started it, and it's great to get exposed to a whole range of music and music lovers.  Being a musician in the internet age has some mild upsides (easy to promote and share) but also some huge downsides that I think have really stressed musicians and the industry quite a bit.  The somewhat-forced move to streaming and away from album purchases has lead to career musicians putting out albums sometimes as loss-leaders, and has often necessitated that musicians have to go on tour for all but the most widely streamed musicians.

Summary, in case you're in a hurry

I'm happy to have Mastodon Music stood up, and I'm thinking about the future with some technical and admin challenges that a project like this presents.  In the meantime, I want this service to stick around and am grateful to be in a position to make that happen.  But if you care a lot, have a read.

Background

With that guy taking over Twitter (don't need to mention his name, we all know who), things have gotten that much worse for musicians.  When I thought about conciously leaving Twitter, I started to delete my music project's account, and turned around and went to find a music Mastodon server... and I was surprised that the options weren't readily obvious.  I know now that there's a few good choices (musicians.today / raveclub.nation, maybe others that I'm forgetting), but the only one I could find then was an Italian instance that had closed registrations.  As for myself, I'm lucky to have a pretty good day job in the tech industry, which personally creates a lot of tension, so I look for ways to help.

So I thought I was lucky enough to have some of the knowledge and comfort with tech and the means, and without thinking too long about it, I had acquired a cloud VM registered the name and set up mastodonmusic.social over the course of a few hours.  Almost as soon as I published the existence of my site to https://instances.social directory, people were signing up, so I guess I wasn't alone in hoping for a musician or music-lover-friendly instance.

Where are we headed?

So far, I would say things are going pretty well.  I'm not through a steady-state billing cycle yet, and probably wont be for another month, but it looks like Mastodon Music will cost about $100/mo to maintain for now, without having someone like Taylor Swift drop in and destroy the server with traffic (see below on exactly why this might be a problem at this moment).  ;-)  If I'm being blunt, I can manage that and none of this is a stressor for me.  So if you're looking for a Patreon right now, I probably won't have one, at least for probably a few months.  If you were thinking of helping me, instead go check out other local posts on the server and buy a record or two from someone you're loving.  That said, I also see some challenges for this server that I want to get ahead of.

• Scaling and Availability (technical and non-technical)

  • Technical bits. The default Mastodon deployment is intended to just run on a bespoke machine in a datacenter or house and maaaaybe serve 300-500 users (some handwaving), and this is running in a VM that's about that size.  The good news is that if we suddenly start running slowly, I have a lot of room to bump up the speed and capacity of this machine, but it's not a trick I can keep playing, and it's an expensive trick long-term.  But the good news is that my provider should never lose any of the data, and I take regular snapshots, so the odds of something wiping the data without recovery are really really low (nothing's impossible, but something that will almost certainly never happen).

    • The default webserver is nginx, which would require me to learn how to put that behind a VIP to scale that, though that's just an assuming as I don't know how that mitigates user session info between instances, but... I'm sure there's a way.  The database (posts text, user info, pretty much everything that's not media) is a single-instance PostgreSQL deployment on the same machine.  Not ideal for scaling.  Moving this to a cloud DB is the scalable thing to do, but it's not done easily or cheaply.  A local-disk dir handles all the media, both locally created and also posts from other servers that Mastodon Music users subscribe to.  This grows... a lot more than than the database.  Also there's some ways that Mastodon shards out tasks, like publish posts to other locations or handling incoming posts for people to read, etc that aren't quite low-hanging fruit, but it'd be interesting to see if I could run those in a more efficient way or even on other VM instances.

      • Side note: there's a basic prober test that runs on this site, so I should get SMS messages should the site ever go down for some reason.  :)

      • Logo note: the person who did the neat logo is here.  I can't claim to have amazing graphic design / illustration skills. More samples, including some unused ones, here.

      • Note: my day job is a little more IT and some light software engineering, but less so on the own-a-website sort of problem area.  I know a bit about this space and some of the basic failures to avoid, but I won't claim expert level knowledge that someone deep into their SRE career might have.  Tips on all this welcome.  :)

    • Lastly, and probably worth saying out loud, I don't personally scale.  I have x hours in the day to work on this, which is sometimes zero or close to it.  I'm a parent and I have a family and some other responsibilities to the world.  But I'll try to prioritize this for now.  But really it's just up to me at the moment, so I'm going to go through and write a Disaster Recovery doc to share with a few work friends, who, to be clear, haven't actually volunteered to help. People in my industry unfortunately have full knowledge of what owning a site like this really means (interacting with bad social media actors, needing to moderate and also needing to deal with whatever responsibilities might be required to be performed to maintain a site like this, no clear revenue stream to ensure that this gets paid for beyond me funding it and keeping my job) though I could at least say something like "you're not on the hook, but should I suddenly become very unavailable (illness, etc), could you work with volunteers here to keep things moving?" and having that Disaster Recovery doc would really help smooth the amount of effort needed and thus make it more palatable for some to volunteer to help with.

  • Non-technical summary of the technical bits. There's a few different ways and projects I'll likely be taking on to get this server to a place where it could handle more user signup influx.  It might even handle a few persons signed up that might drive a ton of traffic (read: what if someone famous very visibly signs up here.  I think I could be ready to deal with it, but I'm not positive with where things are right at this second).

How Can You Help?

So that's probably more info than most everyone needs.  I'm not yet ready to onboard volunteers purely because I'm not yet ready to trust anyone with this project yet.  To be blunt, there's a lot of power that comes the moderator / admin and also access to the VM, and I need to figure out some safe ways to trust others with that eventually.  But, if any of this resonates with you (tech comfort level, any SRE work done in the past, and an interest to help and maintain the moderation / rules structure that exists today), please DM me at @steve@mastodonmusic.social and we can at least start talking about this space.  Again, I'm not comfortable yet granting any wide access to anyone that I don't know and trust extremely well, so for now I'll be running things. I think the last thing that musicians need is more drama or any loss of data or access on their social media.   But I recognize that I'm a single point of failure, so I'll at least do what I can to ensure this service is running for as long as possible or needed.

Thanks,

• @steve@mastodonmusic.social