prom™️
@laurenshof @cwebber @evan what I really like is the openness of it all.
On the signing issue, I'm with Christine. I like Evan's viewpoint for social systems, but not for digital systems with "complex system" mechanics and active intelligent threat actors.
Christine Lemmer-Webber
@promovicz @laurenshof It's "entertaining content" for sure, but what it also gets at is not just the technical side of things, but the social one, and how we are caught between both, and our systems are the output of the conflicts between technical goals and social dynamics.
@evan is my friend, and I'm not super proud of that exchange, because I lost patience publicly, because this is a sore issue for me. But of course, you tear things back, and Evan and I had a nice chat afterwards, and actually have hung out quite a bit before and since, and behind all of that, both of us were going through things in our personal lives.
And yet the decisions we make in these messy social dynamics influence the kinds of technical systems which in turn influence the kinds of social systems we can have!
Christine Lemmer-Webber
@promovicz @laurenshof @evan It does worry me though, and there's a reason it's so personal to me. The lack of signing of messages and content-addressing have lead to serious issues that, while ATproto does worse than us on the aspects of power distribution, it does better in terms of content survivability and portability, and these are things I thought were important *all the way back in ActivityPub standardization*, but we couldn't get to yet.
There is no "technical problems vs social problems" dichotomy. Social situations influence technical design, and technical design informs the kinds of social systems that are possible. Protocol development is all of this, mass multiplied.
Christine Lemmer-Webber
@promovicz @laurenshof @evan And for whatever it's worth, I think there are solutions to these things. EITHER ActivityPub or ATproto could incorporate the good ideas of the other and solve the parts the other lack.
And I can write down to do it. And I have, scattered across bits and pieces.
But it requires getting ecosystems to move, and it's very depressing trying to do that. I don't have the time in my life to sit through meetings trying to convince them that they need to solve the problem right now. So I just focus on building the directions I think matter.
I could write it all down though, and let everyone else do the fighting to make it happen, I suppose.
But I don't have power over the ATproto or ActivityPub worlds, really. The implementers of both do, and both have huge stakes and biases towards their own things, and investments in the directions they already are convinced they should go. I have a say, and an ability to critique, and people listen to me, but only sort of.
Evan Prodromou
@cwebber @promovicz @laurenshof I don't feel like things got that bad at all.
I continue to believe that verifying content when it's first read, rather than when it's first received, is a much more performant strategy. It causes a slight hit for the first reader, but it spreads out the stress on the remote server across time much better.
I also think trust metrics are good for networks.
I did promise you a blog post on the topic, though, @cwebber . I'll try to get that done next week!
Evan Prodromou
@promovicz @cwebber @laurenshof Thanks for bringing the post to my attention! I missed it the first time around.
prom™️
@cwebber @laurenshof @evan You are both working in a challenging space, and I respect that. Discussion is hard to avoid sometimes.
My dichotomy was just for illustration. About the rest, I mostly just agree, and hope that you and the community can figure out a good path forward. My vote tends towards “strong tech makes better social guarantees” or sth like that.
Evan Prodromou
@erincandescent thanks for mentioning blocks! It's one of the reasons that the current best practice is not to include the content of the boosted object at all.
Erin 💽✨
@cwebber @promovicz @laurenshof @evan I think one of the problems we’ve had in general is that signing things is a bit of a nightmare. Not just from a non-repudiation perspective (ActivityPub is pretty crap at this - though workable workarounds sort of exist.. - but I doubt ATProto is much better) but from a revocation and propagation of outdated/deleted information perspective.
Why do we not sign things? Because we don’t have a revocation story and also because indirect relaying gives up all sorts of control. Why is ATProto a bit more flexible here? Because they gave up that control to begin with.
If the signatures had expiries (which as far as I remember, they don’t!) you could imagine a world where when you click the boost button on my post, you ask my server for a copy of the post that’s signed and carries a short lived signature and then you would relay the post alongside that signature; but then it turns out that one of your followers is on a server that I blocked and now my post is there and, as a general rule, the Fediverse has decided that this is unacceptable (despite being unenforcible in general!), mostly as a consequence of the fact that we don’t have any form of 3rd-party-enforcible reply controls (I wish we had that, maybe it’ll come as an evolution of Mastodon’s quote controls…)
(And yes, LD Signatures suck, but all signature formats suck in some way or another and signatures are a primitive that it really sucks to build things around. But that’s a whole separate discussion!)
Evan Prodromou
@lykso Duly noted!
Lykso
@promovicz @laurenshof Really trying hard not to say anything too spicy after reading that exchange. Suffice it to say, I strongly agree with @cwebber
Evan Prodromou
This is a really interesting take!
To me, disinformation becomes dangerous when it is read by a user. Until then, it's just bits on a hard drive.
In your mind, what's the danger of having unverified data in a database that no user has yet read?
Luigi.exe (Dragonheart System)
Nah, I think you had the right to pop off a bit there. I'm no network engineer, but even I thought verifying upon first read was an insane take. In this age with agentic AI writing goddamn hit-pieces on people and how dangerous things are getting, security has to be a priority. Dis/misinformation is spreading at unprecedented rates, and I think a place like the decentralized web needs to do whatever it can to limit that spread if it wants to actually be a viable alternative/replacement.
Evan Prodromou
@noisytoot you seem to be confusing the difference between when you read something with your human eyeballs, and when a software process acting on your behalf reads data from a database.
You're right that there's not an easy way to detect the first, but that's not what we talk about when we're discussing server software.
Noisytoot
Christine Lemmer-Webber
@evan @noisytoot @promovicz @laurenshof If you are talking about "trust THEN verify" as being your *server* sees it but doesn't show the user, I don't think that's the impression I got, and I don't think it's descriptive of the phrase. If your server is not showing to the user yet and that's what's keeping things secure, then it doesn't fully trust it yet, which I agree is safer.
But it does lead to significant delays before content can be shared and viewed, leading to either a sluggish experience of federation, or the thundering herd problem.
Evan Prodromou
@cwebber I take the fault for an imperfect strategy name! Maybe "lazy verification" would be better...?
Evan Prodromou
It's also worth noting that the time frame you're talking about -- spacing out verification requests by tens of seconds or a small number of minutes -- is plenty for reducing the thundering herd problem.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.