sure this is all very bad for activitypub but this is truly amazing content

@laurenshof Love to see people discussing how to solve problems with decentralisation that are caused solely by decentralisation

@laurenshof “it’s ok if you don’t get it”

@seachanger saying that to CHRISTINE!?!

@laurenshof @seachanger It's like the purest, most expertly freebased example of mansplaining that's ever existed

@laurenshof

It's not amazing but absolutely frightening when a key figure involved in the evolution of #ActivityPub demonstrates such a level of incompetence.

@laurenshof @seachanger
That he's the person in all of this that got the deal to write the book on ap is just so emblematic of the world we live in

@jenniferplusplus @laurenshof

@seachanger @jenniferplusplus everything is gender, protocol edition

@laurenshof @seachanger
Yes, that. But also, he created a problem that is hard for computers and harmful for humans. And his proposed solution is to make it more harmful to humans in order to make it easier for the computers.

@jenniferplusplus @laurenshof @seachanger OK I feel like I am missing out on hilarious lore here. Who is this guy (aside from someone who felt the need to lecture Christine Lemmer-Webber about ActivityPub, which, well, lmao)

@jenniferplusplus @laurenshof hard to find a single person more embarrassingly to blame for the failures of mastodon to meet the moment

Specifically for Mastodon's failures ... I can think of another candidate (everything is gender, implementation edition). But for AP and "the Fediverse" as a whole, I completely agree. And yet for some inexplicable reason people still listen to him!

@seachanger @jenniferplusplus @laurenshof

@jdp23 @seachanger @laurenshof I assume you mean Eugen, and I want to give him all due credit for trying to do better. I wish he'd started earlier, and I wish it was going faster, but he's been doing the right kinds of things for some time

My main point is that Eugen's had light-years more impact on Mastodon than Evan. Even with respect to AP's less-than-completely-positive (cough) impact on Mastodon, Eugen could have supported LitePub et al back in 2019ish -- or some other protocol change. And Eugen could have prioritized support for AP C2S. AP was in fact an improvement on OStatus when Mastodon adopted it in 2017, but it was Eugen's choice to do an EEE strategy and let it turn into a millstone.

I agree that Eugen 2026 has grown a lot in some ways from Eugen 2017 and even Eugen 2022 ... it's really hard for a founder to step away and pass the torch and he deserves a huge amount of credit for that. On the other hand local-only posts still aren't in Mastodon, admins still can't easily change the maximum post length, the documentation still talks about how allow-list federation is contrary to Mastodon's mission, I don't think he's ever changed his position on Meta's adoption of AP being "a huge victory for our cause" ... so I disagree on "he's been doing the right kinds of things".

@jenniferplusplus @seachanger @laurenshof

@jdp23 @seachanger @laurenshof
Ok, well, I'd rather reinforce good behavior

@jenniferplusplus @jdp23 @laurenshof no doubt eugen has has an enormous practical impact on mastodon but Evan is just such a sparkling poster boy for the absolutely shittiest and most offputting part of this whole world

@seachanger @jdp23 @laurenshof
If I was forced to choose between all Evans or all Eugens, I'd choose Eugen in a heartbeat

Fair! @jenniferplusplus @seachanger @laurenshof

@laurenshof amazing

@j0ebaldw1n Evan is one of the 5 coauthors of ActivityPub, together with Christine. He's also part of the Social Web Foundation, and is an active contributor to the current maintenance of AP at the w3c. the other 4 have largely left the work on AP (2 of them work on another protocol now), and Evan does most of the current work on AP

@laurenshof
I have zero context for anything else but the saying's "Trust *but* verify"

@laurenshof @seachanger I genuinely don’t know either of the people (or that third person, either) in that conversation, even by name. And yet I came away with a very clear sense of who to trust on technical issues.

And it was not “I talk about this in my book” guy.

Yeah so true. Hmm weren't there five co-authors of the AP spec?

@jenniferplusplus @laurenshof @seachanger

@seachanger @laurenshof ick!

@seachanger @laurenshof good (?) to see that he's being an asshole the same way to AP people and not only AT people…

@laurenshof people inquiring about privacy/security considerations seems like a real trigger point.

@laurenshof Lolololol :D 🍿🍿🍿 Evan gonna Evan

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

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

@laurenshof @j0ebaldw1n and if you remember Identi.ca, the open source Twitter clone from like 2008, where the retweet button was invented, that was Evan too. He’s been doing the open source social media thing for a long time.

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

@laurenshof I didn't think it was that bad at all.

@laurenshof I think ActivityPub is inherently and irrevocably flawed due to a naive implementation and needs to be replaced with something that has performance and efficiency in mind (as a counterexample that handles performance at scale better, AT proto comes to mind; that one has its own issues but it does overall work a lot better)

@thomasfuchs @laurenshof So, naive implementations mean that the protocol is irrevocably flawed?

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

@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 @laurenshof It’s probably quicker and less work to make a new protocol based on lessons learned than try to fix it.

