• 0 Posts
  • 59 Comments
Joined 7M ago
cake
Cake day: Feb 15, 2021

help-circle
rss

I got all excited because I thought it was a new Matrix client designed to be more Discord-like (using Matrix Spaces and so). But I was disappointed when I discovered it’s implementing yet another different protocol (it’s not even federated?)…

They do have a Matrix bridge though. I do hope they come together and further work with Matrix, since I believe the Matrix protocol can do most (all?) of what they are already doing, it’d be easier to migrate discord communities to Matrix if the UI transition was as seemless as it seems to be with Revolt. Revolt could have potential to be the host of a new big Matrix instance to further move people away from depending on matrix.org central instance.

I guess if they do have an officially maintained Server-to-server bridge then it would be equivalent of it acting as a Matrix instance. And that would be great. But it’s unclear if that’s what they are doing / planning to do. The Matrix website claims to not be aware of any server-to-server bridging having been done before, which makes me think Revolt might be doing a “bridge bot” bridge (can someone confirm?), which wouldn’t be as interesting.


If done well it could also boost the local economy. A lot of money in the Software industry goes to huge multinational companies outside of the EU or residing in tax havens.

I wish one day the EU wakes up and starts building its own Google equivalent but based on Free Software. I’m afraid it won’t happen in my lifetime, though.


What the email provider snitched is the IP address (which wasn’t “tori-fied”). So it was anonymity what was compromised in this case.

The email was openly used for activism so the police was already investigating it, they only wanted to know the identity of the physical person behind it, and that’s what ProtonMail helped with, since the activist didn’t use anonymizers. The police didn’t need to decrypt the contents of the account or compromise its privacy (which is what using ProtonMail would have protected against), just its anonymity.


Sure, someone can have high standard for privacy and at the same time have no desire for anonymity. But what was compromised in this case is the identity of the person who owns the email. The email remains private, just not anonymous.


Yes, Tor is another example of a “new layer” on internet routing (I2P functions the same, you can also use it to access the clearnet if you know an exit node). VPN would be fine if you could trust the provider, but imho that’s just shifting the trust to some other company, more of a patch rather than a proper solution to online anonymity.


“Private” and “Anonymous” are different things.

You can protect privacy with encryption, and I believe ProtonMail does work for that, but trying to protect anonymity is an entirely different beast. I’m not convienced it’s possible at all in any way that’s reliable (not just email but also even simple web browsing) unless there’s a change in how routing works in the internet, or a new layer is developed (like I2P, but even that’s not really a warranty).


They should have done it for Minetest, Terasology or any open source Minecraft alternative so their work can truly serve the community.


But it’s not that easy. Having a “discussion around whether abuses occur” implies allowing being apologetic towards those acts which might be abusive.

I’m sure fascists don’t think of fascism as abusive, even if it is. Would you allow discussing that?

At some point you need to set a clear dogmatic/axiomatic definition of what’s not allowed (with examples from different geopolitical positions) and don’t allow anyone to put that in doubt, abiding by that definition should be part of the rules.

Of course this makes it much harder to discuss things openly, but that’s the price to pay if you want to have a rule that claims zero tolerance.


To be honest, I’m not a big fan of Twitter-like services (I find there’s way too much noise in such feeds), so I never really explored the Fediverse surrounding activitypub too much. Any criticism I have on Lemmy current structure is likely to extend to other parts of the Fediverse where similar approaches apply. So I guess you could see my points as rants on that approach for public cross-publishing in general, rather than Lemmy in particular. I guess I picked the target I feel the most interest towards and that I think has the most potential to become something I could use a lot.

If Mastodon (and the activitypub fediverse in general) has the same approach of cross-publishing and forces instances to serve the content from third parties, I think it’s risky that they don’t have a stronger policy towards whitelisting that imposes a tight control over what instances are allowed to have their content served through them, imho it’s asking for trouble to appear. So I think whitelisting was a justified approach in case of lemmy.

In my mind, the issue with whitelisting/blocklisting is the limitation on the reach of the federation. People would have to create multiple accounts to access networks that don’t federate, rather than using one account that can access it all. It makes sense for an internet forum to ban users, block them. But it would make no sense for an internet forum to explicitly block their (legit) users from visiting other forums.

So, ideally, it would be best to find a solution that allows users to access any instance that’s technically compliant with the protocol without having to impose the burden on each instance host to carry responsibility for the content of other instances.


So you claim there should be a separate service for each community-independent feature : one for providing ID, maybe one for DM, one for sharing blocklists, … That is indeed another way to do it, I don’t think I ever claimed federated user instances was the only one. It is still one way, and it has its own disadvantages but also advantages over the one you advocate for.

Yes. That’s the gist of it. I feel we are reaching an understanding, I’m hoping our comments will start getting smaller :P (although I do enjoy the conversation).

Also note: imho, there’s a big difference between serving content through federation for 1-on-1 private communication that can be encrypted end-to-end where not even the server knows what data is being exchanged, and hosting public content for everyone to see. I suspect this is why XMPP / Matrix can more easily federate openly without leaning towards whitelisting. This is why I’m not so worried about 1-on-1 conversations. In fact, just use XMPP/Matrix (or even email!) for private communication, no need to reinvent the wheel. The user-instance could even just be an XMPP/Matrix server and make use of their pubsub layer for the notifications on new replies.

what I mostly meant was that if you want to check an updated community feed, the community instance is aware you do that request

