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.
-
@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.
-
@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
@evan @patmikemid @kopper @hongminhee Okay, sorry for blowing up in public, this is a heated issue for me, and something I strongly regret us not just shipping an answer for, and something I have been troubled by for what's now, well, a decade. But I should have taken this to DMs rather than blowing up in public. Mea culpa.
-
@aeva the thundering herd?
@evan @cwebber @patmikemid @kopper @hongminhee the json ld thing
-
@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@cosocial.ca on the topic of shared caches as thundering herd mitigation... I spent a little bit of time trying to guard against it, and most of the load is just AP GETs.
Nginx cache was all I needed to handle the thundering herd, although I'll admit I haven't tested it against a good evanp or tchambers boost.
I'll write it all up as a separate topic another day.
-
@evan @cwebber @patmikemid @kopper @hongminhee the json ld thing
-
@evan @cwebber @patmikemid @kopper @hongminhee the json ld thing
@aeva
Premium pot-stirring there -
@trwnh i was replying to a post that wanted all expanded terms.
@evan @trwnh @cwebber @kopper @hongminhee I think it would be great to have everything expanded besides the required as2 context.
The results of the compaction algorithm would change if new things migrate into schema.org, so technically a document could become invalid or break without being modified, but this would be a lot better otherwise I guess.
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