Re: [art] The web+ URI scheme prefix

["Roy T. Fielding" <[e-mail]>]

> On Feb 22, 2023, at 7:15 AM, Soni L. <[e-mail]> wrote:
> 
> The fact that browsers do treat web+ as special and the fact that it's not documented/acknowledged by the IETF already has a potential to cause unexpected and unwelcome consequences.
> 
> Yes, in an ideal world it would've been more like web://target/protocol/data (e.g. web://example.org/ap/user/Foo) but browsers already went with web+ so we're sticking with web+. It's a historical pain point.
> 
> And we uh did just actually release an app that supports fallbacks for web+. (Also, "fallback" is the language used by the Windows APIs we're using.)

Argh, this is all getting confused. I did not suggest defining a new universal scheme
for all future protocols/names to be hierarchically bound within.

The URI scheme is the bit that is universal. The Web is designed for new schemes to
be defined when and where they are needed. Whether the scheme is handled as an
alias (resolved to some other scheme) or as a network protocol (resolved by accessing
a resource on the Internet) or as a name (not resolved at all but useful for comparison)
is completely irrelevant to the conceptual purpose of URI schemes.

The only reason this is difficult, in any way, is because someone in browser design
(i.e., someone trying to fix what they thought was a bug) decided that having a
fixed set of URI schemes was "better" because then all of the other schemey:hrefs
could be treated as relative URLs. This is what happens when you think "fixing the
Web" means ignoring HTML authoring mistakes.

Later, after years of people pointing out that this was a horrible thing to do to
the Web because it ended the extensibility of schemes, browser folks added
the safelisted schemes for recognized extensions and the "web+schemes"
workaround for private extensions.  The web+ prefix serves the same purpose
as the x- prefix of IMS field names, and is equally flawed in practice.

When you come to the IETF and say we need a registry for web+ schemes,
the answer is that the ENTIRE purpose of web+ is to not be registered schemes.
Register a normal scheme and ask for it to be safelisted. End of discussion.

The problem with using extensions as a resolution mechanism for fediverse
identifiers is that ActivityPub uses https identifiers, and those https identifiers
require an end-to-end encryption to the origin for both privacy and security.

A non-standard mechanism that intercepts those identifiers and sends them
to some other federated service authority for resolution (or even a third party
extension that merely rewrites the URL) would violate the security properties
required of the https identification mechanism.

Hence, the only way to implement authority-independent identification of
ActivityPub resources is for the link author to choose a URI scheme that
is safe for that purpose, which means a publicly standardized and registered
URI scheme that is commonly implemented within the browser's trusted
scheme resolvers.

The way to do that is to define such a scheme as an Internet Draft (or a
W3C draft recommendation) and have all the right people verify that it
defines a safe implementation of fediverse-identification even though
it only presumes a secure channel to the user's local instance of choice,
rather than a secure channel to the link author's personal instance.
And then convince the major browsers to implement that scheme.

It is easier than it sounds. Far easier than trying to debate your way into
a design that makes it easy for untrusted parties to observe and
potentially report upon every user's fediverse requests. The web+
mechanism might be useful for prototypes, but is deliberately not
secure enough for commonly standardized protocols like ActivityPub.

....Roy