Re: Thinking about Webfinger

Melvin wrote:

> 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

Of course, "upgrades" are not inevitable. They only happen when there is a
real need understood by many. Nonetheless, there are ways that one can
"gracefully" move forward without introducing backwards compatibility
issues. For instance:

It seems to me that the most graceful path forward would be to write an
internet-Draft that:

   - Specifies how WebFinger services should respond when HTTP "Accept"
   headers are used (i.e."Accept: application/ld+json").
   - Alternatively, one could add a new "format" parameter to a WebFinger
   request that might initially be defined as having values of either "jrd" or
   "json-ld." This "format" parameter would be optional, in the same way that
   the "rel" parameter is optional.
   - Define the JSON-LD format for responses.

My assumption is that servers would be permitted to ignore either the
Accept headers or the format parameter. Thus, clients would still be
well-advised to know how to consume both JRD and JSON-LD.

Such an approach would allow WebFinger service implementers to begin
providing JSON-LD responses, when requested, without having any real impact
on those who have implemented JRD-only systems in the past. At some future
date, if it appears that the vast bulk of WebFinger requests are requesting
JSON-LD, it might be appropriate to write a new ID that schedules a shift
in the default for some number of years in the future.

I suppose there may be some who would insist on implementing JSON-LD-only
WebFinger but have some reason to oppose the use of either HTTP Accept
headers or a format parameter... If they could establish some compelling
reason to address their desires, one might define "webfinger.json-ld" as an
alternative to "webfinger." Thus, one could have:

> https://example.com/.well-known/webfinger?resource=acct%3Alice%
> 40example.com (Returns JRD), or
> https://example.com/.well-known/webfinger?resource=acct%3Alice%
> 40example.com&format="json-ld" (Returns JSON-LD), or
> https://example.com/.well-known/webfinger.json-ld?resource=acct%3Alicel%
> 40example.com (Returns JSON-LD).


Would such approaches, or something similar, serve your needs? It seems to
me that any attempt to change or deprecate the use of JRD is likely to be a
non-starter.

Can you explain in more detail the downsides of using JRD? Also, how would
the JSON-LD format differ from the JRD format? Are you suggesting something
more than just adding support for "@context" to what's currently in the JRD
specification, or are you suggesting that the full set of JSON-LD syntax
tokens and keywords could be exploited? Would you allow arbitrary JSON-LD
content or would this new format be limited to the limited set of things
that XRD/JRD can talk about (i.e. subject, aliases, links, etc.)?

Melvin also wrote:

> For example RFC 7033 the term "aliases" and the term "alias" has long been
> talked about in linked data having value.

I am not sure what this sentence means. Can you elaborate a bit?

bob wyman

On Sat, May 6, 2023 at 1:44 PM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> so 6. 5. 2023 v 19:23 odesílatel Evan Prodromou <evan@prodromou.name>
> napsal:
>
>> 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 <melvincarvalho@gmail.com> 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?
>>
>>
>>