You’ll have to adopt clients anyway to upgrades to the protocol. ¯\_(ツ)_/¯

@thomasfuchs @laurenshof You should do that!

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

@cwebber @promovicz @laurenshof @evan it would be great to see a new protocol incorporating lessons learned from both, that concentrates on performance for users and keeps power and bandwidth use as low as possible

@promovicz @cwebber @laurenshof Thanks for bringing the post to my attention! I missed it the first time around.

@thomasfuchs @laurenshof ATProto is the result of corporate minded techbros, to produce yet another #DTBO #SocialMedia aiming at making people a product.

Thinking ATProto is anything else is deeply naive.

I'll yake ActivityPub with its *features* of no algorithm tracking me. Every tracker is a bad idea, every collection should be made a liability, so they stop seeing us as meta data cows.

Long live the #fediverse, free of #bluesky and ALL corporate walled gardens

@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!)

@laurenshof Gorbachev used to get really annoyed at Ronald Reagan for overusing the phrase "Trust, but verify".

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

@promovicz @laurenshof @cwebber

@promovicz @laurenshof Really trying hard not to say anything too spicy after reading that exchange. Suffice it to say, I strongly agree with @cwebber

@cwebber @promovicz @laurenshof @evan I think this whole exchange is a good look, honestly!

You appear frustrated, about a technical problem that is important to you (one that resonates with me!), you don’t fall back on any weird personal attacks, just get loud.

Evan takes it in step and responds nicely.

I could have gasped when i read Evan’s reply and it’s so nice. That’s not how internet exchanges work!

Anyway, this thread reads like real people having a heated and respectful discussion about stuff they feel strongly about. Well done.

@funbreaker @laurenshof "Trust, then verify" is a direct reference to that saying.

@lykso Duly noted!

@promovicz @laurenshof @cwebber

@anders Thanks, those are nice comments.

I should also note that I'm not averse to Christine's ideas around using digital signatures for verifying content. They can improve performance by short-circuiting some verification that would require fetching the content over HTTP.

I do disagree that they are the *only* way to improve that performance, and that it's worth breaking backwards compatibility of the network in order to enable digital signatures.

@cwebber @promovicz @laurenshof

@erincandescent

Can you explain what you mean by expiring signature? Obviously the math doesn’t expire so I assume the idea is signing with some sort of ephemeral key that is not mathematically linked to your identity?

@cwebber

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.

@promovicz @laurenshof @evan

@faraiwe @thomasfuchs @laurenshof i hope you're aware that activitypub is just as public as atproto and that there is nothing stopping someone from creating/running the "tracking algorithms" you claim atproto does by default on this network

@esm I hope you are aware that anything shoved down our throats by techbros is to be seen as toxic and harmful, to their exclusive gain, and aligning yourself with their interests is stupid to the point of suicidal.

Don't let me know.

@evan @anders @promovicz @laurenshof It doesn't need to break backwards compatibility tho

But anyway

Long conversation potentially

@evan As a newbie to the tech end of decentralized spaces, I’m curious as to why you don’t think it should be “verify, then trust” or other alternatives that don’t allow bad actors to get at people who are not tech-savvy.

@ridley minimally I mean a signature with a "don't trust after X" timestamp

apparently i was blocked for saying this, reminder that pointing out that a bad thing that's possible on the "bad" network is also possible on the "good" network is not an endorsement of said bad thing in any way

cognitive dissonance and putting your head in the sand are not good strategies to handle potential threats

@trishalynn Sure! So, there are two main events that happen here:

- The server receives the third-party data
- One of the server's users reads the third-party data

There are usually at least a few minutes, and sometimes a few hours or even days between these two events.

@trishalynn The question is, when should the server *verify* the third-party data?

To be conservative, at the very least, the third party data should be verified before one of the server's users reads it.

@trishalynn If the user is online when the data is received, there may be no time between the time the data is received and when the user reads it.

However, most users aren't online most of the time. There's a strong chance that there are minutes, hours, or days between when the data is received and when it is read.

@evan I should think that the server should verify first even if the user is not active online.

@trishalynn Most ActivityPub implementations today lean waaaaaay into the early part of this gap -- verifying the data as soon as it is received.

The problem with this is that sometimes hundreds or even thousands of servers receive the data within a few seconds -- and if they all verify the data with the third-party server immediately, it can swamp that server with requests.

@trishalynn Before it's read by a user, yes.

@trishalynn One way to relieve this pressure on the third party server is to space out all these requests by seconds or even minutes. There are a couple of ways to do this.

@trishalynn One is to wait until the first reader reads the data. That event is going to vary wildly across servers, so it will spread out the requests and lower the load on the third-party server. The downside of this technique is that it introduces some extra time for that first read. Usually not a lot, but some.

@trishalynn Another is for the receiving server to wait a random number of seconds or minutes before doing the verification request. This spaces out the requests, and hopefully avoids the little delay for the user on first read. At worst, if a user tries to read the data before the verification timeout, you can do the verification then -- it's no worse than the previous method, and will usually be better.

