|
Top-level
 @hrefna This all sounds generally reasonable. The trouble I have with bridging to other protocols is that: 1. They sometimes have different assumptions around consent—like Bluesky's assumptions around personal data processing; and 2. It's not always clear how our consent revocation tools (e.g. domain blocks) will interoperate with their system (e.g. decoupling account identity from host domain). If nothing else, the uncertainty around those things seems to call for a consent-based approach. 3 comments
@hrefna I don't want to belabor the point, because it sounds like we just kinda disagree on this, but part of what I'm saying is that Big Data-type processing is not assumed by the protocol. A service might integrate it, but it would be presumptuous of them to assume specific consent for that use. It is, however, assumed on ATproto—the network doesn't really work without it—which is why bridging those creates an *unavoidable* clash around assumptions about consent for that sort of data handling.  @lrhodes why do you think it is "presumptuous" to assume that? There's nothing in the protocol that I can see that weighs in favor of that interpretation. It's a mastodon-ism, perhaps, but that's not the same thing as "presumptuous" to infer from the protocol, which places no restrictions on this one way or another What's more, what specific clause are you objecting to that you think of as "big data"? Because that term has a very specific meaning to me and I don't see it in the ATProto docs. |
Gregory's Server
@lrhodes That is also true for other ActivityPub services. In fact it is completely analogous: there are very limited requirements for what other servers do here.