6 ms·

>AP doesn't have the facilities for global aggregation which can power search, discovery, algorithms, and metrics. Very nice way to say "AP isn't centralized e

by S0y 2y ago

>AP doesn't have the facilities for global aggregation which can power search, discovery, algorithms, and metrics. Very nice way to say "AP isn't centralized enough". >We felt that strong account portability was an extremely important feature of the system, to ensure that users don't get locked into a specific host. AP's redirection model of account migration concerned us. What's your current timeline to start accepting incoming account migrations back into the bluesky hosted PDS? When will account migrations officially be a recommended operation? Source: https://github.com/bluesky-social/pds/blob/main/ACCOUNT_MIGRATION.md https://github.com/bluesky-social/pds/blob/main/ACCOUNT_MIGR... >We're concerned about the cost structure of AP. We're concerned that self-hosters are going to pay a prohibitively high price for virality. This is why we designed the network to avoid placing heavy load on PDS. First of all, self hosting an ActivityPub service is not prohibitively expensive, heck expensive just isn't even a word a would use at all. On the other hand, what's expensive is the cost of hosting the bluesky relay. What you're essentially doing is just taking on the burden/cost of data processing and hiding it from the end user. The fact that ATProto requires a relay is at complete odds with the premise of decentralization and federation. You're no more decentralized than google search giving you results from different websites. >I know that the AP world is frustrated with the competition between the protocols and suspicious of how we've chosen to do things. It's a shame because I think we're after similar things, and hold similar values. We didn't set out to sabotage the AP world; we just felt like there were important changes that needed to happen for this mission to work. We're frustrated with bluesky describing itself as decentralized and federated when it isn't. Look, I get it, You guys are trying to run a business. You can't control ActivityPub so you made ATProto. It's your thing so you can make what you want with it. You can make it open-source, but at the end of the day, you guys decide. Just be honest about it.

pfraze 2y ago
Believe it or not, it’s possible to have meaningful differences about the way to design a system while maintaining the same motives. It’s clear that you’re happy with the ActivityPub design. I’m not. And your argument right now is akin to saying the Web isn’t decentralized because it uses search engines.
- S0y 2y ago
  If you actually cared about having a meaningful conversation you wouldn't be tip-toeing around my arguments. There's clear dissonance between the words you're speaking and the actual reality of how ATProto/Bsky works. You say you have the same motives yet this is not what the technology shows. >your argument right now is akin to saying the Web isn’t decentralized because it uses search engines. Is that really all I said?
  - pfraze 2y ago
    Very well. > Very nice way to say "AP isn't centralized enough". You seem to be operating under the misconception that having large secondary indexing services in the system is the same thing as binding the system to single organizations. Anybody can run a relay or appview, same as anybody can run a PDS. > What's your current timeline to start accepting incoming account migrations back into the bluesky hosted PDS? When will account migrations officially be a recommended operation? Source: https://github.com/bluesky-social/pds/blob/main/ACCOUNT_MIGR https://github.com/bluesky-social/pds/blob/main/ACCOUNT_MIGR... When the software is sufficiently tested and implemented. > First of all, self hosting an ActivityPub service is not prohibitively expensive, heck expensive just isn't even a word a would use at all. This remains true only so long as the network remains under a certain size, and your posts never go viral. > On the other hand, what's expensive is the cost of hosting the bluesky relay. What you're essentially doing is just taking on the burden/cost of data processing and hiding it from the end user. We're keeping the most valuable part of the system -- account ownership -- from having its costs bundled with application ops. It's important that there are hundreds of thousands of account hosts. It's only important that there are 5 to 10 microblogging applications, and that users can switch between them as they come and go. In fact, I would argue that binding user accounts to individual application instances & their governance like AP does is a massive mistake. It's much more important that you guarantee users' continuity of identity as apps come and go.
    - S0y 2y ago
      I Appreciate you taking the time to properly respond. >large secondary indexing services We've talked about this before. The relay isn't secondary. proof of the matter is, bluesky last week went down because it was down. >Anybody can run a relay or appview, same as anybody can run a PDS. That's just saying anybody can fork the network if they're not happy. that's not very collaborative and social. >When the software is sufficiently tested and implemented. I would think this was a more pressing matter seeing your previous response. >This remains true only so long as the network remains under a certain size, and your posts never go viral. I think you're overestimating how taxing going "viral" is on an ActivityPub server. if one of your posts goes viral, it doesn't get hit for every follower you have. It'll only be a request per instance. Plus, task queues exist. Yes going viral is taxing on a server. it doesn't mean the solution is just to offload that burden to some centralized server. >We're keeping the most valuable part of the system -- account ownership -- from having its costs bundled with application ops. Except the tradeoff is relying on a handful of large organization that have the resources to burden the cost of running a network. Those networks then decide who gets to post or not. account ownership isn't worth much if you can't speak anywhere. If I were to get banned from the bsky relay, I'd be essentially barred from interacting with anyone on the ATmosphere until someone else came along and created a new relay or appview. On activitypub, maybe mastodon.social doesn't like what I say so they ban my instance. But at least I can still interact with the thousand of other instances that exist. Now you can say, don't be an ass and you won't get banned, and I agree. But when you've created a system where only large organizations have the capacity to run a network, Maybe now I get banned because Coca-Cola decided they didn't want anyone saying Pepsi tasted better on their network. >In fact, I would argue that binding user accounts to individual application instances & their governance like AP does is a massive mistake. I think we'll agree to disagree on this one. As always Appreciate the debates pfraze, hopefully these conversation help users decide which platform they like the best.

