Liwott

Or troll back.

Don't. All you will do is legitimate trolling as a activist method

I do understand that, but forbidding everyone to answer the thread seems like a radical solution for this mild problem. Maybe a more appropriate solution would be highlighting the age of the post and of the last comment.

Worst yet, it's probably less likely you'll gain any responses from the same people that have posted in a thread long ago or from anyone really.

The person commenting an old thread should be aware of that, so I don't see what forbidding them to comment helps with.

It also depends how a newly commented post is highlighted in usrrs' feed.

Why should they?

I see, thanks !

Nice ! What metrics do the node and line size represent?

I think the problem is that this global vision of transportation is quite a long term one, so the politicians who need to be reelected within half a decade will tend to fund the issues that concern more people

I also think we are coming close to the end of this nice but long conversation.

We both understand that what a user instance does can be done by several small services. The latter gives you more control, but the former gives you administrative simplicity. I guess which one is desirable is a matter of taste. It may be nice indeed if it was possible to do those things separately, but there would still be combined offers.

There's also the question of whether the community instance need to serve the user instance (name we give to the above combination of services) or directly to the client. The advantage of the former is that the community instance doesn't know anybody checked the content in question, as it was regularly served to the user instance (from what I understand fron activitypub, the content is sent to the instance with the indication of who can access it). As you point out, the request may not need authentification, which makes it less dramatic, but I'm sure data recombination can get creative.

Note that aside from the theoretical question of which is the best protocol, being able to talk to a user instance is necessary if Lemmy wants to connect with the rest of the fediverse someday.

A disadvantage of federation is that one may end up serving undesired content. You mention whitelist as a crucial point here, but again it only changes the speed of connection with unknown servers, thereby only helping when discovering evil instances. When a trusted instance turns evil, it really doesn't change anything. So the usefulness of whitelisting depends on the rate of appearance of new evil instances. I don't know how much it is in practice, but that most of the fediverse use blacklist might indicate it's not that dramatic.

As long as community instances federate, whitelisting is the safest option. This is why I propose they should rather not federate among themselves.

Of course, I agree that if we separate community instances from user instances, there is no need for community instances to federate with each other. They only need to federate with user instances.

In turn, user instances may or may not federate with each other. That's the rest of the discussion. If they don't, it means there is no user-to-user interaction independently from communities, right? For example no direct message feature.

Anything you want to share, see if it can be made made independent, instead of assuming cross-instance federation is the only way.

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.

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.

Maybe true if you want to check a specific content, what I mostly meant was that if you want to check an updated community feed, the community instance is aware you do that request. The user instance is an intermediate who doesn't have to tell which user is checking the feed.

But even for the former use, it is not always true : what if you are using a webclient from a shared computer?

Can’t the feed just reference to community content hosted in community servers without having to host the content itself?

First, same argument as before : you need to tell every community instance in you subscription that you are checking your history.

Also, that means basically that you lose your own content when that instance shuts down.

For this latest two points, the idea is really that you can trust a single (ideally small scale) user-instance instead of vetting each community instance that hosts content that you are interested in. Can be useful if most communities are on an instance that one day turns evil :)

even if you don’t have a google account, your emails will get into google’s hands.

Not negating that.

Not having an account is still an advantage though, as google doesn't know anything about what you exchange with people who don't use it. Federation allows you to

• get that level of "leaving the main instance"

• keep in touch with people still on the main instance

• keep in touch with people who completely left it, without exposing them to it.

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.

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?

If it’s that simple, the whitelisting would not be very useful to protect against bad instances.

What other difference are there?

It also complicates things to add a human factor to the process of setting up your instance.

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?

It does not view/add/remove/edit (manage) any kind of community content, that would be content management, not user management.

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.

To me cross-instance “topics” (either tags or meta-communities) would be the one thing that would make federation useful.

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 are not leaving lemmy.ml if you are still consuming its content.”

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"?)

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

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

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.

And because they don’t federate and don’t cache third party content you remove the biggest reason to do whitelisting/allowlisting.

Again, I don't agree that's the main reason, but we discussed that already.

You are not leaving lemmy.ml if you are still consuming its content.

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.

Nothing should be expected from the user-instance.

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.

It should be designed to allow self-hosting your own.

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

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.

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.

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.

without a cross-instance way to have topics that doesn’t penalize community duplication.

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.