Re: Thinking about Webfinger

po 8. 5. 2023 v 11:47 odesílatel Matthias Pfefferle <matthias@pfefferle.org>
napsal:

> Hi,
>
> when we are already discussing WebFinger, I would love to add a pro
> argument of integrating WebFinger even more into the ActivityPub spec, to
> decouple some of the "single platform“ issues. The most criticized part of
> ActivityPub is actually the identity portability, the direct dependency of
> the identity to the current used platform (I think this is also discussed
> in an other mailing thread)
> https://atproto.com/guides/faq#why-not-use-activitypub. Protocols like AT
> and nostr seem to have some better handlings for that and ironically
> nostr’s NIP-05 is very similar to WebFinger (sadly they refused to use
> WebFinger https://github.com/nostr-protocol/nips/issues/482 ) but used a
> bit different.
>

I'd like to mention that NIP-05 [1] (which is similar to webfinger) has
been working effectively. It enables users to obtain JSON from a
.well-known domain name associated with a public key, which then points
back to the public key. Although it introduces another JSON format, it was
standardized quickly and offers ease of migration. It can also serve as a
bridge to existing web systems, allowing users to verify their accounts at
a domain of their choice, similar to the Twitter blue check mark.  BlueSky
I believe are making their own version of NIP-05.

The team at Kosmos proposed an integration worth considering: "NIP-05 user
addresses (i.e., make your pubkey discoverable via your username@kosmos.org
address)" [2]. Integrating this into both Solid and the fediverse could be
relatively straightforward, as it uses regular JSON without a new URI
scheme. While it doesn't utilize linked data, there is potential for
modeling everything in Nostr with linked data in the future, as indicated
by the ongoing development of a vocabulary that I am working on [3].  But
that will be a longer journey.

[1] https://github.com/nostr-protocol/nips/blob/master/05.md
[2] https://gitea.kosmos.org/kosmos/akkounts/pulls/101
[3] https://w3id.org/nostr


> I would love to see WebFinger used more in the NIP-05 way, as a proxy-like
> identifier for ActivityPub. Hosting WebFinger on a self-owned domain is
> very easy and having a small service to customize the JSON too. With a
> better WebFinger support, a user will be able to control his ID (
> username@owndomain.tld) and delegate the ActivityPub-part (and and a lot
> of others, maybe its possible to decouple ActivityPub even more) to, for
> example, Mastodon. This is already possible, but Mastodon is using the
> canonical identifier that is linked in the JSON instead of the WebFinger
> ID. WebFinger as canonical ID in the fediverse, would allow users to change
> servers without much effort (maybe import/esport follower/following lists).
> Because WebFinger is already common sense in the fediverse, it would not
> cost that much of investment, to have a first step into a more decoupled
> fediverse ecosystem.
>
> Matthias Pfefferle
>
> Am 07.05.2023 um 07:00 schrieb Melvin Carvalho <melvincarvalho@gmail.com>:
>
>
>
> ne 7. 5. 2023 v 1:43 odesílatel Bob Wyman <bob@wyman.us> napsal:
>
>> Melvin wrote:
>>
>>> in theory you could look up an http url with webfinger, this question
>>> did actually come up during the discussions. But of course you'd never
>>> do that, because http has its own tooling curl, the browser, xhr etc
>>
>>
>> Looking up HTTP URLs with WebFinger not only came up in discussions, it
>> is the second example given in the RFC!: (See "3.2.  Getting Author and
>> Copyright Information for a Web Page")
>>
>>>    GET /.well-known/webfinger?
>>>           resource=http%3A%2F%2Fblog.example.com
>>> <http://2fblog.example.com/>%2Farticle%2Fid%2F314
>>>           HTTP/1.1
>>>      Host: blog.example.com
>>
>> The example response JRD includes data about copyright, etc. and I assume
>> it could also provide stuff like public keys, links to did documents, etc.
>>
>
> Webfinger does have an example of how to get JSON data from an HTTP URI.
> However, a great deal of the W3C web stack is all about getting JSON data
> from an HTTP URI.  Indeed, that's exactly what powers the fediverse.
>
> http://scripting.com/manifesto/rulesforstandardsmakers.html
>
> Dave Winer's presentation argues persuasively that doing the same thing in
> two different ways should be avoided in standards.  Webfinger's HTTP lookup
> is a good example of that.  Indeed, although webfinger is not part of
> ActivityPub it is still around, where having one JSON format for the whole
> ecosystem would be simpler.
>
>
>>
>> Erin Shepard wrote:
>>
>>> There's no need for any changes for any URIs with a host component (any
>>> containing an @ or //, broadly)
>>
>>
>> The WebFinger specification does not require that URI's contain either
>> "@" or "//" and, although it strongly recommends that you should use a
>> URI's host to do lookups, it doesn't require that one use any particular
>> WebFinger service. Also, the spec explicitly permits the lookup of URIs
>> that don't have a host component. It says:
>>
>>> The host to which a WebFinger query is issued is significant.  If
>>> the query target contains a "host" portion (Section 3.2.2 of RFC 3986),
>>> then the host to which the WebFinger query is issued SHOULD be the same as
>>> the "host" portion of the query target, unless the client receives
>>> instructions through some out-of-band mechanism to send the query to
>>> another host.  *If the query target does not contain a "host" portion,
>>> then the client chooses a host to which it directs the query using
>>> additional information it has.*
>>
>>
>> So, it seems to me that the RFC allows me to use just about any WebFinger
>> service that I like for lookups. It also seems like I should be able to
>> extract a host from a did:web like "did:web:example.com:user:alice" and
>> use it even though it contains neither "@" nor "//."
>>
>> There are, I think, some good reasons for wanting to use a WebFinger
>> other than that given by a host. (Even though doing so introduces
>> man-in-the-middle issues.) Assuming that I trust the WebFinger service, I
>> might want to preserve privacy by not connecting directly to the "proper"
>> host WebFinger, and thus leaking my ip address. Or, in the case of doing
>> lookups for obscure did-methods, I might simply not have the necessary code
>> in my client.
>>
>> Given that these things are permitted by the WebFinger RFC, and even
>> explicitly mentioned in the RFC, I don't understand the hesitancy to use
>> them
>>
>> bob wyman
>>
>>
>