`keyId` is a problem.
General Discussion
8
Posts
4
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.
-
@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 @jdt For keys, the algorithm to resolve the key's actor/owner is what @silverpill described (fragmented or otherwise). To dereference RDF fragments in general, you must retrieve the primary resource and search for a subject with the full IRI as the id (including fragment). The fragment does not generally reference a property (RDF predicate) in the primary resource, but it could in specific cases.
-
@mariusor @jdt For keys, the algorithm to resolve the key's actor/owner is what @silverpill described (fragmented or otherwise). To dereference RDF fragments in general, you must retrieve the primary resource and search for a subject with the full IRI as the id (including fragment). The fragment does not generally reference a property (RDF predicate) in the primary resource, but it could in specific cases.
@eyeinthesky@mastodon.social Thanks. In your description, does "primary resource" refer to
https://enigmatick.social/user/jdt#main-keyorhttps://enigmatick.social/user/jdt?That matters since the latter is not known as accurate until the resolution is complete.
Practically speaking, it's clear that I can retrieve the Actor resource using the fragment ID (
https://enigmatick.social/user/jdt#main-key) and then retrieve theownerfield from thepublicKeyfield of that object to arrive at the Actor ID. Although since the leap to look in thepublicKeyfield doesn't seem like it's specified by LD-JSON, I suppose just pulling theidfrom the returned Actor object directly might be as valid.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@soatok @ligasser @bonfire let's start a thread to make sure we are clear amongst ourselves! We all really want to see collaborative and interoperable solutions, especially when so much expert thought has gone into them
-
@alisynthesis The initial idea is that all fediverse apps (clients and servers) should implement the standard for maximum interoperability. But it's definitely worth thinking about what we could do to make that possible in any case!
-
@bonfire is it feasible that someone could build a chat client that would let any Fediverse account privately talk with any other Fediverse account?
Because that would be insanely cool.
-
@ligasser @bonfire Not sure, but:
Specification: https://github.com/fedi-e2ee/public-key-directory-specificationImplementation: https://github.com/fedi-e2ee/pkd-server-phpAnnouncement: https://soatok.blog/2025/12/15/announcing-key-transparency-fediverse/The AuxData thing should also be useful for folks that want to build atop my feature to add transparency to other types of public keys (or any other public commitments of static data, such as security researchers publishing hashes of vulnerabilities being disclosed).
-
We hope this will enable the fediverse to become a safer space for activists and communities to organise, coordinate, and collaborate meaningfully. By making secure, user-friendly messaging a core part of the fediverse, we can help lay the groundwork for decentralised networks where people can go beyond talking in the mythical ‘global town square’ and actually organise and accomplish things together.
-
RE: https://socialwebfoundation.org/2025/12/19/implementing-encrypted-messaging-over-activitypub/
Big news for the #Fediverse! End-to-end encryption is coming to #ActivityPub.
@swf with support from @sovtechfund is coordinating two interoperable implementations.
Bonfire is proud to be one of these first two projects, alongside #Emissary by @benpate
We think #E2EE should simply be the default for any private communications, and we’re especially thrilled to bring private, trusted collaboration to the fediverse.
-
@eyeinthesky@mastodon.social Thanks. In your description, does "primary resource" refer to https://enigmatick.social/user/jdt#main-key or https://enigmatick.social/user/jdt?
That matters since the latter is not known as accurate until the resolution is complete.
Practically speaking, it's clear that I can retrieve the Actor resource using the fragment ID (https://enigmatick.social/user/jdt#main-key) and then retrieve the owner field from the publicKey field of that object to arrive at the Actor ID. Although since the leap to look in the publicKey field doesn't seem like it's specified by LD-JSON, I suppose just pulling the id from the returned Actor object directly might be as valid.
-
@mariusor @jdt For keys, the algorithm to resolve the key's actor/owner is what @silverpill described (fragmented or otherwise). To dereference RDF fragments in general, you must retrieve the primary resource and search for a subject with the full IRI as the id (including fragment). The fragment does not generally reference a property (RDF predicate) in the primary resource, but it could in specific cases.
