4 ms·

>Old social media never gave full access to the firehose so there’s a pretty big difference. That is good, but it's still a centralized source of truth. >If y

by S0y 2y ago

>Old social media never gave full access to the firehose so there’s a pretty big difference. That is good, but it's still a centralized source of truth. >If you want large scale social networks, you need to work with a large scale of data. Since federated open queries aren’t feasible, you need big machines. Thats just simply not true. ActivityPub does perfectly without the need of any bulky machine or node acting as a relay for the rest of the network. Every single ActivityPub service only ever interacts with other discovered services. Messages aren't broadcast through a central firehose, they're sent directly to who needs to receive them. This is a fundamental difference with how both protocols work. With ATProto you NEED to connect to some centralized relay that will broker your messages for you. With ActivityPub, there is no middle man, Instances just talk directly to each other. This is why ActivityPub has a discovery problem by the way, but it's just a symptom of real federation. >and is how ActivityPub works by nature. It's not. See Above.

str4d 2y ago
> > If you want large scale social networks, you need to work with a large scale of data. Since federated open queries aren’t feasible, you need big machines. > Thats just simply not true. > [snip] > This is why ActivityPub has a discovery problem by the way, but it's just a symptom of real federation. You're actually agreeing with them! The "discovery problem" is because "federated open queries aren't feasible". > With ATProto you NEED to connect to some centralized relay that will broker your messages for you. You can connect to PDSs directly to fetch data if you want; this is exactly what the relays do! If you want to build a client that behaves more like ActivityPub instances, and does not depend on a relay, you could do so: - Run your own PDS locally, hosting your repo. - Your client reads your repo via your PDS to see the accounts you follow. - Your client looks up the PDSs of those accounts (which are listed in their DID documents). - Your client connects to those PDSs, fetches data from them, builds a feed locally, and displays it to you. This is approximately a pull-based version of ActivityPub. It would have the same scaling properties as ActivityPub (in fact better, as you only fetch what you need, rather than being pushed whatever the origins think you need). It would also suffer from the same discovery problem as ActivityPub (you only see what the accounts you follow post). At that point, you would not be consuming any of the _output_ of a relay. You would still want relays to connect to your PDS to pull data into their _input_ in order for other users to see your posts, but that's because those users have chosen to get their data via a relay (to get around the discovery problem). Other users could instead use the same code you're using, and themselves fetch data directly from your PDS without a relay, if they wanted to suffer from the discovery problem in exchange for not depending on a relay.
- S0y 2y ago
  It doesn't change the fact that if someone were to do that, it wouldn't be supported by anyone let alone the main bluesky firehose. I think it's pretty disingenuous to just say "You can do it" when what your suggesting is so far off the intended usage of the Protocol that it might as well be a brand new implementation. As a matter of fact, people DO already do this. they use ActivityPub and talk to bluesky using a bridge. The core of the issue is, Bluesky's current model is unsustainable. The cost of running the main relay is going to keep rising. The barrier to discovery keeps getting higher and higher. It might cost 150$/month now to mirror the relay, but what's going to happen when it's 1000$?
  - CyberDildonics 2y ago
    Blue Sky supposedly has 5.5 million active users. https://en.wikipedia.org/wiki/Bluesky https://en.wikipedia.org/wiki/Bluesky By your own numbers it averages 2.7 MB/s. This is manageable with a good cable internet connection or a small vps. This is a small number for 5.5 million active users. What happens if it expands to 10 times its current active users? Who knows, maybe only the 354 million people around the world with access to gigabit broadband can run a full server at home and the rest of the people and companies that want to run full servers will have to rent a vps. https://www.telecompetitor.com/gigabit-availability-report-1-in-5-people-worldwide-can-get-1-gbps-broadband/ https://www.telecompetitor.com/gigabit-availability-report-1... The point here is that this is not a practical problem. How many of these servers do you really need?
rudyfraser 2y ago
AP also has relays as a part of the architecture, just less well documented https://joinfediverse.wiki/index.php?mobileaction=toggle_view_desktop&title=Fediverse_relays https://joinfediverse.wiki/index.php?mobileaction=toggle_vie...
- S0y 2y ago
  They may share a name, but they both work in very different ways.
pfraze 2y ago
> That is good, but it's still a centralized source of truth. It's not. It's a trustless aggregator. The PDSes are the sources of truth, and you can crawl them directly. The relay is just an optimization. > Messages aren't broadcast through a central firehose ATProto works like the web does. People publish information on their servers, and then relays crawl them and emit their crawl through a firehose. > ActivityPub does perfectly without the need of any bulky machine or node acting as a relay for the rest of the network ActivityPub doesn't do large scale aggregated views of the activity. The peer-wise exchanges means that views get localized; this is why there's not network-wide search, metrics, or algorithms. > This is why ActivityPub has a discovery problem by the way, right > but it's just a symptom of real federation. "real" ?
- S0y 2y ago
  >The PDSes are the sources of truth, and you can crawl them directly. The relay is just an optimization. This is such a massive understatement. the relay is the single most important piece in the entire Bluesky stack. Let me ask you this, is it possible for me to connect to a PDS directly, right now, via the bluesky app? or is this something that will be possible in the future? >ATProto works like the web does. People publish information on their servers, and then relays crawl them and emit their crawl through a firehose. >ActivityPub doesn't do large scale aggregated views of the activity. So are relays really just an optimization or an integral part of how ATProtocol is supposed to work? ActivityPub doesn't require relays to function properly. This is why I say it's real federation. You can't truly be federated if you require centralization.
  - orf 2y ago
    > You can't truly be federated if you require centralization. I’m not so sure: isn’t the certificate transparency log a pretty good example of a federated group of disparate members successfully sharing a view of the world? That requires some form of centralization to be useful (else it’s not really a log, more of a series of disconnected scribbles), and it’s definitely a true federated network.
  - pfraze 2y ago

