|
Top-level
 But what is unlikely to happen is that they are unlikely to go out to every person on the fediverse and send them an informed consent letter that says "do you consent to us processing dislikes for your posts on our services?" Why? Because it is part of the ecosystem here, even if it is not a widely used part, and they are behaving basically like a typical server in this regard! This is where you have an implied or assumed consent and _no one thinks this is weird_. It's an opt-out system 4/ 13 comments
So if I build an AP server that connects to another open source protocol—say XMPP—so that users can interact across my bridge with their chat clients, is that something I should seek affirmative informed prior consent for? Maybe! But I'd argue that either decision could be considered and it isn't a sign that the person has a "r*ist mindset" or "does not care about consent." It's a sign that we need to have a deeper conversation _about_ consent and what it means. 6/ Men show up in my mentions all of the time to explain things to me. I revoke consent for them to talk to me. I'm opting out. I never opted "in" to speaking to them specifically, but I did opt in to interactions in this environment, with knowledge that I can revoke that consent. What are the limits of what we can enforce and how does that inform consent? What tools do we have to inform and enforce those consent boundaries? These are important questions and the answers aren't satisfying. 7/ I don't know whether a bridge to bluesky should be opt-in or opt-out, and there are a lot of nuances there depending on specifics of the implementation. I can make an argument either way I'd have probably said to expect a blowback, but as a _consent_ question I'm generally of the view that both have merit. I can see a thousand reasons one might defederate from it or revoke, but then there are a thousand reasons one might defederate from gab, hachyderm, or mastodon.art. Different question. 8/ But what I can say with certainty is that _irrespective of what happens there_ this question is not going away, and "yelling at, harassing, and brigading individual developers" is not a good way to go about solving these problems. It does not scale, it does not extend to the next instance, and it does not even allow for a discussion of a solution for _this_ instance. What you _will_ do is drive away the people who you would _want_ working on this problem. Consistently and reliably. 9/ Especially when there are far deeper problems rooted in the protocol and the architecture of major fediverse apps that, so far, people have refused to correct. So long as those are unfixed and so long as expectations here are not better managed we're going to have this problem again. and again. and again. So if we don't want to keep having this same conversation we have real work to do, and this behavior like what we saw yesterday will—at absolute best—only get in the way. 10/10  @hrefna The ironic part is that ATP actually solved a lot of those shortcomings of AP. It gives you (in theoery, federation has yet to start) as a user much more control over who gets to access your data and allows you to take your data wherever you see fit, which is still not and probably will not be possible on AP.  The trend I've seen here of treating individual developers (which, in an OSS context are volunteers freely offering their labor- I mention this only because it's very relevant) like customer service staff at one's mercy at best, and hate-mob targets at worst is galling. It also says an awful lot about the sincerity of people who do this, while cloaking themselves in the appearance and language of leftism.  @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. @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. @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
Further, I don't like it, but it's definitely _in the ActivityPub spec_ that things sent to servers may end up being sent to _every shared inbox that the server knows about_ ( https://www.w3.org/TR/activitypub/#shared-inbox-delivery ).
Do servers need to seek your individualized consent for each server that they forward it to? Or can they assume consent because you are using a mastodon service, have marked your message as #'Public, and because the spec says that they can?
There's no one right answer here.
5/
Further, I don't like it, but it's definitely _in the ActivityPub spec_ that things sent to servers may end up being sent to _every shared inbox that the server knows about_ ( https://www.w3.org/TR/activitypub/#shared-inbox-delivery ).
Do servers need to seek your individualized consent for each server that they forward it to? Or can they assume consent because you are using a mastodon service, have marked your message as #'Public, and because the spec says that they can?