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.

  • 35 Posts
  • 28 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.




  • They kind of fucked up everything in approaching this by not talking to the community and collecting feedback, making dumb assumptions in how the integration was supposed to work, leaking private posts, running everything through their AI system, and neglecting to represent the remote content as having came from anywhere else.

    The other thing is that Maven’s whole concept is training an AI over and over again on the platform’s posts. Ostensibly, this could mean that a lot of Fediverse content ended up in the training data.







  • 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.











  • Yeah, I don’t have a complete answer here. I think that Terms of Service requiring standards of behavior are quite reasonable - people in Congress, for example, are required to conduct themselves to a certain standard or be ejected. Same goes for courtrooms.

    There may be a “minimum threshold” for content or communities that are blocked, on the basis of materials provided (hate speech, harassment campaigns, doxxing, CSAM), but I’ll readily admit that this is conjecture.













  • So, here’s the thing: these guys are working full-time on the project. Their only source of income, grants aside, are donations via fundraising. Effectively, they are putting the project above themselves.

    The common model for this nowadays is the Patreon / OpenCollective / LiberaPay, where donations are usually given continuously over an indefinite period. It’s closer in form to crowdfunding than it is traditional institutional donations.

    This is going to sound shitty: just as the expectation is set that no one should make demands of work done for free, so too is the expectation that development work technically isn’t owed a single penny. Any donor can stop giving, for any reason, at any time.

    If I as a donor feel my needs aren’t being met, I can stop donating. As a collective action, a bunch of dissatisfied supporters can do the same all at once.

    I’m not saying either side should threaten each other. But let’s not pretend that this is some hoity-toity Utopian model where donors selflessly hand over money with no expectations, and the developer just works on whatever. If your livelihood depends on it, if you can’t put bread on your table without it, then you’ve got to keep your backers happy.


  • Accepting donations is not the same as entering into a contract agreement where the person giving a few bucks per month entitles them to dictate how the work should be done. If people want to enter in a relationship where they get exactly what they want for the money they are giving, then they will be better off by going to a commercial provider, so that the nature of the transaction is explicit and mutually agreed.

    With respect, this is a framing issue and depends on your point of view. Does a donation mean someone contracted you to do something specifically? Not really. But, will mismanagement of expectations and hostility convince someone to stop donating to a project? You’d better believe it. If you’re working full-time on a project, donations are your lifeblood. They literally put food on your table. You literally can’t afford to disregard the needs of users and admins. But of course, you are at discretion to decide what those needs actually are, and how critical they are. Nevertheless, the relationship is more transactional than it appears to be.

    About the grants: AFAIK they got the grant to make federation work, which was completed to everyone’s satisfaction. If they had received a big grant from NLNet, got the money but didn’t deliver on what they promised on the application, then you could argue that they did not hold their end of the bargain. But do you it’s fair that because they got money from one part of the work that they should be responsible for all subsequent deliveries?

    Overall, I think their grant from NLNet was a good thing, and I think they did good work on that. As long as their work was in scope of the grant, I don’t see a problem with that.

    I’m really trying to understand where you are coming from with this. You mentioned your work on Diaspora, and I don’t know how much you were involved on it,

    Community Manager, circa 2011 to 2013. I was basically an air traffic controller for GitHub issues, acted as a developer liaison, served as a face of the project to the community, and engaged on the network every single day to get a pulse on what was going on. A lot of it involved smoothing things over with people who were upset about things, resolving conflicts, drumming up volunteer coders, and indicating to core team what varying needs were across the user and developer communities. I lived and breathed it every day.

    I do feel that one of the things that doomed Diaspora was that the founders mistook the attention and money they got in 2010 as an indication that they were all alone responsible in “saving us from Facebook

    This is somewhat inaccurate, and here’s why: Diaspora never advertised itself as an Anti-Facebook. They were building a federated network that focused on user freedom, and it was a combination of timing and insanely good luck that their Kickstarter campaign picked up as much as it did. The whole “we’re going to save you from Facebook” thing was an invention of the media to get people to click headlines. What really doomed Diaspora was that the core team wanted to be a startup, the community wanted it to be a project, and getting the company into yCombinator had the team focus on things further and further away from their original goals.

    If Ilya had learned to say “it’s not my responsibility to build everything to win a fight against a multi-billion corporation”, perhaps he would still be around. This is a little disingenuous. Ilya had a big heart and was an amazing person, but he struggled with depression, anxiety, and mental illness. There was an enormous amount of pressure, sky-high expectations, and media vultures that picked apart every little hiccup the team went through, but I don’t think it’s fair to say it was those things alone that made his passing happen. They didn’t make life any easier for him, though.