Re: Thinking about Webfinger

st 10. 5. 2023 v 8:59 odesílatel Matthias Pfefferle <matthias@pfefferle.org>
napsal:

> But what is the advantage of that URI instead of the current Actor-URI of
> ActivityPub (except that it always looks similar)?
>

It helps to have a canonical location that is easy to find


> I think the biggest issue in decentralized networks are interoperability.
>

Yes!


> Why have nostr defined NIP-05 when WebFinger does exactly the same?
>

I didnt personally design NIP-05, it just sprung up overnight to meet a
need, or 100s of developers iterating together.  Namely, the need for a
verified account.  It's good because it's a well=known location and
everyone knows how to use it.  It's just JSON, not a different mime type,
so it's how much of the web already works.


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

I've been a member of indieweb for many years, hosting my own identity on
my home page.  I like the idea.  But I think we all recognize that this is
not for everyone, and will not be a path to mass adoption.  There are some
nice tools in indieweb, but Linked Data offers a more granular path to
interop.


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