I’m not suggesting anything, just want to know what do you think.
Here is a link if someone don’t know what Meta’s Threads is: https://blog.joinmastodon.org/2023/07/what-to-know-about-threads/
I’m not suggesting anything, just want to know what do you think.
Here is a link if someone don’t know what Meta’s Threads is: https://blog.joinmastodon.org/2023/07/what-to-know-about-threads/
It really helps to hear a historical perspective on this. The issue is not a matter of, “let’s give them a chance and see how it goes.” It’s more like, “we know this has gone very badly in the past and the incentives are clear for Meta to sabotage us.”
yep. And as an XMPP networks op, I wish we had figured-out the technical measures to avoid it in the meantime. Practically, it boils down to preventing a single actor from consolidating a “greater than X” share of the network, while retaining the desirable aspects like “promoting the better services for the most users”.
I have had similar thoughts about breaking monopolies in the Fediverse. Similar to a multi-national alliance, it should be possible to have federation-wide agreement that one instance population cannot grow beyond a certain share of the whole, the consequence being defederation. And I think that would include limiting each admin to a single instance within the federation.
I only fear this rule would be too harsh in practice and penalize the wrong enthusiasts.
Such an alliance could be the achieved organically by listing-out instances passing a certain set of requirements, like: https://providers.xmpp.net/ , and constraining new joiners to route their account creation through it. But several aspects of this consist of undoing major benefits of decentralization/federation. There’s no free lunch :)
How would this apply to things like mastodon.social having having 13M accounts ( https://mastodon.social/@mastodonusercount ) compared to lemmy.world having about 53k accounts?
Would you not push messages there because it’s too large? Would you not send email to gmail because it’s too large?
… and from my days as a news admin, how would you catch / block a no user relay node that relays data to a quarantined node?
All good questions I don’t have good answers to.
Especially when you compare entirely different software (Lemmy vs Mastodon) that happen to both use ActivityPub. So there is already an imbalance. And the imbalance has also started within Lemmy where larger instances have a sort of snowball effect.
I think ideally the “too large” instances would find more admins and split the instance into smaller ones. But that might not be feasible today with the existing technology and human resources.
Another option is to “stop the bleeding” by locking an instance to new accounts to give others a chance to grow. This should have already happened on lemmy.ml IMO. The instance performs very poorly (as of a week ago).
I don’t know the technical details of ActivityPub well enough to propose a real solution. Sounds like an arms race situation.
One of the biggest challenges of federated systems is discovery of content. There’s the fedi.tips : How do I discover accounts to follow on Mastodon and the Fediverse? which gets into it a bit for Mastodon… but that’s fundamentally the biggest problem. Finding content on other servers and getting your content out beyond your “home” server.
Sometimes it doesn’t matter. Sometimes it’s easy for certain content or people. But for most of us, if you want to chat about Star Trek - where do you go? Fortunately, that’s all on https://startrek.website/ - but take Rust for example which is scattered across dozens of instances each claiming a small bit of people.
And if you want /r/all style smorgasbord content of “a bit of this” and “a bit of that” and “this might be interesting”, then lemmy.world local is much better than startrek.website local. Subscribing to everything on lemmy.world while being on another site is… not entirely polite. The “all” is… a filtered list that doesn’t have what I want. I’m on programming.dev for the local since that’s the content I’m kind of after. But, there are people who do want that and for them, being able to sample everything in the Times Square of Lemmy - the only place to reasonably sign up is lemmy.world.
Consider that for smaller instances (with smaller storage backends and network pipes), if the users there subscribe to everything on lemmy.world - the storage and network requirements will be similar to what lemmy.world has which the smaller instances may not be able to support well.
The “too large” instances are, in some ways, better for the fediverse just as living in a city tends to have a lower emission footprint per person than living in the country… but that also runs up against the sensibilities of federate and decentralize that many users have.
With that last point on the “something slurping up the content”, I’m going to say “assume it was already started once people noticed Mastodon.”
It is trivial to have a program that is federated with some instances just subscribe to everything and have that data pushed - its even simpler than trying to scrape it or use an API to access it.
It’s not a “don’t post”, but rather a “just as the OG public federated bulletin board (USENET) was trivial to consume, so to is ActivityPub.”
The limitations of “who to defederate from” and “who to block” is rarely who is reading the data, but rather who is pushing content that you don’t want to see to your instance - so too was it back in the day with NNTP.
If privacy is the concern, then a publicly federated system should be the last choice.
You can still read about my drunken escapades back in '98 if you know where to look on google groups… and there’s nothing I can do about it. For that matter, there was very little I could do about it within a few minutes of hitting “post” back then (not all the servers honored deletion messages since a lot of those were forged). The same is true today.
Assume everything you write will be part of the public record tied to the identity that you present and will appear in some AI training data corpus.
If you try to fight against that, you will lose since that is the anthesis of federated system where you’re trying to push your data out as far as possible without it being controlled by a centralized server’s whims.
Yea I honestly think this will just get better over time. People will start by drinking from a firehose to get their disparate-yet-related content, but eventually these groups will consolidate. And if they don’t, that’s OK too. A feature like “community groups” or hashtags could help with this.
I’m not convinced that watching your “subscribed” feed on programming.dev which contains a lot of lemmy.world communities is just as bad (or even close) to signing up on lemmy.world. The egress bandwidth requirements for lemmy.world are strictly much higher than for programming.dev, because the number of active users (clients) is so much higher. programming.dev is able to cache only what programming.dev users are viewing and that only needs to be fetched from lemmy.world once on a cache miss then forwarded to a significantly smaller set of clients. Even if programming.dev gained a lot of popularity from users on lemmy.world, programming.dev would only need to send content to lemmy.world when it’s not already cached, and that doesn’t happen for every lemmy.world user, just once every cache miss.
^ That’s just my theoretical understanding of the problem, but I don’t know enough details about ActivityPub to say if that’s accurate, so take it with some salt.
Economy of scale is definitely a boon, but a monopolized network runs too great a risk to the long-term health of the network itself. I think we can achieve good efficiency with “large enough” instances that are appropriately balanced across the network.
Yea TBH I’m far less concerned about the privacy of the information that I’m knowingly posting publicly than I am about the social network graph effects of large instances. So the whole “issue” of a relay node sending data to places I didn’t anticipate is not a “problem” I care to solve.___