by S0y 2y ago

pfraze 2y ago

Believe it or not, it’s possible to have meaningful differences about the way to design a system while maintaining the same motives. It’s clear that you’re happy with the ActivityPub design. I’m not. And your argument right now is akin to saying the Web isn’t decentralized because it uses search engines.

S0y 2y ago
If you actually cared about having a meaningful conversation you wouldn't be tip-toeing around my arguments. There's clear dissonance between the words you're speaking and the actual reality of how ATProto/Bsky works. You say you have the same motives yet this is not what the technology shows. >your argument right now is akin to saying the Web isn’t decentralized because it uses search engines. Is that really all I said?
- pfraze 2y ago
  Very well. > Very nice way to say "AP isn't centralized enough". You seem to be operating under the misconception that having large secondary indexing services in the system is the same thing as binding the system to single organizations. Anybody can run a relay or appview, same as anybody can run a PDS. > What's your current timeline to start accepting incoming account migrations back into the bluesky hosted PDS? When will account migrations officially be a recommended operation? Source: https://github.com/bluesky-social/pds/blob/main/ACCOUNT_MIGR https://github.com/bluesky-social/pds/blob/main/ACCOUNT_MIGR... When the software is sufficiently tested and implemented. > First of all, self hosting an ActivityPub service is not prohibitively expensive, heck expensive just isn't even a word a would use at all. This remains true only so long as the network remains under a certain size, and your posts never go viral. > On the other hand, what's expensive is the cost of hosting the bluesky relay. What you're essentially doing is just taking on the burden/cost of data processing and hiding it from the end user. We're keeping the most valuable part of the system -- account ownership -- from having its costs bundled with application ops. It's important that there are hundreds of thousands of account hosts. It's only important that there are 5 to 10 microblogging applications, and that users can switch between them as they come and go. In fact, I would argue that binding user accounts to individual application instances & their governance like AP does is a massive mistake. It's much more important that you guarantee users' continuity of identity as apps come and go.
  - S0y 2y ago
    I Appreciate you taking the time to properly respond. >large secondary indexing services We've talked about this before. The relay isn't secondary. proof of the matter is, bluesky last week went down because it was down. >Anybody can run a relay or appview, same as anybody can run a PDS. That's just saying anybody can fork the network if they're not happy. that's not very collaborative and social. >When the software is sufficiently tested and implemented. I would think this was a more pressing matter seeing your previous response. >This remains true only so long as the network remains under a certain size, and your posts never go viral. I think you're overestimating how taxing going "viral" is on an ActivityPub server. if one of your posts goes viral, it doesn't get hit for every follower you have. It'll only be a request per instance. Plus, task queues exist. Yes going viral is taxing on a server. it doesn't mean the solution is just to offload that burden to some centralized server. >We're keeping the most valuable part of the system -- account ownership -- from having its costs bundled with application ops. Except the tradeoff is relying on a handful of large organization that have the resources to burden the cost of running a network. Those networks then decide who gets to post or not. account ownership isn't worth much if you can't speak anywhere. If I were to get banned from the bsky relay, I'd be essentially barred from interacting with anyone on the ATmosphere until someone else came along and created a new relay or appview. On activitypub, maybe mastodon.social doesn't like what I say so they ban my instance. But at least I can still interact with the thousand of other instances that exist. Now you can say, don't be an ass and you won't get banned, and I agree. But when you've created a system where only large organizations have the capacity to run a network, Maybe now I get banned because Coca-Cola decided they didn't want anyone saying Pepsi tasted better on their network. >In fact, I would argue that binding user accounts to individual application instances & their governance like AP does is a massive mistake. I think we'll agree to disagree on this one. As always Appreciate the debates pfraze, hopefully these conversation help users decide which platform they like the best.