i really disagree with most of your points. a “server” is some machine working for the client. your proposal isn’t getting rid of servers, you’re just making every user responsible to be their own server.
this mostly feels like “im annoyed my instance is filtering content and lacks replies”. have you tried fedilab? it allows fetching directly from source, bypassing your instance and fetching all replies. i think thats kind of anti-privacy but you may like it
if you’re interested here’s a wall of text with more argumentations on my points (sorry wanted to be concise but really failed, i may make this into a reply blog post soon:tm:)
Federation is not the natural unit of social organization
you argue that onboarding is hard, as if picking a server is signing a contract. new users can go to mastosoc and then migrate from there. AP has a great migration system. also federation is somewhat the natural unit: you will never speak to all 8B people, but you will discuss with your local peers and your ideas may get diffused. somewhat fair points, but kind of overblown
Servers are expensive to operate
you really can’t get around this, even if you make every user handle their own stuff, every user will have their database and message queue. every user will receive such post in their message queue, process it and cache in their db. that’s such a wasteful design: you’re replicating once for every member of the network
We should not need to emulate the fragmentation of closed social networks
absolutely true! this should get handled by software implementers, AP already allows intercompatibility, we don’t need a different system, just better fedi software
The server is the wrong place for application logic
this is really wrong imo, and the crux of my critic. most of your complaints boil down to caching: you only see posts cached on a profile and in a conversation. this can’t be different, how could we solve it?
you mention a global search: how do we do that? a central silo which holds all posts ever made, indexed to search? who would run such a monster, and if it existed, why wouldn’t everyone just connect there to have the best experience? that’s centralization
again global search: should all servers ask all other servers? who keeps a list of all servers? again centralized, and also such a waste of resources: every query you’re invoking all fedi servers to answer?
even worse you mention keeping everything on the client, but how do you do that? my fedi instance db is around 30G, and im a single user instance which only sees posts from my follows, definitely not a global db. is every user supposed to store hundreds of GBs to have their “local global db” to search on? why not keep our “local global dbs” shared in one location so that we deduplicate posts and can contribute to archiving? something like a common server for me and my friends?
also if the client is responsible of keeping all its data, how do you sync across devices? in some other reply you mention couchdb and pouchdb, but that sounds silly for fedi: if we are 10 users should we all host our pouchdb on a server, each with the same 10 posts? wouldn’t it be better keeping the posts once and serving them on demand? you save storage on both the server and all clients and get the exact same result
having local dbs for each client also wouldn’t solve broken threads or profiles: each client still needs to see each reply or old post. imagine if every fedi user fetched every old post every time they follow someone, that would be a constant DOS. by having one big server shared across multiple people you’re increasing your chance of finding replies already cached, rather than having to go fetch them
last security: you are assuming a well intentioned fedi but there are bad actors. i don’t want my end device to connect to every instance under the sun. i made a server, which only holds fedi stuff, which at worst will crash or leak private posts. my phone/pc holds my mails and payment methods, am i supposed to just go fetching far and wide from my personal device as soon as someone delivers me an activity? no fucking way! the server is a layer of defense
networks are smarter at the edges
the C2S AP api is really just a way to post, not much different than using madtodon api. as said before content discovery on every client is madness, but timeline/filter managenent is absolutely possible. is it really desirable? megalodon app allows to manage local filters for your timeline, but that’s kind of annoying because you end up with out of sync filters between multiple devices. same for timelines: i like my lists synched honestly, but to each their own, filters/timelines on the client should already be possible.
you mention cheaper servers but only because you’re delegating costs to each client, and the “no storage” idea is in conflict with the couchdb thing you mentioned somewhere else. servers should cache, caching is more efficient on a server than on every client.
a social web browser, built into the browser
im not sure what you’re pitching here. how are AP documents served to other instances from your browser? does your browser need to deliver activities to other instances? is your whole post history just stored in localstorage, deleted if you clear site data? are you supposed to still buy a domain (AP wants domains as identities) and where are you going to point it?
I have not once said that we need to get rid of servers, but I am saying that they could (should?) be used only as an proxy for the outbox/inbox. I’ve said already elsewhere, but it may make it easier to understand: the “ideal” model I have in mind is something like https://movim.eu, but with messages based around the ActivityStream vocabulary.
you really can’t get around this, even if you make every user handle their own stuff, every user will have their database and message queue.
Hard disagree, here. Tell me one system where I can take my domain and just swap the urls of the inbox/outbox. Mastodon lets you migrate your follower list and signals the redirect to your followers about your new actor ID, but you can not bring your data. But most importantly, the identity itself is not portable.
silo which holds all posts ever made, indexed to search? (…) that’s centralization
i don’t want my end device to connect to every instance under the sun.
Not every instance, but you’d be connecting to the outboxes from the people you follow. How is that different from, e.g, subscribing to a RSS feed?
my fedi instance db is around 30G, and im a single user instance which only sees posts from my follows
First: How the hell did you get this much data? :) I have an instance running for 4 years, with a bunch of relays, serving ~10 users and the DB has less than 4GB.
But to answer your question: If you are running a single-user instance, then you are already running a client, the only difference is that you are running on a remote machine which proxies everything for you. And how you deal with data wouldn’t change: just like you can delete old/stale data in Mastodon, you’d be able to delete or offload messages that are older than X days.
i really disagree with most of your points. a “server” is some machine working for the client. your proposal isn’t getting rid of servers, you’re just making every user responsible to be their own server.
this mostly feels like “im annoyed my instance is filtering content and lacks replies”. have you tried fedilab? it allows fetching directly from source, bypassing your instance and fetching all replies. i think thats kind of anti-privacy but you may like it
if you’re interested here’s a wall of text with more argumentations on my points (sorry wanted to be concise but really failed, i may make this into a reply blog post soon:tm:)
you argue that onboarding is hard, as if picking a server is signing a contract. new users can go to mastosoc and then migrate from there. AP has a great migration system. also federation is somewhat the natural unit: you will never speak to all 8B people, but you will discuss with your local peers and your ideas may get diffused. somewhat fair points, but kind of overblown
you really can’t get around this, even if you make every user handle their own stuff, every user will have their database and message queue. every user will receive such post in their message queue, process it and cache in their db. that’s such a wasteful design: you’re replicating once for every member of the network
absolutely true! this should get handled by software implementers, AP already allows intercompatibility, we don’t need a different system, just better fedi software
this is really wrong imo, and the crux of my critic. most of your complaints boil down to caching: you only see posts cached on a profile and in a conversation. this can’t be different, how could we solve it?
also if the client is responsible of keeping all its data, how do you sync across devices? in some other reply you mention couchdb and pouchdb, but that sounds silly for fedi: if we are 10 users should we all host our pouchdb on a server, each with the same 10 posts? wouldn’t it be better keeping the posts once and serving them on demand? you save storage on both the server and all clients and get the exact same result
having local dbs for each client also wouldn’t solve broken threads or profiles: each client still needs to see each reply or old post. imagine if every fedi user fetched every old post every time they follow someone, that would be a constant DOS. by having one big server shared across multiple people you’re increasing your chance of finding replies already cached, rather than having to go fetch them
last security: you are assuming a well intentioned fedi but there are bad actors. i don’t want my end device to connect to every instance under the sun. i made a server, which only holds fedi stuff, which at worst will crash or leak private posts. my phone/pc holds my mails and payment methods, am i supposed to just go fetching far and wide from my personal device as soon as someone delivers me an activity? no fucking way! the server is a layer of defense
the C2S AP api is really just a way to post, not much different than using madtodon api. as said before content discovery on every client is madness, but timeline/filter managenent is absolutely possible. is it really desirable? megalodon app allows to manage local filters for your timeline, but that’s kind of annoying because you end up with out of sync filters between multiple devices. same for timelines: i like my lists synched honestly, but to each their own, filters/timelines on the client should already be possible.
you mention cheaper servers but only because you’re delegating costs to each client, and the “no storage” idea is in conflict with the couchdb thing you mentioned somewhere else. servers should cache, caching is more efficient on a server than on every client.
im not sure what you’re pitching here. how are AP documents served to other instances from your browser? does your browser need to deliver activities to other instances? is your whole post history just stored in localstorage, deleted if you clear site data? are you supposed to still buy a domain (AP wants domains as identities) and where are you going to point it?
I have not once said that we need to get rid of servers, but I am saying that they could (should?) be used only as an proxy for the outbox/inbox. I’ve said already elsewhere, but it may make it easier to understand: the “ideal” model I have in mind is something like https://movim.eu, but with messages based around the ActivityStream vocabulary.
Why is it that a XMPP server can handle millions of concurrent users on a single box with 160GB RAM and 40 cores, yet Mastodon deployments for less than 10k active users have crazy expensive bills?
Hard disagree, here. Tell me one system where I can take my domain and just swap the urls of the inbox/outbox. Mastodon lets you migrate your follower list and signals the redirect to your followers about your new actor ID, but you can not bring your data. But most importantly, the identity itself is not portable.
You can have decentralized search indexes. Each server holds a bit of the index, but everyone gets to see the whole thing.
Not every instance, but you’d be connecting to the outboxes from the people you follow. How is that different from, e.g, subscribing to a RSS feed?
First: How the hell did you get this much data? :) I have an instance running for 4 years, with a bunch of relays, serving ~10 users and the DB has less than 4GB.
But to answer your question: If you are running a single-user instance, then you are already running a client, the only difference is that you are running on a remote machine which proxies everything for you. And how you deal with data wouldn’t change: just like you can delete old/stale data in Mastodon, you’d be able to delete or offload messages that are older than X days.