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.