6 ms·

To be fair to them, they have done a significant amount of work to design the network to be open to competing servers, and I think it would be quite tricky to u

To be fair to them, they have done a significant amount of work to design the network to be open to competing servers, and I think it would be quite tricky to unpick that. In comparison to successful networks like TikTok, Twitter, Facebook, LinkedIn, ATP gives a far fairer playing field and Bluesky hasn't done anything (aside from taking funding) to suggest they're not going to run with it. You are right that they could change their architecture so that their Relay is more trusted or blocks others in some way, once they capture the market. I am not sure what guarantee they could give with the current ATP arch - perhaps a committee would help, but other social networks have no incentive to support ATP.

shafyy 2y ago
They have done everything to have the appearance of an open protocol and use that as a competitive advantage against incumbents. However, if you look at the reality, it's a very centralized service run by the same company which controls and develops the protocol. If they are serious about this, they should hand over ATProto to an organization like W3C. They said that they don't think ActivityPub is good enough – but why not work with the ActivityPub team to make it better instead of building their proprietary protocol? Why should we trust them?
- pfraze 2y ago
  We looked quite closely at ActivityPub. Here's why we didn't go with it: 1. AP doesn't have the facilities for global aggregation which can power search, discovery, algorithms, and metrics. The user community has been very clear that they do not want it to be introduced. We felt the connectivity of a shared global network was extremely important to the UX, but we felt it would be wrong to fly in the face of the AP world's established norms & wishes. 2. 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. 3. 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. 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. Note, however: Our software is not proprietary. It's open-source. The specs are open. The network firehose is open. We're working on getting every piece of the infrastructure into good governance and straightforward self-hosting. It just takes time.
  - fsflover 2y ago
    > AP doesn't have the facilities for global aggregation which can power search, discovery, algorithms, and metrics. I guess you should also refuse to use the Internet itself, too. > 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 So how do I leave a host and join another, independent one in Bluesky?
    - pfraze 2y ago
      For account hosting: https://atproto.com/guides/self-hosting https://atproto.com/guides/self-hosting For running a relay and appview, the code is dispersed among https://github.com/bluesky-social https://github.com/bluesky-social and we're working on a straight-forward distribution
      - Volundr 2y ago
        Mainly because your here and replying, I looked at self hosting the PDS and bounced off because there wasn't really any documentation on day 2 ops. How do I do backups/disaster recovery? What data is stored here and what happens if it's lost? What kind of traffic should I expect to see? What are the risks around updates? I can probably figure this stuff out by learning the protocol, but I wish the documentation around hosting was deeper than "run this script to install it, run this other one to update"
    - deleted 2y ago
      [deleted]
  - 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.

shafyy 2y ago

They have done everything to have the appearance of an open protocol and use that as a competitive advantage against incumbents. However, if you look at the reality, it's a very centralized service run by the same company which controls and develops the protocol. If they are serious about this, they should hand over ATProto to an organization like W3C. They said that they don't think ActivityPub is good enough – but why not work with the ActivityPub team to make it better instead of building their proprietary protocol? Why should we trust them?

pfraze 2y ago
We looked quite closely at ActivityPub. Here's why we didn't go with it: 1. AP doesn't have the facilities for global aggregation which can power search, discovery, algorithms, and metrics. The user community has been very clear that they do not want it to be introduced. We felt the connectivity of a shared global network was extremely important to the UX, but we felt it would be wrong to fly in the face of the AP world's established norms & wishes. 2. 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. 3. 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. 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. Note, however: Our software is not proprietary. It's open-source. The specs are open. The network firehose is open. We're working on getting every piece of the infrastructure into good governance and straightforward self-hosting. It just takes time.
- fsflover 2y ago
  > AP doesn't have the facilities for global aggregation which can power search, discovery, algorithms, and metrics. I guess you should also refuse to use the Internet itself, too. > 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 So how do I leave a host and join another, independent one in Bluesky?
  - pfraze 2y ago
    For account hosting: https://atproto.com/guides/self-hosting https://atproto.com/guides/self-hosting For running a relay and appview, the code is dispersed among https://github.com/bluesky-social https://github.com/bluesky-social and we're working on a straight-forward distribution
    - Volundr 2y ago
      Mainly because your here and replying, I looked at self hosting the PDS and bounced off because there wasn't really any documentation on day 2 ops. How do I do backups/disaster recovery? What data is stored here and what happens if it's lost? What kind of traffic should I expect to see? What are the risks around updates? I can probably figure this stuff out by learning the protocol, but I wish the documentation around hosting was deeper than "run this script to install it, run this other one to update"
  - deleted 2y ago
    [deleted]
- 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.