@kopper @gugurumbe I just don't think the downside of having to cache the results of context URL fetches outweighs that.

@evan @kopper @hongminhee But that means either:

- Users don't get to see content that has been federated to them for *minutes*
- Unless we show unverified messages, allowing for windows of impersonation attacks, in which substantial reputational damage can be done!

And also:

- Whenever I boost several of @vv's posts, her server can be down *for a while*. Random delays can help reduce load but not as substantially as signature verification
- This has to be done for both the activity *and* the object
- And there's no reason to include either the activity or the object if you care about not risking impersonation attacks, because you might as well just send {"@id": "https://example.org/post/12345/"}

@evan @patmikemid @kopper @hongminhee Trust *then* verify?! That means accepting windows of impersonation attacks necessarily then, right...?!

@evan @gugurumbe @cwebber @kopper @hongminhee only for terms defined in AS2, though?

if the activitystreams context is missing in an application/activity+json document, then you MUST assume/inject it. this means you can't redefine "actor" to mean "actor in a movie".

otherwise, you don't have to augment the context with anything else. "https://w3id.org/security#publicKey" is a valid property name. the proposal is to not augment the normative context where possible. no parsing context if there is no context

@julia you don't have to publish as soon as you receive it; you just have to publish before the user loads it.

If the pattern doesn't work for you right now, no problem. As Sharkey scales, I hope you remember it!

@trwnh i was replying to a post that wanted all expanded terms.

@gugurumbe @cwebber @kopper @hongminhee

@kopper @evan @gugurumbe i think you can treat context identifiers as aliases. if you are already in a situation where you generally have to inject corrected contexts, then this should be doable.

@cwebber yes. Like I said, very low risk. If you want to be absolutely safe, wait until your first user reads the content before verifying it. It's usually not immediate. Most users aren't online. (TM)

@patmikemid @kopper @hongminhee

@evan @patmikemid @kopper @hongminhee I would consider myself a user which, when at her computer, is in a state we might call "terminally online"

@cwebber lucky you, you get all the first deliveries!

@patmikemid @kopper @hongminhee

@evan @cwebber @patmikemid @kopper @hongminhee *sheepishly raises hand* why not standardize what everyone ended up doing instead since that seems to be faster *ducks*

@aeva the thundering herd?

@cwebber @patmikemid @kopper @hongminhee

@cwebber @evan @kopper @hongminhee

I may be naive and am not an expert here, but in my musings on a protosocial AP extension I imagined a clean separation of "message bus" where you'd want closed-world predictable msg formats defined by some schema (perhaps JSON Schema or LinkML). These msgs would JSON-LD formatted but validated as plain JSON.

And then there would be the linked data side of the equation, where a semantic web is shaping up that is parsed with the whole set of open standards that exists here, but separate of the message bus. This is then a hypermedia, HTTP web-as-intended side. Open world and follow your nose, for those who want that, or minimum profile for the JSON-only folks.

It occurs to me these require separate/different extension mechanisms, guidelines and best-practices. The linked data part lends itself well for content and knowledge presentation, media publishing. While the msg bus gives me event driven architecture and modeling business logic / msg exchange.

@cwebber @evan @kopper @hongminhee

See the diagram sketch in my other toot posted today:

https://social.coop/@smallcircles/116099511464629495

Protosocial would further prescribe how an AsyncAPI definition can be obtained from an actor, which defines the service it provides i.e. msg formats and msg exchanges. AsyncAPI might need to be extended to adequately model things.

@evan @patmikemid @kopper @hongminhee I'm sorry hold on Evan I'm sorry but it's NOT very low risk. That's a COMPLETE misunderstanding of the information landscape we are currently in.

Trust THEN verify?!?! Trust AND THEN verify?!?!!?!?!?!?

"A random several minutes" until we know whether or not the content delivered authentically is from said actor...

Even ONE minute is enough for someone to read, and believe, something false, and to reply, or to *take action*. Or to boost a post, which is then distributed across the fediverse, and then seen by a bunch of other nodes which also have not yet verified?

Trust AND THEN verify doesn't make sense!!!

AAAAAA I am losing my marbles over this one

@cwebber some last thoughts on digital signatures for solving the thundering herd problem:

Unless the author's signing key is saturated in the network, you're going to have a thundering herd for the key, anyways. It's just pushing the problem down the line.

@evan If it's a popular author, which most commonly is the type who causes the thundering herd, then the chances the key is cached is very high!

@cwebber

If you don't think waiting until the first user loads the content to verify the content is an acceptable risk, there are still other solutions. One I like is using a content-addressed shared cache for public data, like IPFS. We have `alsoKnownAs` as a nice way to include this URI.

@cwebber I think the use case you mentioned was an author with a small following getting boosted by one with a large following.

Regardless, even if the caching level is 90%, you're still doing a big percentage of the original herd.