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.
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.
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.
I donāt understand how Lemmy protocol encourages to not self host. Iām not much familiar with Matrix, but to me it seems that the only difference is that a Lemmy community is only hosted on one instance while a Matrix room is duplicated on each of the usersās home server.Thatās probably very naive, but wouldnāt it mean that in practice one would need more memory to self host a Matrix 1 user-instance?
If itās about the fact that it uses whitelisting instead of blacklisting, I already told you that Iām also in favor of the latter. But this should only have impact on the time it takes to federate, not on the state of an instance once itās set up. After all, the only difference is that the other instanceās owner needs to press āokā before federating.
I think we misunderstood each other about what āmanaging a user accountā means. I define the user-instance as a server where the user has an account, and who federates with the appropriate community-instances so as to serve their content to the user.
Note that I mistakenly used the word āfrontendā here, but I never thought that this instance was the same as the client. Sorry about that ! In your Matrix example, matrix.org is definitely what I would refer to as the user-instance.
I noticed later that by āmanaging a user accountā you probably only meant āprovide an ID who allows to avoid setting up a new passwordā. Is that right? That thing is not an āinstanceā of the networking software, as it doesnāt know anything about the software in question, and only provide some kind of token that allows to create an account on the community instance in question. (the account may be as simple as a pseudonym and a reference to the ID, but may also possibly contain additional info or keep track of the userās activity on the instance)
This brings me back to my previous comment. Say the user-instance (as defined above) is replaced with a simple ID-provider, and serving the content from the community instances becomes the clientās job. This means that you donāt have a cross-instance profile anywhere on the internet, and need to manually connect to any instance where you have an account each time you connect on a new machine. Right?
Now it seems to me that you not wanting user-instances (I still think you donāt want them if they are defined as above, but please correct me if thatās wrong !) is one of the reasons why you would invoke meta-communities as a way to keep track of a cross-instance list of communities.
Again, I donāt agree thatās the main reason, but we discussed that already.
Sure, but remember that white/blacklistings on the Fediverse are not transitive. So I can federate with both lemmy.ml and with other people who are on instances that donāt federate with lemmy.ml. Unless some instances federate only with lemmy.ml, one is never incentivized to stay on lemmy.ml if they want to leave it.
Note that this also works in the context of your original proposal of cross-instance categories : if you follow a category that is open to lemmy.ml, most content that you consume there will come from lemmy.ml. In fact, except if your instance blacklists lemmy.ml. But Iām not sure about why stopping to interact with the biggest instance would become a goal per se.
I donāt like whitelisting either, but if I opened my own instance with the current state of things, I would actually apply whitelisting on my server myself to limit what I federate with.
The problem is that the way the federation works in Lemmy would force my instance to cache and publicly serve content from any server it federates with. And I donāt want to host illegal content and get in trouble.
So the issue is that whitelisting is the only way to safely host a lemmy instance without requiring close eye maintenance. This is what I see as the biggest problem.
If itās that simple, the whitelisting would not be very useful to protect against bad instances. Itāll either be inefficient (if not enough control is applied) or be a burden (if too much control is applied). The line that divides those two is diffuse and itās likely weāll get both false negatives and false positives, so thereāll be mistakes either way, ending up both being a burden and inefficient.
It also complicates things to add a human factor to the process of setting up your instance. Youāll have to do some public relations with the other instances and the other instances might want to keep an eye on your instance which adds to the maintenance burden, specially if lemmy ever becomes popular and it ever reaches numbers in the hundreds of instances.
With an email server or an XMPP server, self-hosting is enough to communicate with everyone. But with lemmy Iāll have to do work for every instance, at that point why not just create an account in that instance, which might actually be instantaneous. Iād rather make a multi-account client that abstracts my identities as if they were one instead of hosting my own server to have control of my identity.
It would defeat the whole point if I meant for the user management instance to federate with instances of its own class. This whole branch on the conversation thread was about me wanting to explore the idea of federation not being needed to do what Lemmy is doing right now, that instead of federating you can separate the services in a more āmicroserviceā-ish like model (but not as extreme), making it not only simpler but also more modular and reusable.
Yes, more or less. Itād act as an authentication server (I explicitly linked OpenIDās wikipedia page right after mentioning āuser account managementā) and itād also allow users and its sessions to be created/removed/edited (again, thatās what āmanagingā means when we talk data). Any operation that related to the user and not the content. It does not view/add/remove/edit (manage) any kind of community content, that would be content management, not user management.
Not necessarily, there could be user metadata stored in the user service. Things like name, profile, personal websiteā¦ but also what instances the user has a token with. I expect the token exchanged is long lasting so the user-instance needs to keep track on its side about this already anyway. Much in the same way as how Paypal keeps āauthorizationsā for websites the user has allowed payment to be automatic, the user-instance would allow the client to know of those websites and be able to access them with the token without manually having to connect (done from whatever the client is, without serving the content). Also the notifications system could be part of that instance, or it could be its own separate service entirely.
Thatās the kind of instance Iād be happy to self-host, because itāll be mainly personal data related to my user. Iām not so interested in hosting communities.
Itās the other way around. Donāt you remember what started this āfederationā topic?
To me cross-instance ātopicsā (either tags or meta-communities) would be the one thing that would make federation useful. Without that, I donāt see the benefit of federation. Which is why I was talking about separating the user management (and notifications) from the content management, so that you can achieve shared accounts without having to federate.
Sorry if Iām repeating myself (I think Iāve said that same paragraph in almost every comment, with different words) but I donāt know how else to explain it.
Again: āYou are not leaving lemmy.ml if you are still consuming its content.ā
If you are using the non-transitive property to consume lemmy.ml content, then you are not leaving lemmy.ml, even if you are connecting to it through a different instance. Even if you donāt have an account in lemmy.ml, you did not really left it. Since we donāt have a cross-instance ātopicā to subscribe to, and since you donāt want āduplicatedā communities, you have to keep relying on lemmy.ml as the central node where most of the active communities are.
It doesnāt have to be a goal.
But in that case just embrace the centralization of those communities, whatās the advantage of federating? The things you want to share cross instance, share them by having a separate service handle them. Only if thereās a reason to have community-servers directly communicate with each other (eg. cross-instance ātopicsā) does federating across them become useful, imho.
So you say that as soon as you create an instance, everyone can see its frontpage, and that there is no way to create an instance where the only thing that outsiders can access is your profile? That would solve your public serving problem, right?
What other difference are there?
Ok I was probably wrong in saying āsetting upā there, as if you had to decide on day one what you federate with. How it would actually work is that you can vet any new instance that you encounter (e.g. via a crosspost, or via a new community there that is announced on some instance you already federate with) before sending it a federation request, that it then would have to accept.
In fact, do you know what happens when a user from an instance that I donāt federate with comments a post that I see? Is it simply hidden? Does it say ācomment from remote instance hiddenā? Or does my instanceās admin receive a suggestion to federate with them? Or maybe in Lemmy federation is only about which communities I can access, but doesnāt hide comments from unfederated (with me) instances?
Filtering the content a user has access to and constructing their frontpage can be seen as part of managing their account. As I said, we misunderstood each otherās definition of managing the user account, thatās ok.
We said already several times, federation also offers the advantage of being able to delegate filtering tasks to the instance you register on. Each user doesnāt have to allow/block each (community-)instance by themselves, but can leave that to an instance admin that they trust.
It also allows the instance to store its usersā history (or outbox in activitypub language).
If the content is served to you by your user instance, it also means to donāt have to communicate with the community-instance every time you want to read content from it. This means that the community-instance cannot track your (passive) activity, which I think is also valuable.
What about crossposting?
Again, the federated network can have one-user nodes, but federation offers the possibility to delegate tasks that you donāt want to do yourself.
Again, you can completely leave it in the sense you mentioned by registering on an instance that doesnāt (plan to) federate with it. So you can leave it, and keep interacting with the rest of the network, the part that interacts both with you and with lemmy.ml.
(This is of course not the only acceptable definition of āleavingā in that context. Isnāt one user closing their gmail account to register with another provider leaving it? Would you say āyou donāt leave gmail if you can still consume content from itā?)
Yes, essentially. Itās too much of a problem having to publicly host content from other peopleās instances that you might have not much control on, unless you activelly monitor them constantly, which is why I think it makes sense lemmy instances use whitelisting. Even if whitelisting is an obstacle in federation.
However, you cannot do what you proposed to solve the same problem when it happens in community instances. As long as community instances federate, whitelisting is the safest option. This is why I propose they should rather not federate among themselves.
Between whitelisting vs blocklisting? Iām not sure if there are any other significant differences than what we already discussed.
As far as I understand, instances are unaware of what instances not in the whitelist might have commented, because they do not host that content. In the words of a lemmy dev: " your instance may not show posts or comments in a remote community if the authorās instance is blocked. Votes are also not counted from blocked instances " ā¦I expect this means the comment will simply not appear at all, but I havenāt tested.
And I already answered that this can be done with shared blocklists. Anything you want to share, see if it can be made made independent, instead of assuming cross-instance federation is the only way.
Canāt the feed just reference to community content hosted in community servers without having to host the content itself? The client may load that content in the feed requesting it from the community servers directly, without it having to be cached in the user-instance.
Or, alternatively, request separately the history feed for each community instance the user has interacted with within the given timeframe (the user instance should know which ones) and merge their history client side.
You can already do that client-side. The client can cache all the requests on local storage so it doesnāt request the same data every time it wants to read it. This actually was suggested by one of the lemmy devs before.
The network will be significantly crippled though, since most active communities are on lemmy.ml.
If gmail has a significant majority of the network of email and you still have the need to communicate primarily with gmail accounts, then yeah, you still depend on gmail, even if itās not who hosts your email account. This gives a lot of power to gmail over the email protocol, even if you donāt have a google account, your emails will get into googleās hands.
Imho, one of the points for federation is trying to avoid depending on big central nodes. If one node is down, disappears or becomes āevilā, the impact is not as big as long as the federated network is well balanced.
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 !