Really I'm of the view that a hard fork of mastodon is (probably) not the right solution, but it's likely my view on that is for different reasons than a lot of other people who have talked about it (and also substantially similar in some respects, but with some core differences).
But if you want to do the work and it energizes you then go forth. It just seems to be more hassle than I suspect it will be worth versus just building a ground-up implementation (which is already plenty of work).
@hrefna@jenniferplusplus if this were a work conversation (rewrite vs investing in maintenance) i would push strongly against rewriting, esp if our metric is “amount of hassle to functioning product”
If this were a work conversation I would be advocating for forking Akkoma or Misskey or contributing to an effort like Letterbook (or just flat contributing to Mastodon or maintaining a soft fork), depending on what my specific goals were.
Further both the reasons for that development and the funding model around that development would look quite different than what people are talking about here.
@hrefna I strongly agree (obviously). But, if the goal is to move existing servers, a fork seems like the only viable path. Unless someone has a budget for a whole engineering team just waiting to be spent, that is.
@jenniferplusplus Overall I tend to think that the migration ease is transient, while the tech debt is eternal.
Over time the mastodon schema is going to change and all of the proposals I've seen drifting around require major changes to the protocol and/or schema, so you still end up with a messy migration down the road (and no extension registry or versions)
There's a middle ground that's a sweet spot, of course, but unless people all move almost immediately the benefits start to go away fast
@jonny I mean it depends. If your goal is to be effective it is probably the worst strategy, because your time is finite. If it is to have fun or learn a lot that might inform a more effective solution in the future, then it's a great strategy!
@hrefna A big pro for hard fork is that migrating data isn't an issue. Forking a large code base definitely has it's issues, but I can see data migration as a sticky issue.
@LovesTha That will only last until the hard fork has schema drift, which is very unlikely to be detected organically unless that is one of the very first priorities.
Maintaining ETLs and ensuring they won't break when you are only in control of one side of the ETL is PITA.
It's not impossible, but any ease of migration has to be a top class priority or you are going to lose it, and that's assuming mastodon doesn't want to deliberately make it more difficult to migrate in the future.
@LovesTha Further, most of the features that I've seen people talk about will require or strongly encourage incompatible schemas. There's going to be loss and complex migrations, and if safety and things like solid reply handling are goals then I'd speculate it will be an issue sooner rather than later.
So it goes back to goals
If your goal is to have fun on a research project that might go somewhere, it's a great idea
But if it is because data migration is easy that's only true temporarily
Add comment