Shared stewardship of the "dweb" protocol handler #28
Option 1: Path-based URI
URI that supports Unix-like path addressing
Main problem: no Origin isolation without writing custom code in browsers.
Option 2: Origin-based URL
A single protocol handler with custom top level domains (TLD suffixes):
Main win: Origin isolation for free.
As noted in #23 we are working toward improving support for protocol-specific handlers. We proactively define
The text was updated successfully, but these errors were encountered:
@lidel From my prior conversations with dat / ssb folks I'm under impression that they don't care about dweb scheme as dat:// encompasses all of the dat and same for ssb, so it appears to me that uniting multiple protocols ipfs + ipns + ipld? is PL specific so I think you should claim it.
Another take on this: what if we reduce the surface of protocol handlers in places like web browsers by using a single protocol handler with custom top level domains (TLD suffixes)?
I'll add my 2¢ here (see this historic discussion for my idealistic background):
[The below makes some assumptions about dat & ssb being similar to IPNS in terms of their URL scheme model, definitely correct me on that if there were any misunderstandings there.]
I think your option 2 is both terribly wrong and totally unnecessary. Staying in the realm of traditional URLing we have strings of the form:
In that mental model having
Both are easily classified as different origins by browsers and the second/original version is even shorter and does not claim arbitrary TLDs and also has existing scheme/protocol handler support in browsers and many other frameworks.
The way I see this is: Leave
Firefox implemented the WHATWG's whitelist in https://bugzilla.mozilla.org/show_bug.cgi?id=1476035 so I don't think navigator.registerProtocolHandler support dweb protocols anymore.
Regarding whitelisting of dweb protocols, there has been recent progress at blink-dev and WHATWG. It is proposed that new protocols are registered as provisional URL scheme at IANA: whatwg/html#5482 (comment)
Reports on relevant repositories:
I'm not really clear what the status/plan for
I haven't gotten any feedback, so I'll go ahead and register the schemes for ipfs, ipfn, dat, ssb and dweb unless someone opposes. If you have any documentation of the protocol (e.g. spec mentioning the URI schemes), that would be helpful.
@Gozala what does web+ipfs:// or web+ssb:// give us over just ipfs:// and ssb://?
If we're doing this i'd like to consider how we can encode different SSB network keys. You can have the same identity and even message hash on different networks and we'd need a way to link to the right one.
In terms of planetary we'd really like to see ssb uri's adopted so we could support them. Right now we're using apple's extensions to redirect requests for ssb content to planetary.social/p/@identity which works but isn't an open decentralized solution.
Former is universally supported across all browsers today (See https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler).
I am not sure I fully understand this, could you give an example ?
I think that would be wonderful. However I can only speculate how long it would take to convince mainstream browsers to add new protocol schemas to the supported list.
@Gozala We're actually talking about the hyper thing in the dat community right now. So far we're thinking that we're going to be switching all the dat wording to talk about hyper:// as the new protocol stack. So dat:// is probably gonna be deprecated to the old stack.
As part of another more dat specific discussion we had a similar discussion like the one in this thread here and it was about
One "solution" is to talk about protocol handlers, but they require browser support or extensions and more than that - some rather centralized authority like browser vendors and/or IANA to even add certain protocols to a certain whitelist - which is not very p2p
This is the reason I personally think a single protocol extension to rule them all is the right way to go.
I also agree with @Alexander255 that the listed options are terrible because they do conflict with how URL's work in general. Now that certain single protocol (e.g.
I described a proposal here:
This way, the
Furthermore - at least in the
Hi dweb community. Thank you again for the feedback. For the record, as I said above the discussion for protocol-specific URL schemes (including dat/hyper) are happening there:
I'm still not sure whether the community reached a consensus regarding "dweb" but I have written a draft in any case (please check):
I think the decision on dweb will not prevent me from sending the other registrations first. However, I'd like to send patches to the HTML spec and web-platform-tests/chromium/mozilla adding all the new safelisted schemes in one go so I'd still appreciate to know soon whether you are really interested in "dweb".
Regarding registering a generic prefix like "dweb+" (or "hyper+"), I haven't seen anything like this mentioned in IANA's documentation, so I don't known whether they would allow such a generic registration. Similarly, none of the existing safelisted schemes in the HTML specification (or browser implementations) are based on a generic prefix, so that would be something new for WHATWG/browser reviewers. Of course I'm not saying we can't propose/try it, just that it might be harder to convince people that extending current schemes...
The HTML specification provides a generic "web+" prefix but corresponding schemes are not registered at IANA. They are designed to provide generic protocol names for users and there is no guarantee someone else won't use them and so that URI conflicts happen.
@fred-wang: Just to make sure: Is IPFN vs IPNS in your comments just a typo? I've never about the former except in your comments and it's not mentioned anywhere else either. You even posted a different proposal yourself in another thread.
Regarding the dweb:-scheme: How problematic is it if the scheme is provisionally registered with IANA and later it turns out it won't be used? Does IANA mind if there is no solid spec on it yet? Does WHATWG mind safelisting a “fuzzy” scheme like that?
Yes, sorry about that. I edited my comments to avoid future confusions.
Just to be sure: I understand dweb is already used, right? Otherwise it does not make sense to submit it yet. IANA has a "historical" list for "not used anymore" schemes, so I don't think it's a problem to stop using it in the future: https://tools.ietf.org/html/rfc7595#section-5
From https://tools.ietf.org/html/rfc7595#section-7.4 : "A scheme specification is only required for 'permanent' registration." ; so I think it's not a problem.
(In https://tools.ietf.org/html/rfc7595#section-4 they say "If no permanent, citable specification for the scheme definition is included, credible reasons for not providing it SHOULD be given." but this section does not seem up-to-date with respect to 7.4 e.g. they mention "security considerations" while 7.4 say that now "the answers instead belong in the scheme specification". )
Good question. From whatwg/html#5482 (comment) it seems having a doc somewhere is the only requirement ; in other threads some people were even arguing about switching from a safelist to a blacklist (this means allowing dweb and all other schemes not reserved by browsers).
I can either submit it or postpone that. I guess if "dweb" is already used it makes sense to try, even if the spec is not solid yet.
BTW, this is from the IANA doc, it seems rejection is very unlikely:
Upon receipt of a scheme registration request, the following steps
Yes, we are not very vocal about it, but support it in production:
I think it is enough to argue provisional registration.
I sent 7 registrations to IANA yesterday and they have been accepted without any further requests on their side.
IIUC, there isn't a clear consensus regarding dweb as a shared protocol for distributed web, but it's already used and the community doesn't oppose to try to register it. So I believe I should just go ahead and do it?
I updated a bit https://github.com/fred-wang/iana-uri-schemes-provisional-registration-requests/blob/master/dweb.txt ; it references https://docs-beta.ipfs.io/how-to/address-ipfs-on-web/#shared-dweb-namespace which says this is still an experiment and redirect to this github issue. Not sure it is a very solid reference, but I don't think there is anything better for now...