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.
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 tag 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. This means 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).
Community/subreddit admins can moderate the comment sections of their posts, and hence manage more than just the list of posts. Multireddit creators only manage the list of subs. So no, a multireddit cannot be seen as meta-communities in the sense that you mentioned.
The latter is precisely the reason why I was claiming that a popular enough multireddit can have indirect (sorry if that was not clear enough) power over the content of the sub. The same way that even if you can publish FOSS android apps out of F-Droid, it is interesting to comply to F-Droidās rules so that your app is published there, because F-Droid is significantly more popular than your app is.
Anyway, this little comment was me trying to anticipate this exception that could be mentioned to the general point I was trying to make : multireddit maintainers usually have no power on the subsā content, unlike the subs with respect to the posts.
I donāt really understand why one would create a clone community on another instance (call it instance B) if the reason is not to have a different moderation from the original one (instance A).
In fact I do see one reason : to allow people from an instance Ā© that does not whitelist instance A to join the meta-community. In that case, the obvious solution is to allow instance C to whitelist the community without whitelist the full instance A (e.g. because it trusts the community mods but not the instance admins).
Hope that makes sense, as I donāt really know how whitelisting currently works, i.e. whether the instance has power on
on which instances its users can follow a community (thatās the one I assumed)
users from which instances can join its communities
both (1) and (2) from a single list
(1) and (2) separately (that would be ideal I think)
If the new communities are created on other instances. I donāt really see the need for duplicating the existing communities.
If you mean whitelist vs blacklist, I agree ! But I donāt think any of our points rely on that distinction. Do you think they do?
A conclusive remark : if all you meant with this meta-community thing is a multireddit-like aggregate for similar communities, I agree it would be nice. If you actually mean merging two similar communities with a result that keeps living on both instances, Iām still not sure I see either the how or the why you would do that.
I said a meta-community manages communities while a community manages posts. Thatās all the sense I meant.
But I believe you now understand what I meant. Letās not dwell on the semantics.
Thatās fine. Itās honestly not a strong enough influence, and you can always make alternative multireddits. Why is that influence bad?
Can you give an example of a multireddit in reddit that has had any influence at all in a subreddit? Because I very much doubt that has ever been the case.
Thatās an unfair comparison. Not only is creating an F-Droid repo much harder (creating a multireddit is literally a few clicks and just select what you want, you donāt even need to self-host anything), but also you donāt have F-Droid accounts that keep the settings consistent across devices, you need to manually configure every time (plus you have to manually type the URL, in androidā¦ itās easier to remember the name of a subreddit than the URL of a repo) which makes the defaults much more relevant. For multireddits there are no defaults, people have to actively look for the multireddits they want and make the choice themselves on which ones to subscribe from the start, and once they are subscribed, that subscription carries in their account, from wherever they login.
Exactly. Thatās the problem. Thatās why I doubt weāll ever see lemmy.ml stop being the main instance.
Iām not sure if that would work, or at least I think it should not work. If an instance has blocked another instance I donāt think metacommunities should be a way to workaround that (I think the point of blocking an instance is to not have to cache/host its contentā¦ this is important if an instance is for example hosting illegal content). I expect metacommunities would only work between instances that have been whitelisted by the instance that is hosting the metacommunity.
However, as far as I know, the blocking is not transitive. So even if server A blocks server B, if both A and B allow connection to C, then C has access to the communities from A and B, even if A and B donāt have access to each other.
If you then make a post in server C, users from A and B can both comment, but the comments from people in A cannot be seen when visiting the post from B, and vice-versa. So I expect a āMeta-Communityā (or whatever you wanna call it if you donāt like the semantics) created in C that has communities from A and B, will have the same effect on the posts. People from A visiting the āmetaā from C will not see the communities from B on it.
I actually expect the logic for aggregation would happen in whichever server you are using to access the āmetaā. So itās not C (the creator of the āmetaā) the one who aggregates the posts if you access from A. I expect A will just collect the list of communities from C and just aggregate them on their side when showing to their users the āmetaā created in C. The same way as it happens with comments. But all this is just implementation details that are besides the point.
Thereās a limited amount of topics that are interesting enough to gather a big enough audience. if communities cannot be duplicated I seriously doubt thereāll ever be a big number of federated instancesā¦ maybe a few docens being optimistic, but without ever reaching the hundreds. So I think lemmy.ml will continue being the central node if there isnāt a change in philosophy.
Multireddit-like meta-community
And I said āmanagesā doesnāt mean the same as a community is more than a list of post (so its management includes moderation), while a multireddit is a list of subs. You then referred to the meta-communities as a form of authority, as if the communities were grouped under a centralised authority who actually had some power over the federated commus; which is why I thought it would be appropriate to insist that it is not the case.
I agree. That was meant as an anticipation to a counterpoint, which I thinl it is now clear that you wouldnāt have tried to make. Sorry about the generated confusion.
Smaller instances
Note that I was only talking about two simultaneously existing communities with exactly the same topic and CoC. This does not prevent a community from migrating, by which I mean the old one blocking new post submissions and linking to the new one in a pinned post and/or sidebar.
To gather an audience big enough for what? There is an infinite amount of topics, and there are also several communities that can be constructed around the same topic (with different CoC, or focusing on different aspects, media,ā¦)
I didnāt imply that meta-communities have to necessarily be identical to communities, I meant they manage communities in the same way communities manage posts. The only reason I said it is to illustrate how they could fit in the model within lemmy. If you understand what I mean, then thatās all that matters.
But if you wanted, the same kind of moderation and additional elements could in theory translate to meta-communities. I just donāt think thatās the interesting partā¦ but in theory you could make it so users can post new communities or comment about the addition of the community (not comments in a post, since itās not posts what a meta-community manages), and in that case moderation in the meta-community would make sense. In theory you could also have bans/kicks and all the same things you have in communities. But Iād be ok with meta-communities being locked down from user submissions or comments. I think the interesting part is just having an aggregate of communities that is cross-instance and that any user can make, without disrupting the communities themselves.
You could essentially make a meta-community by making a community where every single āpostā is actually a link to a community, and having some alternative view that shows the posts of all communities posted, aggregated, instead of showing the actual āpostsā of the meta-community (which will be just links to communities).
This is not necessarily how it needs to be, but it could be one way to do it that illustrates why I was calling them āmeta-communitiesā. But if that term is confusing, we can call it other way.
I didnāt mean meta-communities (or multireddits, or whatever naming) have authority over the communities they aggregate, whether the meta community has moderation for the submissions (communities, not posts) that happen in that meta-community (not in the communities) or not. For sure itās good to clarify that. Thank you.
Thatās how migration in centralized networks work. If thatās the intended approach I donāt see whatās the benefit of federating server-to-server.
Just create an open source reddit clone and decentralize the aspects that you want to share cross instance. You donāt need the instances to federate if you want to centralize the communities. If communities are meant to not federate, then use cross-origin from the client requests instead of serving one instance through the otherā¦ that way you reduce the requirements on the servers, simplify the whole model, donāt need whitelisting/allowlisting and give freedom to the user to move freely cross-instance by having the account management in a separate independently hosted service, like I already proposed before. You are not benefitting from federation if communities are meant to be centralized.
Enough to be actually useful/used. Reddit has 1.2 billion subreddits but only 138k are active. And they have 430 million monthly users.
You can create an infinite amount of topics, but the number of topics that can be active is not as big. It makes no sense for a user to subscribe to an infinite amount of topics, let alone be active in all of them, so in the end thereās always a limit in the number of useful topics, and this limit is relative to the amount of users, their engagement and diversity.
But they donāt. A community contains post who are written for the community by its users. If a community refuses a post, it basically doesnāt exist. A meta-community refers to communities who exist independently from it.
Sure, one can imagine giving community-like features to a meta or vice versa to create an hybrid of the two, but the two things are just very different to start with.
The difference is that the users donāt need to register on the instance where the community is going. All the instances that federate with each other share a pool of users that can register to any of their communities.
You were complaining that leemy.ml will never stop to be a central place if its communities donāt share content with other instances, but communities could simply migrate from it to other instances.
The communities are not the only actors on the instances: federation allows local users to interact with remote users and communities. That each community is centralized doesnāt mean the whole network is.
Define āactually usefulā. An instance with 2 users who post once a year to wish each other a happy christmas is useful for them. Federation allows everyone to create their own niche community on their own instance. Even if none of them ever reaches a thousand of users, the mere possibly is already an accomplished goal of the federation justifying its existence.
Do you thing lemmy.ml already has all of them?
The link posted (if it has it) does not disappear from the internet. The data attached to the post does, but the same would happen if you delete a community in a meta-community, any related data to the post would disappear too. If the post is not a link then thatās something that would not be comparable because the one limit that meta-community imposes is that all posts should be links to communities, by its very definition it is a community that has that constraint, so if your point is that itās different from communities without that constraint, then sure.
But letās agree to disagree. The fact that you later acknowledge that a meta-community can have community-like features shows you understand what I meant. You are discussing semantics of a concept that I made up, this direction is not bringing us anywhere useful.
Only if you compare it to a website where users need to register on the instance where the community is going. But you can have a network of instances that do not ask people to register on them and that rely on a common authentication method provided by a third service (which can also be decentralized). So they share users without the community hosters having to federate between themselves.
I already mentioned decentralized sharing of user accounts/sessions between non-federated instances. I mentioned it in at least two of my responses to your comments in this thread already.
As mentioned before, you can do this without federating between instances. In fact every user can be remote (ie. its account hosted in a third party service), no need to have any instance be the āownerā of any accounts. You can have user accounts managed by a separate service (similar as how itās done in OpenID) with no need for communication between the instances that host the content. In fact this gives much more freedom to self-host your own account and does not have the problems of instances needing whitelisting to prevent caching/hosting content they donāt want.
I said āuseful/usedā. So you could also say āusedā (ieā¦ people actually use it, itās not abandoned). And in a sentence after that I used also the term āactiveā.
No.
I just read in another comment that there is an issue for that: https://github.com/LemmyNet/lemmy/issues/1576