2 ms·

> If you want to deal with a million accounts, you can. There's nothing stopping you from registering accounts for every service you use even if this takes off

> If you want to deal with a million accounts, you can. There's nothing stopping you from registering accounts for every service you use even if this takes off and everyone else moves on to federated services. I apologise for any confusion; I wasn't contending that ForgeFed would prevent me from using individual accounts, I was contending the statement > What happened is that it massively sucks. IMO, it doesn't. It sucks, but not massively so! Maintaining individual accounts across, maybe, six or seven providers[1], does indeed suck, but not massively so, and not enough to go to the trouble of maintaining my own instance within a federated system. [1] I will probably never have anywhere close to a million individual accounts at code-hosting providers, even if it were federated. There will also never be more than a handful of providers where 99.9% of everyone goes. As we've seen again, and again, and again ... any distributed system (like cryptocurrency exchanges, federated social networking, etc) slowly consolidates into three, maybe four places that get almost all the traffic/users. It becomes centralised. Is there any reason you think that this time, with ForgeFed, it will be different? Federated systems are a technical solution to a social problem, which is why it always fails - i.e. results in centralisation eventually. If you have any examples where the result truly is normally distributed amongst all the instances I'd really like to see that.

vidarh 3y ago
> [1] I will probably never have anywhere close to a million individual accounts at code-hosting providers, even if it were federated. There will also never be more than a handful of providers where 99.9% of everyone goes. I think we're talking past each other. I celebrate the move towards federated systems because if done right I won't need accounts on a bunch of individual systems. Unlike today where I do have individual accounts on multiple different code hosting sites. > Is there any reason you think that this time, with ForgeFed, it will be different? It's irrelevant to me if 99% of users are on a single ForgeFed instance as long as it's still federated so I don't need to be there if I don't want to but can still interact. ActivityPub support also means that even if they do nothing to provide easy migration, spidering all the relevant content to move it elsewhere if a dominant ForgeFed instance goes rogue is easy.
- lelanthran 3y ago
  > It's irrelevant to me if 99% of users are on a single ForgeFed instance as long as it's still federated so I don't need to be there if I don't want to but can still interact. Only if you're running your own instance, otherwise you're at the mercy of whoever's instance you are on: if they decide to cut off some other instance for whatever reason, then, no, you won't see that other instance without running your own instance. And if you do federate with rogue instances, your own instance will be rejected from the popular ones anyway. It's a social problem, not a technological one, so you get all the downsides of centralisation with none of the upsides.
  - vidarh 3y ago
    > Only if you're running your own instance, otherwise you're at the mercy of whoever's instance you are on: if they decide to cut off some other instance for whatever reason, then, no, you won't see that other instance without running your own instance. And if I sign up to individual servers, they could ban me. There are risks in every model, but unlike in a centralised model, with a federated system I get to choose along a wide spectrum with respect to which risks I'm prepared to take. I could just sign up to the dominant server if I'm comfortable with that. I can pay someone to run an instance for me, I can run my own, I can find an instance run by someone I trust. The worst case is that I get the same upsides and downsides as in a centralised system. > It's a social problem, not a technological one, so you get all the downsides of centralisation with none of the upsides. To me this notion that there are upsides is comical, because of the above. I get choice. That's an upside. For my Mastodon setup I opted to run my own private instance because it gives me a level of control of the interface, and who I federate with and a number of other things that I don't get from the big instances. For Lemmy, I couldn't be bothered, because it's not (for now anyway) important enough. For ForgeFed, who knows, we'll see. But unlike with a centralised system, when I make that choice I don't choose away communication with all of those on other instances. So to me, it is strictly better, and your hypotheticals are irrelevant because my worst case is to go back to the centralised model and register an account with a dominant instance.

vidarh 3y ago

> [1] I will probably never have anywhere close to a million individual accounts at code-hosting providers, even if it were federated. There will also never be more than a handful of providers where 99.9% of everyone goes. I think we're talking past each other. I celebrate the move towards federated systems because if done right I won't need accounts on a bunch of individual systems. Unlike today where I do have individual accounts on multiple different code hosting sites. > Is there any reason you think that this time, with ForgeFed, it will be different? It's irrelevant to me if 99% of users are on a single ForgeFed instance as long as it's still federated so I don't need to be there if I don't want to but can still interact. ActivityPub support also means that even if they do nothing to provide easy migration, spidering all the relevant content to move it elsewhere if a dominant ForgeFed instance goes rogue is easy.

lelanthran 3y ago
> It's irrelevant to me if 99% of users are on a single ForgeFed instance as long as it's still federated so I don't need to be there if I don't want to but can still interact. Only if you're running your own instance, otherwise you're at the mercy of whoever's instance you are on: if they decide to cut off some other instance for whatever reason, then, no, you won't see that other instance without running your own instance. And if you do federate with rogue instances, your own instance will be rejected from the popular ones anyway. It's a social problem, not a technological one, so you get all the downsides of centralisation with none of the upsides.
- vidarh 3y ago
  > Only if you're running your own instance, otherwise you're at the mercy of whoever's instance you are on: if they decide to cut off some other instance for whatever reason, then, no, you won't see that other instance without running your own instance. And if I sign up to individual servers, they could ban me. There are risks in every model, but unlike in a centralised model, with a federated system I get to choose along a wide spectrum with respect to which risks I'm prepared to take. I could just sign up to the dominant server if I'm comfortable with that. I can pay someone to run an instance for me, I can run my own, I can find an instance run by someone I trust. The worst case is that I get the same upsides and downsides as in a centralised system. > It's a social problem, not a technological one, so you get all the downsides of centralisation with none of the upsides. To me this notion that there are upsides is comical, because of the above. I get choice. That's an upside. For my Mastodon setup I opted to run my own private instance because it gives me a level of control of the interface, and who I federate with and a number of other things that I don't get from the big instances. For Lemmy, I couldn't be bothered, because it's not (for now anyway) important enough. For ForgeFed, who knows, we'll see. But unlike with a centralised system, when I make that choice I don't choose away communication with all of those on other instances. So to me, it is strictly better, and your hypotheticals are irrelevant because my worst case is to go back to the centralised model and register an account with a dominant instance.