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

[Eliot Lear <[e-mail]>]

As another casual observer, can I suggest that you use a slightly more 
descriptive scheme name?  "at" is heavily overloaded, and a name that 
provides at least a guess what this is will serve the user better.

Eliot

On 07.05.23 03:26, Melvin Carvalho wrote:
>
>
> 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 
> <http://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
>
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review