This is true, but there can be ways to mitigate that too. If the community is public, the API to retrieve the community feed doesn’t need to be authenticated, you might only need to authenticate the request if you want to submit content or if the community is private. And in both of those cases, even if there was an intermediary, I expect there should be a way for the original instance that hosts the community to make sure the user has the rights to do that operation on their instance, so they would have to know either way.

They still can know your IP, but that’s a different level and using the same IP doesn’t mean you are the same person. Specially when using shared computers or moving around. And you’d still have that issue if you host your own user instance to cache your accessed content.

Personally I don’t have a problem with the community-instance knowing I’m accessing the content, specially if that’s the cost of mitigating whitelisting. After all, the whole internet works this way already.

My motivation for federation is in the decentralized and open nature of it. I’m ok with having data (as well as knowledge of me accessing that data) across smaller servers, because as long as they are small and I don’t use them primarily, they won’t be able to know what I do outside of their domain, only what I do when accessing that server. The issue is when not only there’s one predominant server hosting most of the content, but also there’s whitelisting that makes federating with it and self-hosting troublesome.

Not having an account is still an advantage though

That depends on what you compare it with. The 3 points you enumerate can be done without needing communities to federate among themselves.

Note that in this section of the conversation we are not comparing “closed walled gardens” vs “federation”. The point we were discussing in this branch of the conversation was: would it be bad if one instance (ie. lemmy.ml… or gmail.com for email) is central to a substantial majority of the activity?

When I said “embrace the centralization”, I didn’t mean making it a walled garden, I meant replacing the federation between communities with shared services. With user accounts being shared it wouldn’t be any more of a closed network than it already is (it might actually be less closed if it leads to removing whitelisting). I’d mean communities will be accepted as a centralized aspect that lives in one instance, even if other aspects (like user accounts) are decentralized. Essentially this would remove pressure from the community instance to have to serve third party content since that’s the requirement for federation. And with that pressure removed, I think there’s much less of a reason to do whitelisting (the only reason left would be avoiding toxic users, but that can be done in other ways as discussed, or at the very least the whitelisting could be limited to content submission rather than content access, so you don’t need to create different accounts for accessing different networks that don’t connect with each other).

The alternative to “embracing the centralization” is actually pushing for decentralization. Trying to fight the social snowball effect that might make big instances more attractive to use than small ones and implementing more cross-instance ways to access the content so that the system is more decentralized. Attempt to minimize the impact of a community “belonging” to one instance, so that smaller communities in smaller instances can compete for user attention in fairer conditions.


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?

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.

What other difference are there?

Between whitelisting vs blocklisting? I’m not sure if there are any other significant differences than what we already discussed.

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?

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.

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.

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.

It also allows the instance to store its users’ history (or outbox in activitypub language).

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.

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.

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.

Again, you can completely leave it in the sense you mentioned by registering on an instance that doesn’t (plan to) federate with it.

The network will be significantly crippled though, since most active communities are on lemmy.ml.

Would you say “you don’t leave gmail if you can still consume content from it”?

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.


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.

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.

the only difference is that the other instance’s owner needs to press “ok” before federating.

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.

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.

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.

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?

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.

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?

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.

Now it seems to me that you not wanting user-instances […] is one of the reasons why you would invoke meta-communities as a way to keep track of a cross-instance list of 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.

Unless some instances federate only with lemmy.ml, one is never incentivized to stay on lemmy.ml if they want to leave 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.

I’m not sure about why stopping to interact with the biggest instance would become a goal per se.

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.


It’s up to each (user or community) instance to decide with whom they want to federate.

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.

This is not incompatible with federation.

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.

If you completely get rid of the user-instances that’s true.

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.

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.

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.

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.

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.


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.

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.

They serve content from the community instances to their users, whether they host it or not.

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.

They can form, true, but they can also stop growing at some point

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.

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.

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.


Ok so you do mean to incluse user submissions and comments, thanks ! That was not clear to me.

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.

how is its list of communities established?

  1. The admin can (un)pins posts, the links of the pinned post make up the list.
  2. A upvote threshold decides which links are on the list. That way it’s really community driven.

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.


Meta-community definition

So the way the content is added is the one of a multireddit, not a community.

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

Community-instances would still be able to accept or reject the communities that they host, and that is not really about 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.

On the other hand, user-instances and community-instances would still be able to accept or reject each other.

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.

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.

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.

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.

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.


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

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.

The difference is that the users don’t need to register on the instance where the community is going.

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.

federation allows local users to interact with remote users and communities

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.

Define “actually useful”.

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”.

Do you thing lemmy.ml already has all of them?

No.


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.

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.

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.

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.

To gather an audience big enough for what?

Enough to be actually useful/used. Reddit has 1.2 billion subreddits but only 138k are active. And they have 430 million monthly users.

There is an infinite amount of topics, and there are also several communities that can be constructed around the same topic

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.


So no, a multireddit cannot be seen as meta-communities in the sense that you mentioned.

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.

a popular enough multireddit can have indirect (sorry if that was not clear enough) power over the content of the sub.

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.

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.

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.

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).

Exactly. That’s the problem. That’s why I doubt we’ll ever see lemmy.ml stop being the main instance.

In fact I do see one reason : to allow people from an instance ( C ) that does not whitelist instance A to join the meta-community.

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.

If the new communities are created on other instances. I don’t really see the need for duplicating the existing communities.

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.


“managing” doesn’t mean the same thing

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.

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.

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.

One can subscribe to a community on another instance

That’s what I mean by manually tracking each instance. You have to manually subscribe to a separate community for each instance.

that’s two communities that one has to subscribe to, but that’s a one time operation, right?

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.

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?

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.

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 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).