Capability discovery for ActivityPub applications.
This document is based on the idea described in FEP-aaa3: Listing Implemented Specifications on the Application Actor.
1 Like
Added the list of implementations and a new capability to the registry (RFC-9421 + Ed25519):
@silverpill Is it only related to HTTP capabilities or this can be extended to FEPs as well?
@silverpill @feps
@rayslava It can be extended to FEPs. However, capabilities usually can be inferred from properties and types (e.g. Question type indicates that server can accept poll votes), and in those cases explicit signaling is not necessary.
Why not simply use Nodeinfo for this? Implementing this generator for every actor type and then sending it for thousands of accounts is unnecessarily wasteful.
Edit: Okay it seems like something similar can be achieved via fep-d556 via webfinger, that wouldnt be difficult to add then.
Why not simply use Nodeinfo for this?
NodeInfo has also been discussed, but some developers and server operators don't want to publish software metadata and usage stats. The solution proposed here seems to be less controversial.
1 Like
re: Link vs the actual thing (@id)
i am not sure Link objects is the way to go. it makes more sense to me to just use the actual @id because then you can make descriptive statements about that thing out-of-band and load them into your processor.
re: registries
if you are establishing a registry then it would be useful to have precise definitions for precise identifiers. it is unclear what exactly https://datatracker.ietf.org/doc/html/rfc9421 entails, and https://datatracker.ietf.org/doc/html/rfc9421#name-eddsa-using-curve-edwards25 hints toward “eddsa using curve edwards25519”, but that is a similarly incomplete definition – it tells you how to sign some input, but not what that input should be. you would want to know the full parameters that might make up a full auth-scheme that can be signaled with the HTTP WWW-Authenticate header in cases of authentication, or included in HTTP Accept-Signature in case of inbox OPTIONS or on a failed POST.
implications for FEP process?
tangentially to this: should the FEP process have any affordances for registries? it could complicate things like “what FINAL status means” and “how to count implementers”, so it’s worth considering. i think individual FEPs can declare their own “capability identifiers” as well, since individual FEPs have the ability to contain subresources (like term definitions and so on) and act as their own namespaces.
canonical or equivalent identifiers
also tangentially, the datatracker.ietf.org URIs used are not canonical for the actual RFCs. there are several equivalent identifiers that could refer to the same thing (owl:sameAs):
doi:10.17487/RFC9421(the DOI)https://doi.org/10.17487/RFC9421(the DOI resolver)https://dx.doi.org/10.17487/rfc9421(another DOI resolver)
https://www.rfc-editor.org/info/rfc9421(what the actual DOI resolves to)urn:ietf:rfc:9421(the URN for the IETF RFC)urn:issn:2070-1721(the URN for the ISSN)https://www.ietf.org/rfc/rfc9421(an alternate resource)https://www.ietf.org/rfc/rfc9421.html(in text/html)https://www.ietf.org/rfc/rfc9421.xml(in text/xml)https://www.ietf.org/rfc/rfc9421.txt(in text/plain)
it may be wise to use a canonical identifier and also have it actually be an identifier so that equivalences can be defined and recognized wherever they might be used. see Service Discovery Identities and Service Discovery Features for prior art.
RFC 9421 actually defines an IANA registry for this in Section 6.2: HTTP Message Signature – maybe use this to form a canonical identifier? something like #alg/ed25519 or #alg:ed25519 could work, maybe even just #ed25519 if you expect there to never be a conflict between algorithm names and parameter names. you could also define something specific in a FEP, though.
1 Like
Could you provide an example? We can use an object with url property instead of Link, but I don’t see what is the benefit.
In case of RFC-9421 and RFC-9421+ed25519 capabilities, the identifiers are opaque strings. There is no document that defines how to use those signatures in Fediverse, but when such document will be written, it will be added to the registry.
I think registries fit quite well into the FEP process. Once the proposal is FINAL, you can add new entries, but you can not change them.
I agree, that would be great.
I’d like to keep these identifiers until a FEP or a report is published where the corresponding capabilities are described in detail. After that we can mark datatracker.ietf.org identifiers as deprecated.
I think capability identifiers should be HTTP URIs. Self-describing, if possible.
instead of
{
"href": "https://datatracker.ietf.org/doc/html/rfc9421"
}
it would be
{
"id": "https://datatracker.ietf.org/doc/html/rfc9421"
}
a processor could then be able to say, “hey, i know what that id is, i have some definitions right here!” and apply logic according to those definitions. the processor would know that your <software> <implements> <rfc9421> (and <https://datatracker.ietf.org/doc/html/rfc9421> owl:sameAs <rfc9421>) instead of only knowing that your <software> <implements> _:b0 and then separately that _:b0 as:href <https://datatracker.ietf.org/doc/html/rfc9421>. the former is saying “software implements rfc9421” and the latter is saying “software implements a Link whose href is rfc9421”. it doesn’t make much sense to say the software implements a Link; rather, it is implementing the RFC, which is the thing being referred to (<> in Turtle, @id in JSON-LD).
yes, the ids are opaque strings, but people can use many different identifiers for the same thing. we want at least one of the following to be true:
- people use the same id consistently globally (enforced by a central registry)
- people recognize when different ids refer to the same thing
encoding the knowledge into Turtle looks like this:
<rfc9421>
owl:sameAs
<https://datatracker.ietf.org/doc/html/rfc9421>,
<doi:10.17487/RFC9421>,
<https://doi.org/10.17487/RFC9421>,
<https://dx.doi.org/10.17487/rfc9421>,
<https://www.rfc-editor.org/info/rfc9421>,
<urn:ietf:rfc:9421>,
<urn:issn:2070-1721>,
<https://www.ietf.org/rfc/rfc9421>.
and this encoding would allow an OWL reasoner to recognize any of the above ids as referring to the same thing, for maximum robustness on the consuming side. you can imagine a similar encoding into a programming language like Python, using something like RFC9421_SUPPORTED = thing_implemented in set("https://datatracker.ietf.org/doc/html/rfc9421", ) and so on.
of course, on the publishing side, we don’t want to encourage people to use a bunch of different ids. this is where the central registry comes in. a FEP could act like one, or it could establish one. if you imagine an id like https://w3id.org/fep/xxxx/#rfc9421 and https://w3id.org/fep/xxxx/#rfc9421-ed25519 (with definitions similar to the above Turtle codeblock), then this hypothetical FEP-xxxx can refer back to https://w3id.org/fep/844e (or other such FEPs for establishing capabilities).
they would be, still. unfortunately discourse’s formatting made that invisible. to clarify, i was describing https://www.iana.org/assignments/http-message-signature/#alg/ed25519 or https://www.iana.org/assignments/http-message-signature/#ed25519 as the full id.
one slight problem with most URIs that could be used to represent the RFC itself: those URIs are owned by other social entities, so we can’t strictly say with full authoritativeness that any of them refer to the RFC, if we want everyone to agree (global consensus). we can only do this with statements about an identifier that we own, in a context that we establish. so a fep can be trusted to make authoritative statements about its own subresources, and this provides the single self-describing identifier as the entrypoint.
i don’t know if there’s anything that can be done at the https://w3id.org/fep/a4ed level or if this is more in the purview of https://w3id.org/fep/888d, but it seems like a pattern worth documenting somewhere…