Re: [Uri-review] Registration request for "at" URI scheme

[Melvin Carvalho <[e-mail]>]

so 6. 5. 2023 v 21:22 odesílatel Bryan Newbold <[e-mail]>
napsal:

> Hi Melvin! Thanks for your comments. Reply in-line below.
>
> On Sat, May 6, 2023 at 8:24 AM Melvin Carvalho <[e-mail]>
> wrote:
>
>> The JSON objects already have 7 different types of identifiers, and
>> there's more (e.g. CID) and when you replace did:plc it will be at least
>> 9.  See:
>>
>
> This JSON document is a DID document, in W3C specification. I'm not sure
> why the number of identifier types is relevant to this URI scheme request.
>
> At the level of the at:// URI scheme, we specify that a DID be used, not
> that did:plc specifically is required. It is true that there are a large
> number of DID resolution methods, and that from a pragmatic standpoint we
> strongly recommend only using did:plc and did:web in the AT Protocol
> ecosystem, but this is not a constraint at the URI scheme level.
>
> We will also take this as a reminder to finish formalizing and register
> the did:plc resolution mechanism with W3C.
>
> I think it ought not be an issue to register "at", but I really think you
>> might be saving yourself some trouble if you hold off for a bit and
>> complete the protocol.  at:// likely is not needed at all.
>>
>
> Some aspects of the protocol are still under development, but our use of
> the at:// URI schema is stable. There are third party implementations of
> the protocol under development, and several independent parties handling
> real-world data with AT URIs embedded in them. This seems like an
> appropriate time to provisionally register the URI scheme, and progress to
> "permanent" registration when the protocol specification matures.
>
>
>> The HTTP identifiers can be done with http:// and the did identifers can
>> be done with did:, which is part of the design of URIs.  There's not a huge
>> need to put at:// in front of either, IMHO
>>
>
>  There are several good reasons to have a URI scheme distinct from HTTP in
> AT Protocol, here are two:
>
> Accounts ("repos") in AT Protocol are easy to migrate between service
> providers. This means that the *location* of the current authoritative host
> for a repo changes over time. An HTTP URL would indicate one specific
> location for the repo and would go stale after a migration. As you note
> above, we *do* use an HTTP URL for the *current* location of the PDS, in
> the DID document, but this value changes over time, while the AT URIs are
> intended to be stable.
>
> Content in AT Protocol is re-distributable between multiple services and
> actors, and the mechanism for transportation is flexible. The current
> protocol uses HTTP and WebSocket, but content can also stored in plan files
> on disk, etc. There is a need to reference specific records ("resources")
> regardless of location and transportation mechanism. This is what AT URIs
> are for.
>

Thank you for the additional information. As a casual observer of this
list, I believe there should be no issue with this being a provisional URI
scheme. I happen to chair the W3C Nostr Community Group [1], and I'm aware
that BlueSky aims to interoperate with Nostr and other protocols. Please
feel free to join us for further discussion.

Regarding the at:// protocol, designers must determine when to reuse
existing protocols and when to create new ones. The examples provided for
the at URI scheme [2] initially seemed quite similar to the http protocol.
While the hostnames like alice.host.com look like http, you point out that
the authority may change over time and hence require a lookup.  That might
work, albeit with some added complexity.

A minor note of caution is to ensure that the resulting URI adheres to
RFC3986, which does not allow for two hashes in the identifier. Be mindful
of this when designing the authority part or any other components.

I'm excited to see how this project evolves, especially in the free
software community. There is hope is that the client-side app might be
open-sourced, since it has received much praise.

[1] https://www.w3.org/community/nostr/
[2] https://atproto.com/specs/at-uri-scheme


> Cheers,
>
> --bryan
>