Re: Thinking about Webfinger

po 8. 5. 2023 v 12:18 odesílatel Melvin Carvalho <melvincarvalho@gmail.com>
napsal:

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

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