I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
-
@patmikemid I call it trust, then verify. Usually caching the data with a ttl of a short number of minutes is enough.
@evan @patmikemid @kopper @hongminhee Trust *then* verify?! That means accepting windows of impersonation attacks necessarily then, right...?!
-
@gugurumbe @cwebber @kopper @hongminhee AS2 requires compacted JSON-LD.
@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
-
@evan@cosocial.ca @cwebber@social.coop @hongminhee@hollo.social @kopper@not-brain.d.on-t.work I feel like deferring activity resolution and publishing based on online status would only serve to create more reasons for your average person to feel that the fediverse is unstable- explaining the logistics of the herd problem to someone who doesn't know what a distributed system is is kinda difficult.
@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!
-
@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
@trwnh i was replying to a post that wanted all expanded terms.
-
@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.
-
@evan @patmikemid @kopper @hongminhee Trust *then* verify?! That means accepting windows of impersonation attacks necessarily then, right...?!
@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 -
@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"
-
@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!
-
@cwebber lucky you, you get all the first deliveries!
@evan @cwebber @patmikemid @kopper @hongminhee *sheepishly raises hand* why not standardize what everyone ended up doing instead since that seems to be faster *ducks*
-
@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?
-
@evan @kopper @hongminhee The problem is that signing json-ld is extremely hard, because effectively you have to turn to the RDF graph normalization algorithm, which has extremely expensive compute times. The lack of signatures means that when I boost peoples' posts, it takes down their instance, since effectively *every* distributed post on the network doesn't actually get accepted as-is, users dial-back to check its contents.
Which, at that point, we might as well not distribute the contents at all when we post to inboxes! We could just publish with the object of the activity being the object's id uri
@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
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.
-
@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'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 lucky you, you get all the first deliveries!
@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.
-
@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 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.
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.
-
@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 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.
-
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.
@evan ESPECIALLY if it's on something like IPFS, you need signatures, because there's no "see if it's on this instance" to speak of as a trust step!!!!
Am I am losing my mind over here
-
@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 it's ok if you don't get it. You don't have to use it. There are other ways to handle the thundering herd, like shared caches.
-
@evan ESPECIALLY if it's on something like IPFS, you need signatures, because there's no "see if it's on this instance" to speak of as a trust step!!!!
Am I am losing my mind over here
@cwebber yes.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login