230
Should programming.dev defederate from Meta if they implement ActivityPub? (programming.dev)
submitted 3 years ago by to c/meta@programming.dev
154 comments fedilink hide all child comments
 

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/

you are viewing a single comment's thread
view the rest of the comments
[–] 12 points 3 years ago (1 child)

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 6 points 3 years ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 4 points 3 years ago

    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 :)

  • permalink
  • fedilink
  • source
  • parent
  • [+] 2 points 3 years ago* (last edited 2 years ago) (1 child)
    [deleted]
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago (1 child)

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

    how would you catch / block a no user relay node that relays data to a quarantined node?

    I don't know the technical details of ActivityPub well enough to propose a real solution. Sounds like an arms race situation.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [+] 1 point 3 years ago* (last edited 2 years ago) (1 child)
    [deleted]
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago

    One of the biggest challenges of federated systems is discovery of content.

    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.

    Subscribing to everything on lemmy.world while being on another site is… not entirely polite. [..] 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.

    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.

    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.

    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.

    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.

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

  • permalink
  • fedilink
  • source
  • parent