- cross-posted to:
- blogging@programming.dev
- lemmy@lemmy.ml
- fediverse@lemmy.ml
- cross-posted to:
- blogging@programming.dev
- lemmy@lemmy.ml
- fediverse@lemmy.ml
I made a blog post on my biggest issue in Lemmy and the proposed solutions for it. Any thoughts on this would be appreciated.
I’ve already went on on why merging communities is Bad for the Fediverse (and only really helps the big corpos that get into the Fediverse), so it’s good that the badness of that “solution” is acknowledged.
As for #2: multicommunities: I seem to recall Kbin already does that, so it should work. As for sub-issue 1, "To create a multi-community, you would have to know where each community is and add it to your list. ", well that’s what webrings are for! Let’s bring them back from the '90s. Basically get’s give the power of “static search” back to the users.
Numero 3 Electric Boogaloo: Making communities follow communities, is not much of a bad idea, but I’m wary fo the issues already mentioned in it. I’m mostly concerned also about it making it harder to maintain smaller Lemmy instances due to the extra communication overhead.
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.
Oh that’s a very good point! I had the wrong impression there was extra data sharing needed in this case but yeah, looking back it makes sense that the amount of data transfer is about the same considering the focus is on the verb (actor A sends to / pulls from actor B) rather on who is doing the action.