I’ve been looking for a free Reddit alternative and preferably one that was federated. I’m not really sure how federation works with this though. A lot of similar sites are just personal projects that people made as a hobby that lack a lot of important features or the interface was really ugly.
I haven’t seen how to moderate communities though but the Github page says this can be done, which I consider important since I want moderation to be done by communities and users rather then admins. If there’s a quarantine feature similar to Reddit that would be useful too so I don’t just have to ban communities.
Yep, it’s the closest thing to what I’ve been looking for in a long time.
Though I wish it focused a bit more on “topics” or categories rathen than specific communities centralized in specific instances. I use sites like reddit more as a way to get news rather than as community forums.
Do you mean … ?
I don’t the point of that. You create a community on one instance and people from other instances can join it. What is wrong with that?
Or mayne you mean …?
What if the same name labels two different topics? On the other hand, what if two communities on the same topic have different names? (eg on reddit there’s r/howyoudoing and r/friendstvshow) I think it’s up to the communities to decide whether to merge or not.
If you are involved in communities that you think should merge, I think the only viable first step is to understand why they are differennt communities.
I feel that lemmy is a bit too centralized around lemmy.ml, there’s very little point to, for example, make a “!Fediverse@some-other-less-popular-instance” when you already have [email protected] …it kind of defeats the point of federation if you depend on lemmy.ml as central point, even if you are accessing from other instance.
Maybe your idea of merging 2communities could be a way to mitigate this. Reddit has a feature called “multireddit” that essentially does that. For example, here’s a multireddit that combines the subreddit for each continent: https://old.reddit.com/user/lookseerouw/m/continents/
Agree, but this is not a feature issue. The problem is that most people are on lemmy.ml, and so are naturally the communities that they create. The question is how to get newcomers (including myself actually !) to register on other instances.
Right, but multireddit are just aggregated feeds from different communities, not actual merging.
Anyway, I don’t think that this merging idea is a good one, I was just trying to figure out what you meant with cross instance communities.
Off topic:
Sorry, this was a post I accidentally deleted by misclicking (it might be a good idea to add a confirmation prompt or something).
I pressed “edit” on the deleted post hoping at least I could re-write it that way, the edit dialog was empty so I started re-writting the whole thing and saving.
Then I realized the edit did nothing on deleted posts, so I had to post a new comment (the one above).
Only after that did I found out you can actually press the delete button on a deleted comment to “restore it” (I guess “delete” just hides it?). But by then the earlier edit had overwritten the original post (so I guess editting deleted posts works, it just doesn’t unhide them).
I’d suggest: either disable the “edit” button on deleted posts, or make it so pressing “edit” on the deleted post restores it right before you start editting it (maybe change the text to “restore & edit”)
I agree, but imho it is a big deterrent if making a community in a smaller instance means competing with bigger instances that are way more popular.
Personally I’d actually like to self-host my own instance just to register myself on it (just like with email or XMPP), manage my own identity, my own profile, and don’t depend on whether any particular small instance is gonna dissappear tomorrow, or if the allowlist of that instance isn’t what I’d like, or if I’d rather change the UI in this or that way.
I didn’t say “cross instance communities”, I said “topics” or “categories” because I don’t think it necessarily has to be “communities” what needs to be cross-instance.
I was presenting a problem, not a solution. You made 2 proposals: the merging of two communities as “option 2” that I think might mitigate the issue (I agree it might not solve it, it depends how it’s done) and your “option 1” which might also help if it were possible (but it’s probably more complex).
What could that be except communities? Hashtags maybe? Or maybe having communities that affiliate with each other, not as a full merge, but providing a mutually agregated feed, something like a multireddit but that would be accessible from the communities’ respective pages.
Yes, all those are valid ways to approach it, imho.
(Hash)tags is the obvious one. Also the most chaotic and mob-driven. But it would be the least centralized and more community-driven way to approach it. I expect each community would be able to moderate what tags are allowed for the posts that are submitted to it, and/or be able to correct mis-tagged posts. And ideally each user browsing by hastag should be able to add his own blocklist to exclude communities he doesn’t want content from. This approach has the advantage of being more granular and offering a categorization that is “perpendicular” to communities. So you can actually browse by tag in only one community (as a way to subdivide it further) just the same as how you can browse by tag on a particular instance or on the whole fediverse.
Multireddits are curated aggregations of subreddits, but that means it requires maintenance and in the end it has a centralized point of control. In the reddit example, any user can decide to make a curated list of subreddits to form a multireddit, when people “follow” the multireddit the user who created it is the authority to decide what new subreddit might be added/removed. I guess it could be seen as meta-communities (a community that instead of managing an aggregate of post manages an aggregate of communities). This way you can have multiple meta-communities for the same topic that organize communities in different way, or that gave different “authorities” so if you don’t like the set of communities one person has chosen, you pick another (or make your own), so even if the authority is centralized, you can switch it around and have it your way without really losing content. So centralization of that control is not a big a deal as long as you can fork it with no further consecuence.
Whichever path is taken, the goal is being able to subscribe to a topic in a way that’s cross-instance, without having to manually keep track of each instance, taking advantage of the federation and not having to rely on big community nodes to form around one server. Ideally even if there were many small communities in separate instances it should work just as well as if there was only one big one.
Without something that, I don’t see what advantage federation has for a reddit-like service (the main advantage I see right now is shared user accounts, but you could have also done that without needing federation, by separating the user/session management to a different service/API that independent servers could use for their own communities without needing to federate with other communities).
I don’t agree : “managing” doesn’t mean the same thing. AFAIU, there’s nothing more to managing a multireddit than updating the list of subs it contains. Managing a community (or a sub) includes moderating the content. The only way for a multireddit maintainer to have any control is that the multireddit be more followed than the subs it contains, so that being part of the multireddit is in the sub’s interest.
I don’t think one has to manually keep track of the instances. One can subscribe to a community on another instance, follow the updates in their subscribed feed, and comment from their instance.
Ok, if there are two communities on the same topic on two different instances, that’s two communities that one has to subscribe to, but that’s a one time operation, right? Also if the communities have to be created on two instances, it probably means that they don’t share the same code of conduct (CoC). So it does result in two different communities being created, right?
Maybe what you are asking for is that instances being able to whitelist only a community from an instance, e.g. if the community has stricter CoC than the instance? I have don’t have any idea about whether it already works that ways, or about how hard it would be to implement that.
To me, “manage” in the context of an aggregate means “add and remove”, sometimes edit.
A meta-community adds/removes communities to its aggregate, a community adds/removes posts to its aggregate.
Moderation is a separate topic. I expect the only ones who add/remove communities to a metacommunity are already the admins/moderators. Though I guess if you allowed users to submit/propose new communities to add to the meta-community, then in that case moderation would make sense.
A multireddit never has any control over the posts (not even if it had more followers than the communities). That’s the job of each individual subreddit.
The only thing a meta-community has control over is which communities are added/removed, not the posts that get shown. It’s a “meta-community” not a “super-community”, it does not have authority over what the communities post.
If a admin/mod in a meta-community does not like the posts or the CoC of a community, then he can just remove that community from the meta-community. But that would not make the community stop existing or posting. It simply won’t be part of that meta and users subscribed to the meta won’t see those posts as part of it.
When you want to post something you still need to choose a community where to post it. Meta communities aggregate, but they do not add new posts. The point is you can still follow the meta-community and get an aggregate of news from a curated set of communities, which will be cross-instance if it’s used for communities in different instances.
That’s what I mean by manually tracking each instance. You have to manually subscribe to a separate community for each instance.
For 2 communities it’s 1 time, for “N” communities it’s an “N-1” times operation. Where “N” is an evolving number determined by the number of instances that exist at any given time and how many communities on the same topic they create. If you want to follow a topic cross-instance you need to actively keep up to date on what new instances have been created and what new community on that topic have the instances (old & new) added.
Proof that users are required to track this evolution is how the most subscribed community in lemmy.ml (https://lemmy.ml/c/announcements) is about announcing new communities.
It’ll always result in two communities being created, even if they had same CoC. And in fact, to avoid centralization (which is the whole point), it shouldn’t matter if the CoC is the same, they should be usable communities even if they have few posts and are otherwise identical to lemmy.ml, otherwise there’s very little reason to have (or join) a community outside of the big central one.
The fact that you think that in order to create a community in another instance for the same topic the most probable reason is CoC discrepancy shows that there’s very little incentive to de-centralize the communities. I don’t see how lemmy.ml will stop being the central community node if that doesn’t change.
I don’t understand, how would that help?
Wouldn’t that essentially make things even more centralized since that would further restrict lemmy.ml federation?
The whitelisting (or allowlisting) itself is playing against the idea of federation. If you block it all except selected servers then you are essentially creating your own walled garden. Anyone is allowed to make their own walled gardens, or contribute to it. But that’s just the same as how everyone is allowed to make an open source reddit clone or contribute to it. Personally, if we were to go that route I would have preferred if instances did not federate among themselves and instead they relied on a common user/session authentication system, with the servers being decentralized in the same sense as how “The Web” itself is decentralized, with no need of server-to-server federation. At least that way the user is the one who decides which instances is he allowed to use his account on. Otherwise, as it stands, it makes no sense to make a personal instance, not even to host your own identity, much how it makes no sense to make a personal reddit clone, since you won’t be able to use that account in other servers without being explicitly allowed (and it would make no sense for lemmy.ml to add a personal server with no communities to their allowlist).
I just read in another comment that there is an issue for that: https://github.com/LemmyNet/lemmy/issues/1576
Cross instance communities are an interesting idea, although it’s unclear how they would be moderated, or how executive decisions would be made.
Whats unclear to me is how “cross instance communities” could be implemented in activitypub. Honestly I dont see any way to do it, because every
Grouplives on a single server.Couldn’t it be done by the application, where at AP level there exist 2
Groupobjects, one on each instance? One is the leader, the Community that was first created, the other is a follower. The group actors synchronise activity between them, such that in the UI it seems they form a single Community. This means e.g. that the follower group is authorized to perform admin activities on behalf of admins at the leader group (and possibly vice versa).I know this is something of a trick, less desirable than native protocol support. Note that I am very interested in seeing the Community concept go next-level, see e.g. Standardizing on a common Community domain as AP extension?. Also there’s renewed interest in standardizing Group behavior, now that PixelFed will release support for them. See PixelFed Groups on SocialHub.
If there is a leader then its still centralized, and its not clear what will happen if that leader disappears. Sure there might be some hacks to make it work, but I think that decentralized groups would need to use a different protocol from activitypub.
I am also interested in standardizing activitypub groups, but for now i’m busy refactoring our entire federation code, to make future changes easier (including compat with other projects).
Maybe leader/follower is the wrong concept. Synched groups might be better. To the user-observer they are similar to decentralized groups. But it’ll be a bit hacky, for sure :D
Good luck with the federation code. I am super curious about the features it will bring to Lemmy!. Thank you for all your efforts and dedication 💚