• 13 Posts
  • 35 Comments
Joined 1 year ago
cake
Cake day: May 2nd, 2023

help-circle
  • Thank you for the detailed explanation. It matches what I’ve heard from others while having this same debate. Now allow me to explain my side.

    I have consented to functionality in which my posts are distributed to other instances within the Fediverse. It’s widely advertised and clearly explained that is how things function. I can readily find which implementations are part of the fediverse

    This is the part I think is wrong and the cause of all of this. You can not find which implementations are part of the fediverse. No tracker that you can use has an up-to-date and accurate listing of implementations. New ones come online every day as some random developer builds something new. The fediverse doesn’t have clear boundaries and I think the advertising that you mentioned does a disservice by implying it does. The fediverse is similar to the web; they’re both based on open protocols and can be guided but not controlled, because anybody can build something on those protocols.

    One response to this fuzziness has been to demand most features be opt-in. The reason I don’t think this is tenable is because you have to have a hard boundary to determine what should be opt-in and what is ok to be opt-out. Your heuristic was native ActivityPub implementation. I don’t think this scales (I feel like you’re going to say this is a technological argument and therefore invalid, but it’s also a social argument. Ppl don’t want to use something that they have to constantly maintain. Constantly adding new servers/users to an allowlist is a chore that would drive ppl away. See google+ circles). It doesn’t scale because like I said above new implementations pop up every day and these implementations are starting to branch away from the static archetypes we’re used to (Twitter-like, Facebook-like, Reddit-like, etc). And some of them are existing projects that add AP support.

    For instance, Hubzilla/Friendica has been bridging AP content for years. Do all of those instances require opt-in because they use a different protocol in addition to AP? There have also been bridges that translate RSS feeds to AP actor for years. Did the owners of those RSS feeds opt-in and should they have been required to?

    What I’m trying to say is I think you’re right that you can never keep up with the boundaries of the fediverse and where your posts end up. And I don’t think there’s an easy delineation for what should be opt-out vs opt-in. So instead we should be demanding that implementations add controls to our posts. Thinks like ACLs and OCAPs would allow you to control who can see your posts and interact with them and not care about new bridges/instances/whatever. Which is why I think the argument over opt-out vs opt-in is a distraction that will only keep the fediverse in this quasi-privacy space where you’re dependent on yelling down any actor who is doing something with yours posts you don’t like.


  • I said the two things are different, you said how does that make asking for consent for the two things different, and my response was that for one of them it already works that way without your consent. That is a clear difference. Yes, I’m talking about the technology to explain the difference, because it’s a concrete fact. Your argument that a bridge should be opt-in requires an abstract boundary that some instances are are allowed to federate on an opt-out basis and others are not.

    You don’t build trust in users by using practices like opt-out, which is again, the only argument I am trying to make.

    The instance you’re on uses opt-out practices. You didn’t consent to your post federating to kbin.social and yet here we are. If you don’t trust the bridge, fine, block it. Every tool on the fediverse that you already use to deal with its inherently opt-out nature is available for you to use with this bridge.






  • The proposal was intentionally written to be easy to implement. All fediverse platforms deal with follows so handling follows for groups is a simple extension to that.

    Some subreddits are still not wanting to move to Lemmy

    I’ve seen ppl saying they don’t want to use any threadiverse platform because of disparate communities/threads. This issue keeps being talked about and always generates pretty big threads so its clear that its an issue that causes a lot of users friction. There’s also plenty of issues that are way lower priority than this but they’re still filed on various projects’ trackers.

    I think it’s higher priority than you do and would contribute to helping the fediverse grow but I don’t think we’re gonna convince each other so I’m gonna bow out here.


  • The third solution wouldn’t cause extra communication. If you’re subbed to a community that follows other communities, you receive all the posts once. That’s the same as if you followed all of those communities yourself.

    If your server hosts communities that follow others, that would still be the same as having users on your server follow those servers. It’s the same amount of communication.

    I’m assuming you were talking about this comment. That doesn’t explain why merging communities is bad, only why you may not want to do it. Which would always be an option. Having the option to merge duplicate communities doesn’t mean you can’t maintain similar communities without merging them.


  • the Lemmy devs are not interested in this

    I know. I’m the one who posted that one of the lemmy devs is not interested in this. But if the userbase gets behind it, they could convince the dev team. Kbin, mbin, or sublink could implement this and even if lemmy doesn’t it would improve things for lemmy users because who follow communities hosted on those implementations and could serve as a proof of concept.

    there is also the “political” aspect

    Everything about the proposal is optional. Nobody would be forced to do anything, unless the owner of the community decides to go against the wishes of the community members.

    Lemmy has been around for years, not months, and this is still an issue that ppl are having. Some ppl know each other and can choose to keep their communities separate. But for ppl who want larger, more in depth discussions and new ppl, this simple technical measure can make the platform better for the multiple reasons I mentioned above.

    Your arguments against it seem to be:

    1. Its not needed. - I’ve pointed out multiple reasons I think its needed. Consolidation either doesn’t happen, is never actually completed, or is a years long process. Discussions are fragmented which leads to communities that don’t have enough activity. New users are unfamiliar with the platform and unaware of large players so don’t know how to find the most active community. Consolidating on a single community means you’ve centralized the community and put it at risk if that server goes down.
    2. People might not want it - The proposal doesn’t force anybody to group their communities. They can maintain their independence. I imagine that mods thinking about grouping with another community would have a discussion with the other mod team and both communities’ members.

    I disagree with both of those arguments but even ignoring that, I don’t understand why it matters to you. You seem to be fine with the current state and this proposal wouldn’t disrupt that. Either the communities you’re in don’t join up with others or they do and you wouldn’t notice (unless a mod groups with a wildly different community)


  • I don’t think we’ve consolidated around fediverse@lemmy.world. You’re using a single post as an example. I’ve posted links that got 40+ comments in fediverse@kbin.social but way less in other communities. I’ve posted or seen threads in fediverse@lemmy.ml that got more discussion.

    The merge of cooking communities on lemmy.world is also not really relevant. Those communities were each supposed to be specialized communities, not general cooking communities. They shutdown because they couldn’t sustain enough activity. And they were all on lemmy.world so the userbase likely all overlapped; I’d bet that most ppl subbed to them were already subbed to cooking@lemmy.world anyway.

    What I’m talking about is when small and medium sized servers (not lemmy.world) have their own communities that overlap with other communities. Users who join those servers aren’t necessarily going to know about lemmy.ml or lemmy.world. They’ll see communities they’re interested in and sub, but then won’t see as much interaction as they want. This leads to ppl just giving up and going back to the corporate sites.

    Even if consolidation is happening, there’s a transition period where ppl are posting in multiple places, ppl get the same post in their feed multiple times, comment threads are separate. Then when consolidation happens, you have a single community where those mods hold all the power. If we used something like the proposal above, each community could still exist but all the conversations are still consolidated. That keeps the power spread out and likely keeps each mod team in check and provides multiple on-ramps to the community. You could find movies@a.com or movies@b.com but if they’re grouped, you still find the super-community. And then if one of those servers goes down, only users subbed to that community have to migrate and they should be tangentially aware of the other community so migration is easier. Their server could even handle that migration automatically.



  • Because all the evidence shows…

    What evidence shows that? This post is in fediverse@lemmy.world and crossposted to fediverse@lemmy.ml. There’s also fediverse@kbin.social and I know I’ve seen others. Most of these communities have been running for a few years now and there’s still no consolidation.

    You can see the same pattern with communities for gaming, linux, gardening, movies, tv, etc. I’m subscribed to multiple communities for each of those topics on separate servers because the consolidation doesn’t happen.




  • This is nonsense. The fediverse isn’t cryptocurrency. Having 51% of the fediverse doesn’t give you any more control than having 1%. If your instance(s) implement a feature that the rest of the fediverse doesn’t like, they can defederate.

    Other instances either react by defederating, but because they only have 49 percent, due to network effects, they get extinct

    If 49% of the fediverse defederates from the other 51%, it is now 100% of a new, smaller fediverse. You can’t just claim that “network effects” will cause them to go extinct. Whether those instances have enough userbase to sustain a cohesive network depends on the actual number of instances/users. And the fediverse has sustained itself for over a decade with less than the current ~2 million accts and most of that time it had substantially less than 1 active accts.



  • before they end up with a seat on the activity hub team. Then we’re back where we started.

    There is no activity pub team. There is an informal group discussing enhancements at https://socialhub.activitypub.rocks but anybody can join that and submit proposals. Any nobody is required to accept or implement those proposals. I have joined the forum and submitted a proposal myself, but nobody has implemented it or even seems likely to.

    Also, not blocking threads doesn’t make your instance a “meta controlled instance”. Meta has no power over any instance other than Threads. Even instances that don’t proactively block Threads can’t be forced to use any hypothetical Meta extensions to AP. And its really unlikely that people who started servers on a minuscule network (most likely for fun or philosophical reasons) are going to follow Meta’s lead just to have access to more people. Everyone who is here and everyone who started a server here knowingly did that on a network that is a tiny fraction of a percent of the size of other social networks; an increased userbase isn’t some big reward for fediverse server admins.