this post was submitted on 06 Jul 2023
233 points (99.6% liked)
Programming.dev Meta
2464 readers
2 users here now
Welcome to the Programming.Dev meta community!
This is a community for discussing things about programming.dev itself. Things like announcements, site help posts, site questions, etc. are all welcome here.
Links
Credits
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Pertaining to the discussion in case you missed it https://ploum.net/2023-06-23-how-to-kill-decentralised-networks.html
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 :)
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.
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.___
Really good write-up!
It persuaded me that federating with any corporation is not a good move at such early stages.
Very informative, thanks for sharing.
The author is definitely qualified to speak on XMPP and ActivityPub but one thing I noticed is all protocols and technologies mentioned really had no other alternatives for communication. Users flocked because there was nowhere else to go.
Imagine Lemmy.world was owned by Meta and today decided to federate only with those who paid it.
It is in the power of users to host their content on instances that will not turn on them - which unfortunately means not holding discourse on monitized instances