Re: Thinking about Webfinger

But what is the advantage of that URI instead of the current Actor-URI of ActivityPub (except that it always looks similar)? I think the biggest issue in decentralized networks are interoperability. Why have nostr defined NIP-05 when WebFinger does exactly the same? If the changes are only because of cosmetics and of unified JSON formats, I would prefer the IndieWeb way: Working code over specs https://indieweb.org/specifications

Matthias

> Am 10.05.2023 um 08:47 schrieb Melvin Carvalho <melvincarvalho@gmail.com>:
> 
> 
> 
> po 8. 5. 2023 v 12:18 odesílatel Melvin Carvalho <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> napsal:
>> 
>> 
>> po 8. 5. 2023 v 11:47 odesílatel Matthias Pfefferle <matthias@pfefferle.org <mailto: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 <mailto: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.
> 
> I think a better way than either webfinger or NIP-05 could be for activity pub to have its own well known area
> 
> rel="canonical"
> 
> /.well-known/ap/user/bob
> 
> Then return ActivitPub JSON
> 
> Would be killer, imho
>  
>> 
>> [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 <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 <mailto: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