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.
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.
Meta-communities
Sorry, but I am still trying. What you first said is that a multireddit can be seen as a meta-community, which I didn’t understand because the only similarity I see (between multi and community) is that there is somehow a list involved. Were you really talking about multireddits or are you building a concept of metacommunity around it but more similar to a community in some way ? (justifying the comparison)
So the way the content is added is the one of a multireddit, not a community.
And so is the content.
So to me it seems that your concept of metacommunity is identical to the one of multireddit rather than something you are making up. Please correct me if that’s wrong and explain how it’s different, that’s exactly the thing I’m trying to understand with this discussion.
So, if what I said above is correct, what you are doing is stripping a post of its body, title, community, comments down to a link, so that the community (now a mere list of links) can fit the comparison with a multireddit.
Federation
You need to federate the instances where the users are. Now Lemmy has only one kind of instance, for both communities and users. You propose a model where there are two (user-instance and community-instance), that’s interesting.
Community-instances would still be able to accept or reject the communities that they host, and that is not really about federation.
On the other hand, user-instances and community-instances would still be able to accept or reject each other.
Ok but communities about any kind of niche topic can be active, all you need is at least 2 users ready to publicly and regularly communicate with each other. In particular, being active does not require thousands of users, so is not bound to the big topics who already have pages on lemmy.ml.
Meta-community definition
You also cant add it to a meta-community, “the content” that is added is community links, not posts. Remember, that’s the main difference between meta-community and community. When you want to post something that isn’t a new community, you don’t post to the meta-community, you post to a community.
If you just make a community where every post is a link to a community (which in theory you can even do right now without any code changes, as long as you moderate it to be so), then conceptually you have already the data model of a meta-community. And doing this does not necessarily stop you from having moderation, comments, and everythign a community has (because it is a community, just one where each post references a community).
But of course to make it useful as a feed, you need to add a new interface where you can see an aggregate of the posts of the communities referenced (because the posts of the meta-community would be just references to communities). And a way for users to subscribe to that aggregate instead of (or in addition to?) the aggregate of references to communities.
However, this last thing is just a different “view”. Meta-community mods do not actively “manage” the posts/comments in that view (because it’s not posts/comments from their community), they only manage the posts/comments in their (meta)community (in which posts happen to be references to communities whose posts show in that “view”).
Multireddits are just a particular case of “meta-community” (one that does not allow user submissions or comments and has only one admin who submits/deletes entries, which is fine since the thing that makes it worth it is the aggregation of subreddits).
We are still discussing semantics on a particular made-up definition involving small details that don’t necessarily matter that much, imho. I don’t think we are going anywhere.
Federation
Well yes, but that’s not related to instance whitelisting, plus it’s a restriction totally valid.
Instances should not be forced to host content they don’t want to host. Imagine if a community is about sharing ilegal content (copyright-infringing stuff, child pornography, etc.) the instance could be held responsible if it knowingly hosts that content publicly and does not delete it, even if it was uploaded by other people.
This would be comparable to lemmy.ml accepting/rejecting accounts based on whether the account email is hosted in “gmail.com”, “hotmail.com” or whichever other third party service.
It’s true that user-instances and community-instances can block each other, but I think it’s less likely. I think whitelisting makes sense when instances have to serve or cache content from other instances, something lemmy does in order to federate. But if we stop federating and let clients access multiple instances directly (instead of each user accessing only one instance to access others through federation) then no instance has to serve content from instances that have content they dont want (or content that’s ilegal). They’ll no longer be responsible for the content from instances they federate with since it’s no longer offered through your instance. The user-instances in my example also do not serve content from other instances, so they are also very unlikely to see a need to block anyone.
Also note how the blocking in lemmy is not transitive (if A blocks B but not C, you still can access both A and B through C), this shows they are ok with people going to other instances that migth be more permissive in their allowlist, while still allowing those users to federate with lemmy. I suspect the primary reason for the whitelisting is to avoid actively participating in the distribution of content they don’t agree with.
Even if you really want to consider that level of activity (which shouldn’t really be significant when we are talking about communities that become centralized nodes on a topic for the entire network). The point was that the number of active topics is limited. Those 2 users can’t be active in an infinite amount of topics. At the end of the day the number of active topics is limited by the user engagement. And looking at reddit’s numbers, we can see that in a mature social network there’s much less active topics than active users (over a thousand times less!).
Remember the reason we talked about this: if you don’t duplicate communities then the fact that the amount of popular active topics is limited can lead to huge centralized nodes forming around the active communities.
Sure, but I never said lemmy.ml is the only instance that has active communities. I’m saying it’s where most of them are.
Ok so you do mean to incluse user submissions and comments, thanks ! That was not clear to me.
Now, if the idea is really to base the meta on a community, how is its list of communities established? I see two sensible options :
The admin can (un)pins posts, the links of the pinned post make up the list.
A upvote threshold decides which links are on the list. That way it’s really community driven.
Great! …but just in case there’s a misunderstanding: remember submissions in a meta-community are communities. We are not talking about posts with links/articles. In the same way, comments in a meta-community would be comments in relation to that submission (the submission linking a community, not a submission linking an url/article).
Each posted link/article from a submitted community in the metacommunity already has its own comment thread, which is independent of the meta-community existance and is already in the community the posted link/article belongs to. As discussed before, meta-communities have no authority over that.
I don’t necessarily think meta-communities need to allow user submissions (which would be communities) or comments (which would be on community submissions) to be useful. That’s why I didn’t see much point in discussing in this direction.
I just pointed out that they can have it (because you asked for it before).
Personally I think it should be possible to customize in each community which users are allowed to post/comment (if at all). I believe “private” communities is a planned feature too.
I feel we are still not understanding each other.
Note that one thing is “the submissions of the meta-community” (which each will be a reference to a community) and a different thing is “the submissions of the communities that are submitted to the meta-community” (which before I called “posts”… or to be more specific: urls/articles).
The former is moderated by the admins/mods in the meta-community. The latter is moderated by the admins/mods in the respective communities where the posts reside.
I imagine there would be 2 “views”. One that shows the list of communities in the meta-community (and optionally allows users to submit a new community and comment on those submissions) and another that shows the aggregated posts of the communities that have been submitted to the meta-community.
For this latter “aggregated view of the submissions of the submitted communities”, if you wanted to add additional control on what shows there then I guess you could have ways to add “weights” to each community. Maybe, for example, a combination of the number of upvotes to the meta-community submission for that community and the number of upvotes to the submission in the community submitted could be used to decide the order in which the posts show in the aggregate. You could also factor in things like number of subscribers if needed… that kind of detail on how urls/articles are aggregated is something that would require some experimentation to get right.
I think I pretty much inderstand you now. The point of my 2-item list was to draw a line between “communities submitted to the meta community” (which I also referred to as post in that part), and the ones who are actually part of the meta. I was thinking “cutoff” rather than “weight for appearance in the feed”, but the latter is also interesting !
That’s true if nothing is expected from the user-instance side. But for example a community-instance may expect from the federated user-instances that they ban user who are repetedly reported for bad behaviour.
This will be all the more true when Lemmy will federate with other fediverse platforms, such as Mastodon. There, there is a public user to user interaction and so it may be desirable to block the instances that allows undesired behaviours, because most users from there will make no difference and act the same way on Lemmy communities.
They serve content from the community instances to their users, whether they host it or not.
If you really want those instances to disappear altogether and the user accessing communities from client, we lose the feature of user-instances blocking users for all their members, and the members will have to block e.g. all nazis one by one.
They can form, true, but they can also stop growing at some point, as a result of either their own will, the new communities being created elsewhere or cpmmunities migrating elsewhere. In fact, shared communities also don’t prevent these instances to become bigger and bigger.
Of course I didn’t mean that litterally an infinity of communities will exist some day, just that there are way more topics than what is currently on lemmy.ml so there is a lot of room for other instances to grow.
Also, the limit of topic that they can discuss simultaneously is not the same as the global one, considering that new communities (dis)appear everyday. And sometimes one will create a new community instead of one that is dying, e.g. setting new rules that they think will improve it. Maybe creating a community on a new instance with different CoC.
Nothing should be expected from the user-instance. It should be designed to allow self-hosting your own. If you want to allow people to self-host their user-instance, you can’t trust that they’ll all behave exactly as you want.
I think an alternative approach if you really want to have bans from an instance carry to the rest would be having repositories of blocklists that are shared between community-instances.
If you really really don’t want to have blocklists, and you do want to rely on user-instances being trust-worthy… then well… I guess in that case the current federated model that uses whitelists makes sense. But then it’ll be a closed network, not comparable with open networks like XMPP / Matrix, where self-hosting is not only possible, but encouraged.
How do you define “serve”? To me a server is only serving the content that it provides as reponse to the requests done to it.
If I build a website that uses Google/Facebook as a login method (eg. via OAuth) that doesn’t mean that Google/Facebook is serving all the content in that website. The servers of that website are the ones that both host and serve the content. Google/Facebook is just used by that website as authentication method, but that doesn’t mean that Google/Facebook has any responsibility of the content of that website.
True, but I’m not saying that it’ll keep growing infinitelly (it won’t because the amount of active topics are limited).
My point is that lemmy.ml will continue being central to the network. The other ones can only catter to niche or novel audiences, since they are discouraged from duplicating the communities that have been already created in lemmy.ml.
It’s fine if you are ok with centralizing communities in specific instances but in that case I don’t see much of a point in federating, just do proper centralization of the communities without the baggage of having to federate across them. Decentralize the services that are meant to be decentralized (identity, search, notifications, etc). This gives more freedom for self-hosting and also makes it possible to reutilize these smaller services to reuse them in other projects outside of Lemmy.
I agree, but my point was never in conflict with that.
I already told you before that I don’t think lemmy.ml has all the topics, what I think is that it has most of the active ones and that I expect it’ll continue being the central lemmy node as long as the model continues being designed like this, without a cross-instance way to have topics that doesn’t penalize community duplication.
It’s up to each (user or community) instance to decide with whom they want to federate. It’s true that the user-instances typically wouldn’t have a clear identity in a platform like Lemmy where everything happens in communities, so it seems pointless to block a user-instance for a community-instance; in particular I don’t completely disagree with the statement that the communities cannot expect so much from the user instances in that model.
But when you think broader than Lemmy, the day it federates with other platforms, like Pixelfed or Mastodon, where interactions happen on the instance, then it has an interest to block instances who allows/encourages behaviours that you wouldn’t want to see reproduced in your communities.
That’s from the community instance perspective. From the user perspective, it makes sense to join a user-instance that already filters the communities that display unwanted behaviour, i.e. to join an instance who CoC is in agreement with your own preferences, and whose admins you trust to do that job properly.
This is not incompatible with federation. Users who want an instance doing some filtering job for them can, users who don’t can set up a 1-user instance. Now I’m not familiar with the technicalities of how to currently set up an instance, but if I’m right all one needs to participate in the federation without having an actual server running is an app that talks to the (community-)instance API as if it was a 1-user instance.
If you completely get rid of the user-instances that’s true. But actually, how different is that from having an account on each of the instances? In fact, how do you do if you want to access your subscribed feed from a web browser? If I understand correctly, assuming there is an appropriate webapp hosted somewhere on the internet, you need to communicate it each of the instances on which you have an account. And so if you are using a shared computer where you don’t want to save your connection data, you need to do it every time.
The user-instance is a service that hosts your preferences, and provides a front-end that serves content from various community-instances. You can do without it, but then you heavily rely on the client.
For me the point of the federation is not to forbid users to gather in some instances if they want to, but to give access to the service to those who don’t. It ok if most users/communities are on lemmy.ml, as long as they always have the choice to leave it and keep interacting.
It is not that clear to me whether storing the community in other servers really help decentralizing. If a community is on lemmy.ml and a smaller one, it is still on lemmy.ml. I’m not sure about how much you empower a small server by using it as a backup of the data that you have on lemmy.ml.
I know, that’s why I said “should”.
I’ll repeat what I said: If you really really don’t want to have blocklists, and you do want to rely on user-instances being trust-worthy… then well… I guess in that case the current federated model that uses whitelists makes sense. But then it’ll be a closed network, not comparable with open networks like XMPP / Matrix, where self-hosting is not only possible, but encouraged.
Not only did I never say or imply that federation is incompatible with self-hosting, I actually gave notorious federated protocols (XMPP & Matrix) as example of protocols that encourage self-hosting (unlike Lemmy).
And btw, those other projects actually make it a point to try and minimize the creation of big nodes (Matrix in particular is pushing hard to try and make matrix.org smaller, to the point that they are experimenting with a hybrid P2P model now). Imho, these are examples of federation done right. Lemmy, as it stands with its current design and whitelisting model, is not.
I don’t understand how did you reach the conclusion that I’d want to get rid of user instances. I don’t even understand why getting rid of user-instances would even make what I said true.
The Google/Facebook example was a way to showcase how user-instances do not serve the content, the same way Google/Facebook do not serve the content of the websites that use them as auth methods.
Ah. I see where there’s confusion.
I don’t think it’s required for the user instance to “provide a front-end that serves content from various community-instances”. That’s the job of the client software, not of the user-instance. The user-instance can be just a simple server that handles user accounts and nothing else. It could be theoretically used for other types of services, it might not even be that much related to Lemmy in particular. It might even be just an “OpenID Connect” instance, maybe with some customizations if required.
You could have client software that’s completelly web based, using localstorage to keep its local cache (in addition to the remote community-instance having its cache) without having the server who provides the webclient cache or serve any of the community content. An example of this is https://riot.im/app a Matrix client on the web that you can use to access any Matrix instance and consume content via sending requests directly to the instance where the content is hosted. riot.im is not the server, matrix.org (or whichever server you specify when connecting) is. The web client is not responsible of the content you access through it, because it does not serve nor host that content. And the user-instance also does not. Only the community-instance would be responsible of its own content, and because it’s not federated it will not need to take responsability of content hosted by other community-instances.
Of course the same server that runs a user-instance can have also a web client and can even run its own community-instance, all at the same time. But the point is that each of those is a separate module and they don’t really federate (as in, no two instances of the same type communicate with something that isn’t a service I can replace. And because they don’t federate and don’t cache third party content you remove the biggest reason to do whitelisting/allowlisting.
You are not leaving lemmy.ml if you are still consuming its content. You depend on it still. Interacting with lemmy.ml through a third party is just a way to use lemmy.ml. The difference between interacting with lemmy.ml directly is just a technical detail.
It does not give you much of real end-user advantage. The only difference is that the user details will be hosted in a difference instance, but you don’t need federation for that, as we have already discussed.