If you load /all, you will get posts from communities on a bunch of different servers. If you load your subscriptions, those communities still likely come from multiple servers.
Currently, lemmy.world, lemm.ee, and communick.news are running all the time, with random downtime due to issues/maintenance. When I log in to lemm.ee, I fetch the posts from lemm.ee, including any posts that may have been posted to lemmy.world and communick.news while I was logged out, even if both are down while I’m logged in.
I guess my main issue with your idea is that it will (IMO) encourage people to host more servers, which in turn could lead to communities being more spread out across servers, which will then make the experience worse since a client side implementation depends much more heavily on servers being available.
I guess my main issue with your idea is that it will (IMO) encourage people to host more servers
Why? If anything, I believe that it would be the opposite. Less “responsibility” on the servers would mean better capacity to scale and serve more clients on the same hardware and (if the identity is not dependent on the server and can be easily portable) it would mean less attached value to the server itself, so people wouldn’t care so much about “what instance they are joining”.
The best analog there is to what I am proposing is movim, and if you go take a look at their server list, you will see quite a limited amount of servers even though it has as many active users as Lemmy.
I really agree with your premise. Less responsibility on the server means less depending on it. We’d gain independence, could move accounts and do some more nuanced things. But I really think the less your own server or relay does, the more you’re prone to suffer from network outages, other servers becoming unavailable etc. So you’d need to duplicate everything no matter what to compensate for that. And you introduce lots of additional traffic by fetching all the hashtags from everywhere. Or you’d end up in the same situation as before where they’re subject of availability on your instance or perspective on the network.
Plus you want unsubscribed old posts showing up and a perspective that’s independant of the chosen instance. So you basically need to replicate everything everywhere. And this introduces additional complexity and resource usage and your goal was to reduce that. (And federation becomes just an inconvenience and additional unnecessary work at that point.)
It’s not that it’s technically difficult. We could do that. And you’re right by pointing at XMPP and Movim and stuff. But that also doesn’t solve most of the issues you outlined in your initial post. It’s even more narrow in how you rely on your own server and shaping your perspective on the whole network.
And sometimes this is what we want. People do dedicated instances to a topic. For example a Mastodon server for IT and tech people. Of course you want IT related stuff to show up on your main page. And we sometimes want moderation and a place to have civilized discussions. Not a place of anarchy and shitposting like on 4chan. That requires some form of hierarchy or democracy. And at the end of the day the server operators are responsible for what content is shared (publicly) via their infrastructure…
So I’d say you can’t achieve all your goals with ActivityPub. You need to think bigger. Maybe do away with federation altogether. Since federation is all about having different instances with a different focus and perspective on the same network. Maybe focused on a language or subject or sub-community of users, different rules and moderation. And you want more a unified perspective, everyone gets the same and less intermediaries. I’d say that is fundamentally incompatible with this form of federation and kind of out of scope. You probably want a network without that hierarchy. And that comes with different technical challenges and advantages.
(And suppose we extended ActivityPub. Instead of separating and moving stuff to the client, we could imagine you install a Lemmy or Mastodon server/instance on your computer or phone. Along your browser. You’d have it all on your device and could configure it like you wanted. I’m not sure if that’d be a superior solution.)
I feel like one of the issues with these “new plan for X” essays or posts is that readers usually interpret it as something to completely replace the status quo. It’s not the case. I’m not saying that everyone should start using this. I’m not saying that everyone should leave Mastodon. I’m not saying that all server-focused software using AP needs to go away.
I’m just saying that the current approach is not the only one and that Mozilla could have benefited from trying something different. I’m saying that Federation might be the right unit of organization for some cases, but that there is a whole world of possibilities where Federation is not so suitable.
I get it, it makes no sense to say that a network with 1M+ active users is “doing everything wrong” and that we need to start anew. I am not arguing the case to change those that are already here. I am arguing for changes that could help those that looked at “Federated Social Media” and went away because this model didn’t work for them.
Hmm, I get you. But I don’t think that’s what this discussion is about. I’m more concerned with the technical difficulties / impossibilities / inconsistencies with the approach. Less so if it should replace the current solution or a possible upgrade path. That’s something to worry about later. It’s more like I don’t think it’s going to work properly. It’s more combining the disadvantages of two different approaches.
But I’m happy if someone goes ahead and does a better approach. I also see the shortcomings of the current solution. Maybe I’m being too pessimistic.
Less “responsibility” on the servers would mean better capacity to scale and serve more clients on the same hardware and (if the identity is not dependent on the server and can be easily portable) it would mean less attached value to the server itself
To me, this makes it sound much more attractive to run a server, as it will be easier to do. Though I guess this is subjective.
If you load /all, you will get posts from communities on a bunch of different servers. If you load your subscriptions, those communities still likely come from multiple servers.
Currently, lemmy.world, lemm.ee, and communick.news are running all the time, with random downtime due to issues/maintenance. When I log in to lemm.ee, I fetch the posts from lemm.ee, including any posts that may have been posted to lemmy.world and communick.news while I was logged out, even if both are down while I’m logged in.
I guess my main issue with your idea is that it will (IMO) encourage people to host more servers, which in turn could lead to communities being more spread out across servers, which will then make the experience worse since a client side implementation depends much more heavily on servers being available.
Why? If anything, I believe that it would be the opposite. Less “responsibility” on the servers would mean better capacity to scale and serve more clients on the same hardware and (if the identity is not dependent on the server and can be easily portable) it would mean less attached value to the server itself, so people wouldn’t care so much about “what instance they are joining”.
The best analog there is to what I am proposing is movim, and if you go take a look at their server list, you will see quite a limited amount of servers even though it has as many active users as Lemmy.
I really agree with your premise. Less responsibility on the server means less depending on it. We’d gain independence, could move accounts and do some more nuanced things. But I really think the less your own server or relay does, the more you’re prone to suffer from network outages, other servers becoming unavailable etc. So you’d need to duplicate everything no matter what to compensate for that. And you introduce lots of additional traffic by fetching all the hashtags from everywhere. Or you’d end up in the same situation as before where they’re subject of availability on your instance or perspective on the network.
Plus you want unsubscribed old posts showing up and a perspective that’s independant of the chosen instance. So you basically need to replicate everything everywhere. And this introduces additional complexity and resource usage and your goal was to reduce that. (And federation becomes just an inconvenience and additional unnecessary work at that point.)
It’s not that it’s technically difficult. We could do that. And you’re right by pointing at XMPP and Movim and stuff. But that also doesn’t solve most of the issues you outlined in your initial post. It’s even more narrow in how you rely on your own server and shaping your perspective on the whole network.
And sometimes this is what we want. People do dedicated instances to a topic. For example a Mastodon server for IT and tech people. Of course you want IT related stuff to show up on your main page. And we sometimes want moderation and a place to have civilized discussions. Not a place of anarchy and shitposting like on 4chan. That requires some form of hierarchy or democracy. And at the end of the day the server operators are responsible for what content is shared (publicly) via their infrastructure…
So I’d say you can’t achieve all your goals with ActivityPub. You need to think bigger. Maybe do away with federation altogether. Since federation is all about having different instances with a different focus and perspective on the same network. Maybe focused on a language or subject or sub-community of users, different rules and moderation. And you want more a unified perspective, everyone gets the same and less intermediaries. I’d say that is fundamentally incompatible with this form of federation and kind of out of scope. You probably want a network without that hierarchy. And that comes with different technical challenges and advantages.
(And suppose we extended ActivityPub. Instead of separating and moving stuff to the client, we could imagine you install a Lemmy or Mastodon server/instance on your computer or phone. Along your browser. You’d have it all on your device and could configure it like you wanted. I’m not sure if that’d be a superior solution.)
I feel like one of the issues with these “new plan for X” essays or posts is that readers usually interpret it as something to completely replace the status quo. It’s not the case. I’m not saying that everyone should start using this. I’m not saying that everyone should leave Mastodon. I’m not saying that all server-focused software using AP needs to go away.
I’m just saying that the current approach is not the only one and that Mozilla could have benefited from trying something different. I’m saying that Federation might be the right unit of organization for some cases, but that there is a whole world of possibilities where Federation is not so suitable.
I get it, it makes no sense to say that a network with 1M+ active users is “doing everything wrong” and that we need to start anew. I am not arguing the case to change those that are already here. I am arguing for changes that could help those that looked at “Federated Social Media” and went away because this model didn’t work for them.
Hmm, I get you. But I don’t think that’s what this discussion is about. I’m more concerned with the technical difficulties / impossibilities / inconsistencies with the approach. Less so if it should replace the current solution or a possible upgrade path. That’s something to worry about later. It’s more like I don’t think it’s going to work properly. It’s more combining the disadvantages of two different approaches.
But I’m happy if someone goes ahead and does a better approach. I also see the shortcomings of the current solution. Maybe I’m being too pessimistic.
To me, this makes it sound much more attractive to run a server, as it will be easier to do. Though I guess this is subjective.