Re: Thinking about Webfinger

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 <mailto: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 <mailto: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 <http://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
>>