I write articles and interview people about the Fediverse and decentralized technologies. In my spare time, I play lots of video games. I also like to make pixel art, music, and games.

  • 36 Posts
  • 43 Comments
Joined 7 months ago
cake
Cake day: November 30th, 2023

help-circle
  • I wrote a counter-point to this a while back: https://wedistribute.org/2024/05/forking-mastodon/

    I’m not saying “don’t do it”, but realize that the amount of commitment required to make a hard fork even moderately successful is vast.

    It’s telling that the biggest project in the space is barely able to pay more than a handful of people to work on it, and it still develops at a snail’s pace. Notably, those are the people who deeply understand the system and its internals. While it’s not impossible, you have to be realistic about how much further a group can get when they don’t have the insight or technical chops required to take development further.









  • I can’t tell whether this is serious or sarcastic 😅

    As far as the “global square” part of the equation is concerned: yeah, you’re right! A firehose of public statuses requires indexing to work, as a basic foundational premise.

    However, there’s nothing preventing someone from standing up a PDS, opting out of the firehose / big graph service, and instead leaning on federation between individual PDSes. I’m not saying it would necessarily be a common use-case, but it’s definitely not impossible.


  • It’s a different approach with different ideas. It uses open protocols, focuses on data and account portability, and incorporates peer-to-peer concepts in its architecture. The vision behind Bluesky is to build a global square with these concepts.

    I definitely wish they would’ve extended ActivityPub and collaborated on the wider network, but I kind of understand wanting to start from scratch and not get involved with the cultural debt Mastodon brought to the network.



  • Misskey is a little bit odd, in the sense that there’s constantly new forks in various stages of development. New forks emerge just as quickly as old ones die off.

    It may be that the frontend and backend both being written in one language helps make the system easier to hack on. I can’t say for sure. What’s weird is that some of these forks go in really odd directions, like rewriting the whole backend in a different programming language.

    The other thing is that, despite their proliferation, the effort is somewhat fragmented into all of these little projects. I’m not sure how viable any of these forks are in the long term.


  • Thank you for these insights!

    Yeah, aside from developer muscle, an effort like this requires deep knowledge of the existing system. Or, failing that, a commitment to learning it.

    It’s also not something that can be done as a side project, if it hopes to compete with the main project to the point of replacing it. Something like that requires an ungodly amount of effort and dedication. Someone would have to commit years of their life to solely working on that.



  • It’s an interesting and frustrating problem. I think there are three potential ways forward, but they’re both flawed:

    1. Quasi-Centralization: a project like Mastodon or a vetted Non-Profit entity operates a high-concurrency server whose sole purpose is to cache link metadata and Images. Servers initially pull preview data from that, instead of the direct page.

    2. We find a way to do this in some zero-trust peer-to-peer way, where multiple servers compare their copies of the same data. Whatever doesn’t match ends up not being used.

    3. Servers cache link metadata and previews locally with a minimal amount of requests; any boost or reshare only reflects a proxied local preview of that link. Instead of doing this on a per-view or per-user basis, it’s simply per-instance.

    I honestly think the third option might be the least destructive, even if it’s not as efficient as it could be.























  • I mean, the real gag here is not just that it’s bad and people mostly don’t use it correctly, it’s that your whole section can catch hell if QA finds even the smallest error. Better have multiple people on DIT to look over everything every single day!

    It got to be one of those things that I hated so much, I sketched out plans for my own open source alternative. No guarantee that I’ll ever actually make it, but I have loads of thoughts on how to do this better.

    Meanwhile, all the F-35 guys laugh at us in ALIS, which is apparently great.


  • Holy shit, Air Force MX represent!

    Yeah, this piece of garbage has it all:

    • Crusty UI that looks like Windows 95 + Web 1.0
    • All navigation is done either though typing numbers in a box, or diving into a maze of links with the density of a black hole.
    • Loses everything if you hit the back button
    • Schedule in the future, sign off in the past.
    • The yellow windows in the ugliest font imaginable. Pop-up blocker enabled? Yeah, you won’t see them, and your page will refresh if you turn it on.
    • Have fun fishing for a primary JCN to pull from for all your subsequent job write-ups. Cross-reference everything!
    • You signed off a whole JCN tree on an X and need to open it up again? Better have powers.
    • Half the time, your shop writes stuff that’s just wrong. They took out a part and put it back in? “L 127 Configured to Installed Position”, because they didn’t want to put in an install and removal job.
    • Being the DIT monitor who has to fix all the bad write-ups for QA compliance. So many people get basic details horribly wrong.

    Been doing F-16 MX and using this garbage for the last few years now. I’ve actually gotten pretty good with it, but it doesn’t excuse the fact that this is one of the worst pieces of garbage out there.