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

I think this provisional registration is a good idea.  One of the central
premises of Bluesky is that you can migrate your online presence between
servers without loss of subscriptions or data, and it's hard to see how to
do this without a URI schema that isn't intrinsically tied to a host, the
way that "http" URIs are. It remains to be seen if this will actually work,
but it's a compelling idea.

On Sat, May 6, 2023 at 12:28 PM <bnewbold@robocracy.org> wrote:

>
> [sorry for the dupes folks, trying yet again from personal email after a ]
> [spam bounce from @blueskyweb.xyz. Have contacted support@ietf.org       ]
>
> --------
>
> Hi Melvin! Thanks for your comments. Reply in-line below.
>
> On Sat, May 6, 2023 at 8:24 AM Melvin Carvalho <melvincarvalho@gmail.com>
> 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_______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review
>