by S0y 2y ago

str4d 2y ago

> > If you want large scale social networks, you need to work with a large scale of data. Since federated open queries aren’t feasible, you need big machines. > Thats just simply not true. > [snip] > This is why ActivityPub has a discovery problem by the way, but it's just a symptom of real federation. You're actually agreeing with them! The "discovery problem" is because "federated open queries aren't feasible". > With ATProto you NEED to connect to some centralized relay that will broker your messages for you. You can connect to PDSs directly to fetch data if you want; this is exactly what the relays do! If you want to build a client that behaves more like ActivityPub instances, and does not depend on a relay, you could do so: - Run your own PDS locally, hosting your repo. - Your client reads your repo via your PDS to see the accounts you follow. - Your client looks up the PDSs of those accounts (which are listed in their DID documents). - Your client connects to those PDSs, fetches data from them, builds a feed locally, and displays it to you. This is approximately a pull-based version of ActivityPub. It would have the same scaling properties as ActivityPub (in fact better, as you only fetch what you need, rather than being pushed whatever the origins think you need). It would also suffer from the same discovery problem as ActivityPub (you only see what the accounts you follow post). At that point, you would not be consuming any of the _output_ of a relay. You would still want relays to connect to your PDS to pull data into their _input_ in order for other users to see your posts, but that's because those users have chosen to get their data via a relay (to get around the discovery problem). Other users could instead use the same code you're using, and themselves fetch data directly from your PDS without a relay, if they wanted to suffer from the discovery problem in exchange for not depending on a relay.

S0y 2y ago
It doesn't change the fact that if someone were to do that, it wouldn't be supported by anyone let alone the main bluesky firehose. I think it's pretty disingenuous to just say "You can do it" when what your suggesting is so far off the intended usage of the Protocol that it might as well be a brand new implementation. As a matter of fact, people DO already do this. they use ActivityPub and talk to bluesky using a bridge. The core of the issue is, Bluesky's current model is unsustainable. The cost of running the main relay is going to keep rising. The barrier to discovery keeps getting higher and higher. It might cost 150$/month now to mirror the relay, but what's going to happen when it's 1000$?
- CyberDildonics 2y ago
  Blue Sky supposedly has 5.5 million active users. https://en.wikipedia.org/wiki/Bluesky https://en.wikipedia.org/wiki/Bluesky By your own numbers it averages 2.7 MB/s. This is manageable with a good cable internet connection or a small vps. This is a small number for 5.5 million active users. What happens if it expands to 10 times its current active users? Who knows, maybe only the 354 million people around the world with access to gigabit broadband can run a full server at home and the rest of the people and companies that want to run full servers will have to rent a vps. https://www.telecompetitor.com/gigabit-availability-report-1-in-5-people-worldwide-can-get-1-gbps-broadband/ https://www.telecompetitor.com/gigabit-availability-report-1... The point here is that this is not a practical problem. How many of these servers do you really need?

rudyfraser 2y ago

AP also has relays as a part of the architecture, just less well documented https://joinfediverse.wiki/index.php?mobileaction=toggle_view_desktop&title=Fediverse_relays https://joinfediverse.wiki/index.php?mobileaction=toggle_vie...

S0y 2y ago
They may share a name, but they both work in very different ways.

pfraze 2y ago

> That is good, but it's still a centralized source of truth. It's not. It's a trustless aggregator. The PDSes are the sources of truth, and you can crawl them directly. The relay is just an optimization. > Messages aren't broadcast through a central firehose ATProto works like the web does. People publish information on their servers, and then relays crawl them and emit their crawl through a firehose. > ActivityPub does perfectly without the need of any bulky machine or node acting as a relay for the rest of the network ActivityPub doesn't do large scale aggregated views of the activity. The peer-wise exchanges means that views get localized; this is why there's not network-wide search, metrics, or algorithms. > This is why ActivityPub has a discovery problem by the way, right > but it's just a symptom of real federation. "real" ?

S0y 2y ago
>The PDSes are the sources of truth, and you can crawl them directly. The relay is just an optimization. This is such a massive understatement. the relay is the single most important piece in the entire Bluesky stack. Let me ask you this, is it possible for me to connect to a PDS directly, right now, via the bluesky app? or is this something that will be possible in the future? >ATProto works like the web does. People publish information on their servers, and then relays crawl them and emit their crawl through a firehose. >ActivityPub doesn't do large scale aggregated views of the activity. So are relays really just an optimization or an integral part of how ATProtocol is supposed to work? ActivityPub doesn't require relays to function properly. This is why I say it's real federation. You can't truly be federated if you require centralization.
- orf 2y ago
  > You can't truly be federated if you require centralization. I’m not so sure: isn’t the certificate transparency log a pretty good example of a federated group of disparate members successfully sharing a view of the world? That requires some form of centralization to be useful (else it’s not really a log, more of a series of disconnected scribbles), and it’s definitely a true federated network.
- pfraze 2y ago