That’s a nice idea but has some pretty obvious technical drawbacks that aren’t discussed in the blog article:
The complexity of most networks grows about exponentially with the number of connections between the entities. It gets immensely more computationally expensive that way and you’re bound to use lots of additional network traffic and total cpu power that way.
And some (a lot of) people like using social media on their phones instead of a computer. You’re bound to drain their batteries real fast by moving application logic there.
Other than that I like the general idea. The Fediverse should be more dynamic. Caching and discovery have some big issues in the current form. That should be tackled and we need technical solutions for that. And the current architecture isn’t perfect at all.
Furthermore, if talking about the edge where networks are smarter… Why then move it into the browser which isn’t at the edge? Wouldn’t that be an argument to invent edge-routers like in edge computing? I mean with c2s you have a server on the one side and a client on the other side with the edge somewhere in between. If you now flip it you end up in a different situation. But there’s still nothing at the edge where you could introduce some smarts…
And some (a lot of) people like using social media on their phones instead of a computer. You’re bound to drain their batteries real fast by moving application logic there.
Messaging applications (that need to be online all the time) don’t have this issue. Mobile email clients are even more conservative in resource usage. Why would an AP client be any different?
You are not going to be transcoding video or executing complex machine learning analysis on the device. I can reasonably argue that a local-first AcvitityPub application would be no different in resource usage than something like a modern XMPP or Matrix client.
A Matrix app connects to a Matrix server, same for XMPP and email. Sometimes they might connect to a few more for extra accounts.
An AP client in the way you’re describing will need to connect to thousands of servers (at least). The whole point of federation is that you get content from a large network but through a single source.
So does a web browser. So does a mobile Lemmy client like Jerboa. “Connecting to thousands of servers” doesn’t mean anything, if these connections are sporadic and uncorrelated.
When you first sign up to a account, you might be greeted with a list of recommended users to follow. This list can be configured by the server admin, but in any case it will only be able to show you accounts that are from the same server as yours or from a server that already “federates” with it.
How will you get a list of users on different servers without connecting to them?
When you run a search query, you are running the query through the server, and again the results are only a reflection of the data that has been “seen” by the server.
Changing this will require the client to search through a bunch of servers itself, or use a 3rd party search engine.
The “trending hashtags” feature only works for tags that have been explicitly approved by the instance admin.
How will you get trending hashtags from servers without connecting to them?
The server provides different sorting methods for posts and comments, such as “Hot”, “Active”, “Newest”, etc. There is no way for the user to define their own sorting method.
How would you fetch posts, their score and comments from servers without connecting to them?
How will you get a list of users on different servers without connecting to them?
In the same way that a RSS reader knows which feeds to download?
Changing this will require the client to search through a bunch of servers itself, or use a 3rd party search engine.
Yes, but the 3rd party search engine can be specialized. It could be a service that indexes all of the fediverse, or it could be a “standard” search query with some special operators.
How would you fetch posts, their score and comments from servers without connecting to them?
Your application will already receive updates from the communities you are subscribed to. In the case where you want to browse by /all, then yes, on first load your client will be making a bunch of queries to different servers that have communities to get a list of updates. But this would be an issue only on first load, because subsequent queries would be “give me all events that happened since the last time I visited”.
But if you really don’t want to run this on your device, then how about this: someone develops a “client” which is actually an aggregator of all the different instances which can then be used as web service that provides an API for end-users. This way, we still get to enjoy a distributed system, we still have a client-first application and we also get the benefit of having a service that makes it easier for the people who think that “federation is too complicated for non-techies.”
In the same way that a RSS reader knows which feeds to download?
I meant how will you fetch a list of users from which you could generate recommendations.
Yes, but the 3rd party search engine can be specialized. It could be a service that indexes all of the fediverse, or it could be a “standard” search query with some special operators.
I guess with proper integration for different search engines (or maybe just something like Searx) this could be useful.
Your application will already receive updates from the communities you are subscribed to. In the case where you want to browse by /all, then yes, on first load your client will be making a bunch of queries to different servers that have communities to get a list of updates. But this would be an issue only on first load, because subsequent queries would be “give me all events that happened since the last time I visited”.
Currently a Lemmy app loads all posts from a single server (which in turn, aggregates posts from different servers), and then loads stuff like images from their respective hosts. With your suggestion, every post might come from a different server, any of which might be temporarily down (not uncommon unfortunately). Caching will make this issue and the other issues less severe, but it won’t solve them.
I don’t disagree with the idea BTW, I just honestly think it’s not practical (at least with ActivityPub).
With your suggestion, every post might come from a different server.
Why? Take our interaction, for example. the community is on lemmy.world, you are on lemm.ee and I’m on communick.news. My response generates an activity that is sent to LW, and LW then announces that activity to all the servers who have at least one subscriber. If LW went down, you wouldn’t be able to see this message until it came back up and it started processing the federation queue again. Right?
The same thing would happen in a “message-relay” system. My client would send a message to LW, and LW would then send the activity to lemm.ee, which would then “push” it to you. If any of the servers went offline, the whole process would stop at the node that is offline and would then resume when it came back up.
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.
That’s a nice idea but has some pretty obvious technical drawbacks that aren’t discussed in the blog article:
The complexity of most networks grows about exponentially with the number of connections between the entities. It gets immensely more computationally expensive that way and you’re bound to use lots of additional network traffic and total cpu power that way.
And some (a lot of) people like using social media on their phones instead of a computer. You’re bound to drain their batteries real fast by moving application logic there.
Other than that I like the general idea. The Fediverse should be more dynamic. Caching and discovery have some big issues in the current form. That should be tackled and we need technical solutions for that. And the current architecture isn’t perfect at all.
Furthermore, if talking about the edge where networks are smarter… Why then move it into the browser which isn’t at the edge? Wouldn’t that be an argument to invent edge-routers like in edge computing? I mean with c2s you have a server on the one side and a client on the other side with the edge somewhere in between. If you now flip it you end up in a different situation. But there’s still nothing at the edge where you could introduce some smarts…
Messaging applications (that need to be online all the time) don’t have this issue. Mobile email clients are even more conservative in resource usage. Why would an AP client be any different?
You are not going to be transcoding video or executing complex machine learning analysis on the device. I can reasonably argue that a local-first AcvitityPub application would be no different in resource usage than something like a modern XMPP or Matrix client.
A Matrix app connects to a Matrix server, same for XMPP and email. Sometimes they might connect to a few more for extra accounts.
An AP client in the way you’re describing will need to connect to thousands of servers (at least). The whole point of federation is that you get content from a large network but through a single source.
So does a web browser. So does a mobile Lemmy client like Jerboa. “Connecting to thousands of servers” doesn’t mean anything, if these connections are sporadic and uncorrelated.
How will you get a list of users on different servers without connecting to them?
Changing this will require the client to search through a bunch of servers itself, or use a 3rd party search engine.
How will you get trending hashtags from servers without connecting to them?
How would you fetch posts, their score and comments from servers without connecting to them?
In the same way that a RSS reader knows which feeds to download?
Yes, but the 3rd party search engine can be specialized. It could be a service that indexes all of the fediverse, or it could be a “standard” search query with some special operators.
Your application will already receive updates from the communities you are subscribed to. In the case where you want to browse by /all, then yes, on first load your client will be making a bunch of queries to different servers that have communities to get a list of updates. But this would be an issue only on first load, because subsequent queries would be “give me all events that happened since the last time I visited”.
But if you really don’t want to run this on your device, then how about this: someone develops a “client” which is actually an aggregator of all the different instances which can then be used as web service that provides an API for end-users. This way, we still get to enjoy a distributed system, we still have a client-first application and we also get the benefit of having a service that makes it easier for the people who think that “federation is too complicated for non-techies.”
I meant how will you fetch a list of users from which you could generate recommendations.
I guess with proper integration for different search engines (or maybe just something like Searx) this could be useful.
Currently a Lemmy app loads all posts from a single server (which in turn, aggregates posts from different servers), and then loads stuff like images from their respective hosts. With your suggestion, every post might come from a different server, any of which might be temporarily down (not uncommon unfortunately). Caching will make this issue and the other issues less severe, but it won’t solve them.
I don’t disagree with the idea BTW, I just honestly think it’s not practical (at least with ActivityPub).
Why? Take our interaction, for example. the community is on lemmy.world, you are on lemm.ee and I’m on communick.news. My response generates an activity that is sent to LW, and LW then announces that activity to all the servers who have at least one subscriber. If LW went down, you wouldn’t be able to see this message until it came back up and it started processing the federation queue again. Right?
The same thing would happen in a “message-relay” system. My client would send a message to LW, and LW would then send the activity to lemm.ee, which would then “push” it to you. If any of the servers went offline, the whole process would stop at the node that is offline and would then resume when it came back up.
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.