@evan (Could you please let me know when you’re done explaining? I don’t want to jump in with clarifying Qs till you’re done.)

@trishalynn So, the last part, which I think is most controversial, is showing the unverified data to the user -- doing the verification *after* the first read.

This requires a lot of trust between the actors. But if a sending actor has sent 10 or 1000 or 10,000 shares, all of which have previously verified correctly, there's a very good chance that share number 10001 is also going to verify correctly.

@trishalynn This requires a lot more tracking on the receiving server's part. I'm not even sure the performance benefits are that great, compared to waiting for first-read instead of verifying on receipt. But for high-volume servers, it might be a valuable strategy in the future.

@trishalynn I think I'm done!

@evan What's the effect on a high-volume server versus a lower-volume server when the ethos of "trust, then verify" is used to implement a solution?

@cwebber The original conversation was about removing JSON-LD and potentially using another schema language or making one up, or throwing away extensibility altogether. That would break backwards compatibility.

I agree, we might be able to add digital signatures without removing JSON-LD.

@trishalynn OK, so, you're good with the idea that the data doesn't have to be verified until the first user reads it, correct? We're good up until there?

@trishalynn Most of the benefits happen there. It would be great to see more ActivityPub implementations take that approach, because it would ease up on smaller servers. (Christine gave the example of when she shares posts by her friend Viv, which kills Viv's server.)

@trishalynn I think that maintaining trust metrics has some resource requirements -- you have to track by server and maybe by actor how many times you've received third-party data from them, and how many times it has verified correctly.

@trishalynn I think there are limited benefits to using these trust metrics to verify even *after* the first read. So, it would only be on a server with a lot of scale, where those benefits multiply out over thousands or millions of interactions, where that technique might pay off.

@trishalynn I hope that answers your question.

@trishalynn Oh, I should probably say: trust is what we do when we are not certain. If I receive my 10 millionth share from mastodon.social, and I decide to delay verifying it, there's a non-zero chance that this is the time that mastodon.social takes its heel turn and sends me fake data. Trust is accepting that non-zero chance. For users or developers that can't accept that chance, waiting to verify when the first user reads the data is still a great benefit, and also a lot easier to code for.

@Eeveecraft

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?

@cwebber @promovicz @laurenshof

@evan @cwebber @promovicz @laurenshof How do you handle notifications for the purpose of determining when the content is first read? I receive notifications for my mentions, which include the contents of the message. There's no way for the server to know when I actually read the message in the notification, only when the notification is received by my client (which will likely be within seconds to minutes of it being received by my server).

The options are either to include unverified content in the notification (which I don't consider to be acceptable), or verify it first, at which point it's almost the same as verifying it as soon as it's received by my server.

@evan I am not suggesting removing json-ld, I am suggesting accepting the current state of affairs as "it's json-ld except not really because almost nobody is using the official algorithms" and then saying "okay, well how can we make this json-ld compatible but actually add a canonicalization and signature system that doesn't use those algorithms, even though the few people who want to bridge with the RDF world still could"

Which, maybe I didn't explain sufficiently

@evan I am not suggesting we would do *anything* spec-incompatible either. None of the proposals I have made for ActivityPub have suggested doing so. They would require a window where some new servers were doing things that other servers would have to catch up on to make use of those features, but that's forward compatibility, not backwards.

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

@promovicz @laurenshof @cwebber

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

@cwebber I take the fault for an imperfect strategy name! Maybe "lazy verification" would be better...?

@noisytoot @promovicz @laurenshof

@cwebber I reread this post and it's true, you talk about finding solutions, not about removing JSON-LD.

https://social.coop/@cwebber/116098814196020228

@evan @Eeveecraft @cwebber @promovicz @laurenshof

As someone coming from the matrix side, storing unverified events is a significant problem even when there are no human eyeballs to see them, because they are both a resource exhaustion vector and a legal risk. Unfortunately it's necessary in some cases but they should be avoided as much as possible :/

@evan All of that was helpful in understanding your line of thinking, thank you.

@evan @Eeveecraft @cwebber @promovicz @laurenshof in this case the risk can probably buy mitigated by verifying or discarding on a random timer as well as on view, so there's no build up of unverified content.

@JadedBlueEyes in our case, it's an URL.

@Eeveecraft @cwebber @promovicz @laurenshof

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.

@noisytoot @promovicz @laurenshof @cwebber

@esm

Attitudes like this are exactly why I call fedi the linux of social media

Is it based on FOSS? Yes

Is it better than the alternative? Mostly

Do most people still use the alternative due to it being less daunting to get into? Yes

Is it full of smug dudebros that decry the alternative as ontologically evil at every single opportunity even when it’s not relevant, helpful, necessary or (in some cases) even correct? Oh my god yes

Like that’s not to say bluesky doesn’t have its issues because it absolutely does but ranting about how it was made by hashtag satan himself long live hashtag mastodon helps exactly nobody

@laurenshof “It’s OK if you don’t get it”