Re: Thinking about Webfinger

so 6. 5. 2023 v 19:23 odesílatel Evan Prodromou <>

> Webfinger is defined at the IETF in RFC 7033 and it would probably make
> sense to discuss a revision in that organization's framework, with a draft
> RFC.
> From the pov of the social web, it would be important to retain backwards
> compatibility, since the standard is widely implemented.
> I find the changes you're proposing minimal, theoretical and de gustibus.
> I don't think they're pressing enough to justify the very real costs of
> rolling out a new version.

Thanks for your input.  Agree regarding backwards compatibility

However, upgrades to the spec or the network will have to happen one day.
And it's likely we will work out how to do that gracefully, with signaling,
opt-in and long sunset periods after the network has switched.  This kind
of thing has been pioneered in many other running open source networks via
soft forks and similar mechanisms.  Next year it will be 10 years since the
first W3C Social Web Working Group, and a lot has changed in that time.

In the longer term it might be of benefit to sketch out what a webfinger
record would look like, in activity pub style JSON.  As you say, it would
be a minimal change, probably not hard:

A Webfinger record is typically a JSON object that contains information
about the user, such as their profile URL, avatar, or ActivityPub actor
endpoint. In the context of ActivityPub, the Webfinger record would include
a link to the user's ActivityPub actor object.

There are advantages to unifying.  For example RFC 7033 the term "aliases"
and the term "alias" has long been talked about in linked data having value.

It could be a good exercise to sketch out and, so that in the longer term
implementers can use one JSON serialization, instead of two.  And one fewer
URI scheme, thereby simplifying identity, which I think will be needed at
some point.

> Evan
> On May 6, 2023 09:31, Melvin Carvalho <> wrote:
> Back in 2012 Mark Nottingham suggested a way to lookup JSON data for a
> given handle:
> /.well-known/user=bob@host
> WIth the endpoint returning JSON
> In retrospect this was a brilliant idea.  What happened with webfinger was
> a bit different
> instead of user= or acct= a new URI scheme ws minted acct:
> This was unnecessary, and there wasnt a good reason for it at the time
> that i can remember other than to use uris.
> Also at the time the JSON that came back was JRD, a whole new flavour of
> JSON modele on XRD.  However, XRD failed to gain popularity, and JRD is a
> different format to most of the fediverse.
> Would it be time to simplify webfiger in 3 ways.
> 1. no longer need the acct: URI scheme
> 2. use the simpler acct=user@host form
> 3. return a JSON serialization that is the same format as AP objects
> The existing infrastructure would need to be maintained because its used
> in places such as OIDC, however a newer endpoint could be advertised for
> newer systems, opting in.  Perhaps even could be proposed to the IETF as
> Webfinger 2.
> Is this too big a leap, or worth writing up?

Received on Saturday, 6 May 2023 17:44:25 UTC