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.
-
@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.
-
@evan @gugurumbe it's infeasible to preload all contexts, pretty much every pleroma instance hosts their own context on their own instance for example. then there is the obvious interop problems of how to handle contexts for new extensions your software is not aware of (though pretending like they're empty might work i guess?)
@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!
-
@evan @gugurumbe
here is a backwards incompatible change in a fep you authored: codeberg.org/fediverse/fep/src/branch/main/fep/b2b8/fep-b2b8.md#attributedto (specifically, the Link-and-name bit. mobile Firefox does not let me send highlights apparently)
the http signature draft->rfc change is backwards incompatible.
mastodon api to c2s is backwards incompatible for client developers (and, if done correctly, would require long and unwieldy migrations on servers. ask firefish.social users how those kinds of migrations end up)
whatever the replacement for as:summary as content warnings would be backwards incompatible. replacing as:name with as:description for media alt text is backwards incompatible (gotosocial did it, and we adapted)
making webfinger optional is backwards incompatible
backwards compatibility is not here yet. now is the second best time to get rid of legacy cruft@kopper @evan @gugurumbe that, and honestly a netsplit is probably the least of our concerns on this network; after all, we've been through this before with the migration from ostatus, and netsplits practically happen daily via defeds
-
@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:
🫧 socialcoding.. (@smallcircles@social.coop)
Attached: 1 image @julian@activitypub.space @evan@cosocial.ca Btw, some time ago in a matrix discussion I sketched how I'd like to conceptually 'see' the social network. Not Mastodon-compliant per se (though it might be via a Profile or Bridge) but back to "promised land". Where the protocol is expressed in familiar architecture patterns and borrows concepts from message queuing, actor model, event-driven architecture, etc. Then as a "Solution designer" I am a stakeholder that wants to be completely shielded from all that jazz. That should all be encapsulated by the protocol libraries and SDK's that are offered in language variants across the ecosystem. #ActivityPub et al is a black box. I can directly start modeling what should be exchanged on the bus, and I can apply domain driven design here. And if I have a semantic web part of my app I'd use linked data modeling best-practices. I would have power tools like #EventCatalog and methods like #EventModeling. https://www.eventcatalog.dev/features/visualization https://eventmodeling.org/
social.coop (social.coop)
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 @gugurumbe
here is a backwards incompatible change in a fep you authored: codeberg.org/fediverse/fep/src/branch/main/fep/b2b8/fep-b2b8.md#attributedto (specifically, the Link-and-name bit. mobile Firefox does not let me send highlights apparently)
the http signature draft->rfc change is backwards incompatible.
mastodon api to c2s is backwards incompatible for client developers (and, if done correctly, would require long and unwieldy migrations on servers. ask firefish.social users how those kinds of migrations end up)
whatever the replacement for as:summary as content warnings would be backwards incompatible. replacing as:name with as:description for media alt text is backwards incompatible (gotosocial did it, and we adapted)
making webfinger optional is backwards incompatible
backwards compatibility is not here yet. now is the second best time to get rid of legacy cruft@kopper @gugurumbe sorry, I don't understand your point.
`attributedTo` has always had a range of `Object` or `Link`. The `Link` type has always had a `name` property.
I agree, HTTP Signature suuucks for us. I think the best we can do is double-knock and cache the results. I don't think that process has even started that much.
-
@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.
