Further, I don't like it, but it's definitely _in the...

All posts Hrefna's posts Post Back to profile

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.

Like 14 February at 20:19 | Open on hachyderm.io

12 comments

Hrefna (DHC)

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.

14 February at 20:25 | Open on hachyderm.io

Hrefna (DHC)

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.

14 February at 20:31 | Open on hachyderm.io

Hrefna (DHC)

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.

14 February at 20:36 | Open on hachyderm.io

Hrefna (DHC)

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.

14 February at 20:39 | Open on hachyderm.io

Hrefna (DHC)

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.

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

14 February at 20:42 | Open on hachyderm.io

Timon 🛠

@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.
As of now you can already host your own PDS and use it with bsky.

14 February at 20:56 | Open on mastodon.social

Anoosha

@hrefna thank you for coming up with a critical viewpoint of what was not that visible, at least for me. But if I ask you to summarize what you said briefly, would you do it? I think I didn't get the issue clearly.

14 February at 21:37 | Open on expressional.social

Eric McCorkle

@hrefna

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.

14 February at 21:00 | Open on indieweb.social

L. Rhodes

@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.

14 February at 21:25 | Open on merveilles.town

Hrefna (DHC)

@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.

14 February at 21:38 | Open on hachyderm.io

L. Rhodes

@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.

14 February at 21:47 | Open on merveilles.town

Hrefna (DHC)

@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.

14 February at 22:01 | Open on hachyderm.io

Go Up