Yves: Just looked at this, linked to issue we have on miniapps. It's basically something related how to define hooks based on on the URL scheme instead of doing it using media types. In that case... just skimmed it a bit earlier on ... seems that the ? mechanism is still http/https. I think there's something in webarch for that. What do they really want here? Do they just want media types, or do they want a protocol to access them.

David: I think one thing that's led people to want schemes like this in the past that they want the URL and not just the contents of the resource.

Tess: Why not just use registerProtocolHandler.

Yves: It's expensive, and (missed).

Dan: I kind of had the same question. Feels like web applications already do this. Doesn't feel like there should be a PWA-specific thing. The point of PWAs is that they're web applications; we can push back against technologies specific to PWAs, especially when web applications can already do this.

Tess: Restated: There could be some value in providing any web application that uses a web app manifest to have a way of saying what protocols they register from their manifest. But I'd want to think that's syntactic sugar, 1:1 with a call to registerProtocolHandler from the web application. Same underlying model and permissions and expectations. If we want to change the model for the PWA case, I'd want to entertain changing the model for the non PWA case. The manifest is convenience but not sole mechanism -- letting you know stuff that you could know anyway if you load the webapp -- it's letting you skip the loading. I worry that redefining the feature risks bifurcating the models. This should be by reference to registerProtocolHandler, or they should file bugs on registerProtocolHandler.

Tess: I'll take an action to review the explainer with that in mind and see if that feedback makes sense when I read it.

Dan: Bump it a week

Kenneth: looked at this and it seems sensible. Similar to register protocol handler but in the web app manifest... all can be done at "install" time. Same mitigation that exists in registerProtocolHandler. Not all protocols. Thinking about extending that a bit. Registering a scheme.. associated a title + and icon..

Dan: Tess said " could this be syntactic sugar on top of registerProtocolHandler"?

Ken: not totally – eg you can't associated an icon.

peter: you can have a tittle with registerProtocolHandler. I'd like to see the two things be more integrated. Maybe turn it to an options dictionary.

Ken: yes – also I'm worried that people will register a handler and use an icon and title that makes it look like another application. Something like that could be solved in the UI...

Yves: my comment last week was more about the use case section - e.g. for powerpoint. For magnet it's OK because it's a protocol to retrieve something. But web+powerpoint is a media type – there should be an option for what you encounter when you use a media type.

Ken: already another proposal for file extensions .. mime types vs file extensions discussion...

Peter: the thing about mime type is that you don't know what the content type is before you fetch it.

Yves: if it's in the link header you can ...

Ken: file handling proposal (#371). Instead of protocol handlers you have file handlers... so why are these not working the same way? Action thing instead of a URL. No icon associated with the file handler – should there be? Maybe these could just be "handlers" ...

Dan: feels like it could be confusing for the developer – different ways to do similar things.

Yves: if you're abusing media types and the way you're doing things based on content then it's another way of doing things differently from the current way of the web.

David: the file handling proposal is tied to the native filesystem API - lets the web page read and write files. Some concerns about native filesystem.

Ken: I still think the APIs could be similar.

Yves: official URI scheme – doesn't contain powerpoint, etc...

Peter: i noticed that registerProtocolHandler contains a list of safe schemes. That seems like something that should be harmonized or at least explained. Like to see some explanation of how this interacts with registerProtocolHandler.

Ken: also what happens if the manifest is updated and they add another one.

Peter: I'd also like to see the icon backported into registerProtocolHandler.

Ken: the UI should mitigate against misuse of this to confuse users.

David: that might involve something like showing the origin.

Peter: related topic: the list of safe listed schemes is being managed in the HTML spec... This should be an external registry.

Dan: isn't this encompassed in the evergreen /ever blue / ever teal / whatever color we are using proposal?

David: living standards have some of the advantages of registries too.

Rossen: will summarize on the github

Tess: i wonder about the security implications of the manifest and registerProtocolHandler being out of sync...

Tess: Seems like they allow the PWA to handle https too, which is worrisome.

Dan: i left a comment and pushed to f2f

Peter: marked as pending feedback and looks like we got some...

Tess: ... kind of "the entire thing" - I'll reply.

Peter: going to waiting for feedback?

Requested an update...

Ken: I know that Diego was involved with this issue but I don't see him as part of the primary contacts. I will reach out to him and ask if he can be added.

Dan: I agree with Marcus' statement about "apart from subtle things nothing else will be different".

[discussion on whether you need this or if register protocol handler is enough?]

Rossen: would the same be applicable in app to app scenarios? More applicable example - i click on an email, my handler has outlook PWA registered. in outlook i should be able to click ...

Dan: Or example where you have email client running in a Tab.. and you want clickin on an email link to bring you to that tab and open up a compose function there... Can register protocol handler do that?

Ken: Yes.

Ken: I think it's the same... it just calls that function underneath. So that it gets registered when you install the app. That's fine - it's not something you want every site to do, but when you install something it could be a good time to ask.

Dan: so it's fine - as long as regular web apps running in other tabs for example also have access to the same functionality.

Ken: yes and that seems to be the case.

Rossen: I think that if Diego or Aaron engages it will move this along.