`keyId` is a problem.
General Discussion
6
Posts
3
Posters
0
Views
-
keyIdis a problem.Generally speaking, most Actors have a `keyId' that looks something like:
https://enigmatick.social/user/jdt#main-keyWhen an
inboxPOSTarrives from an unknown user, we can chop off the bit including#main-keyand we can pull the remaining URL as the Actor's ID.But some implementations decided they should use
/main-keyinstead. That indicates that thekeyIdformat is unreliable and not well-specified. So I switched to deferring this header check for unknown Actors deeper into my ingestion pipeline so that I could retrieve theactorstring from the object being sent. That works pretty well.But
GETrequests. Likefollowers_synchronization. Dammit. There's no object to refer to. So we're back to parsing thekeyIdand hoping for meaning.Out of 124,007 Actors in my database, 587 do not comply with the
#main-keyconvention.enigmatick=> select count(*) from actors where as_public_key->>'id' NOT LIKE '%#main-key'; count ------- 587 (1 row)For full coverage, I need to accommodate
/main-keyand#keyas well#ActivityPub
-
keyIdis a problem.Generally speaking, most Actors have a `keyId' that looks something like:
https://enigmatick.social/user/jdt#main-keyWhen an
inboxPOSTarrives from an unknown user, we can chop off the bit including#main-keyand we can pull the remaining URL as the Actor's ID.But some implementations decided they should use
/main-keyinstead. That indicates that thekeyIdformat is unreliable and not well-specified. So I switched to deferring this header check for unknown Actors deeper into my ingestion pipeline so that I could retrieve theactorstring from the object being sent. That works pretty well.But
GETrequests. Likefollowers_synchronization. Dammit. There's no object to refer to. So we're back to parsing thekeyIdand hoping for meaning.Out of 124,007 Actors in my database, 587 do not comply with the
#main-keyconvention.enigmatick=> select count(*) from actors where as_public_key->>'id' NOT LIKE '%#main-key'; count ------- 587 (1 row)For full coverage, I need to accommodate
/main-keyand#keyas well#ActivityPub
@jdt You're supposed to fetch the
keyIdfirst, then fetch itsowner(orcontroller).
But in practice its either/main-key(GoToSocial) or fragment ID, so it is indeed possible to save a HTTP request. -
keyIdis a problem.Generally speaking, most Actors have a `keyId' that looks something like:
https://enigmatick.social/user/jdt#main-keyWhen an
inboxPOSTarrives from an unknown user, we can chop off the bit including#main-keyand we can pull the remaining URL as the Actor's ID.But some implementations decided they should use
/main-keyinstead. That indicates that thekeyIdformat is unreliable and not well-specified. So I switched to deferring this header check for unknown Actors deeper into my ingestion pipeline so that I could retrieve theactorstring from the object being sent. That works pretty well.But
GETrequests. Likefollowers_synchronization. Dammit. There's no object to refer to. So we're back to parsing thekeyIdand hoping for meaning.Out of 124,007 Actors in my database, 587 do not comply with the
#main-keyconvention.enigmatick=> select count(*) from actors where as_public_key->>'id' NOT LIKE '%#main-key'; count ------- 587 (1 row)For full coverage, I need to accommodate
/main-keyand#keyas well#ActivityPub
@jdt the fragment in a JSON-LD document IRI has a semantic meaning that goes back to RDF: https://www.w3.org/TR/rdf11-concepts/#section-fragID
> a secondary resource that is usually a part of, view of, defined in, or described in the primary resource, and the precise semantics depend on the set of representations that might result from a retrieval action on the primary resource.
-
@jdt You're supposed to fetch the
keyIdfirst, then fetch itsowner(orcontroller).
But in practice its either/main-key(GoToSocial) or fragment ID, so it is indeed possible to save a HTTP request.@silverpill@mitra.social That makes sense. I guess I was getting a little bit spun around by the idea that the
keyIdis not the Actoridand thinking too hard about it. -
@jdt the fragment in a JSON-LD document IRI has a semantic meaning that goes back to RDF: https://www.w3.org/TR/rdf11-concepts/#section-fragID
> a secondary resource that is usually a part of, view of, defined in, or described in the primary resource, and the precise semantics depend on the set of representations that might result from a retrieval action on the primary resource.
@mariusor@metalhead.club That's great context; thanks!
-
@mariusor@metalhead.club That's great context; thanks!
@jdt the way I interpret it for JSON-LD documents is that the fragment is the actual name of the property inside the document that the IRI refers to. So in the case of a public key would be https://example.com/jdoe#publicKey (instead of jdoe#main)
I haven't seen anything in the documentation to give a more explicit, or different, mechanism.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@jdt the way I interpret it for JSON-LD documents is that the fragment is the actual name of the property inside the document that the IRI refers to. So in the case of a public key would be https://example.com/jdoe#publicKey (instead of jdoe#main)
I haven't seen anything in the documentation to give a more explicit, or different, mechanism.
-
@mariusor@metalhead.club That's great context; thanks!
-
@silverpill@mitra.social That makes sense. I guess I was getting a little bit spun around by the idea that the keyId is not the Actor id and thinking too hard about it.
-
@jdt the fragment in a JSON-LD document IRI has a semantic meaning that goes back to RDF: https://www.w3.org/TR/rdf11-concepts/#section-fragID
> a secondary resource that is usually a part of, view of, defined in, or described in the primary resource, and the precise semantics depend on the set of representations that might result from a retrieval action on the primary resource.
-
@jdt You're supposed to fetch the keyId first, then fetch its owner (or controller).
But in practice its either /main-key (GoToSocial) or fragment ID, so it is indeed possible to save a HTTP request.
-
keyId is a problem.
Generally speaking, most Actors have a `keyId' that looks something like:
https://enigmatick.social/user/jdt#main-keyWhen an inbox POST arrives from an unknown user, we can chop off the bit including #main-key and we can pull the remaining URL as the Actor's ID.
But some implementations decided they should use /main-key instead. That indicates that the keyId format is unreliable and not well-specified. So I switched to deferring this header check for unknown Actors deeper into my ingestion pipeline so that I could retrieve the actor string from the object being sent. That works pretty well.
But GET requests. Like followers_synchronization. Dammit. There's no object to refer to. So we're back to parsing the keyId and hoping for meaning.
Out of 124,007 Actors in my database, 587 do not comply with the #main-key convention.
enigmatick=> select count(*) from actors where as_public_key->>'id' NOT LIKE '%#main-key'; count ------- 587 (1 row)For full coverage, I need to accommodate /main-key and #key as well
#ActivityPub
-
@reiver I'd consider interoperating social networks to be "federated", but I know it's not a precise term. There are similar ambiguities with other commonly used terms: decentralization, server, node, instance, and so on. We have our personal definitions but find that others have a different mental model than ours. It might be interesting to have a collaborative social web glossary that captures the variations of how these terms are used.
-
@rimu@mastodon.nzoss.nz Definitely. Offloading the static assets to nginx is a big win. Varnish adds a layer of serving from memory that takes it up a notch. Like having your own Fastly pop.
It does require some configuration nuance to be sure you aren't serving cached assets to the wrong connections (e.g., authenticated GET requests that shouldn't be shared beyond a specific session).
