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 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.
>

Many excellent points have been raised, particularly regarding the benefits
of mapping out identity, canonical identity, migration of identity, and
interoperability of identity in greater detail. One aspect that seems to be
lacking is consistency across systems, such as Solid and ActivityPub. While
both use linked data, they have not yet achieved interoperability.

Within the fediverse, canonical identity can also change. A potential
solution could be a consistent system that employs the same JSON data model
for all identities at the W3C. Although some tweaks may be needed for
different systems, establishing a common core based on current
functionality and future considerations could be advantageous.


>
> 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
>>
>>
>