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

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

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

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

But anyway

Long conversation potentially

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

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