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

[[e-mail]]

[sorry for the dupes folks, trying yet again from personal email after a ]
[spam bounce from @blueskyweb.xyz. Have contacted [e-mail]       ]

--------

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.

Cheers,

--bryan