propose: fast lane ipns #66
Conversation
|
|
||
| Diagram illustrates a name resolution flow. Note however that it does not show how name router can discover new names and their keepers from pubsub. | ||
|
|
||
| <!-- |
| Diagram illustrating how name update flow. | ||
|
|
||
| <-- | ||
| ```flow |
|
|
||
| <-- | ||
|
|
||
| ```flow |
There was a problem hiding this comment.
I'm not sure where a.com is coming from.
There was a problem hiding this comment.
I'm not sure where a.com is coming from.
As per test above this "Diagram illustrates name resolution through DNSLink", so it is an example when peer is trying to resolve /ipns/a.com/. @Stebalien does this make sense, otherwise could you please clarify a bit what you mean ?
| > - ❌ DHT implementation in nodejs is buggy, untersted and unoptimized ([ipfs/js-ipfs#3469][]). | ||
| > - ⚠️ PubSub in web nodes only works in swarms formed around central ICE server that are disjoint from go nodes. In practice creating fragmented networks of ephemeral peers. | ||
| > - ⚠️ IPNS over pubsub is disabled in go by default (Can be enabled by running daemon with `--enable-namesys-pubsub`). Pubusb itself is also disabled by default ([protocol/web3-dev-team#53][]). | ||
| > - ⚠️ IPNS over pubsub in nodejs still requires DHT to bootstrap overlay network of participating peers. Lack of proper DHT implementation prevents it. Which could be overcome via delegated routing but it does not work out of the box. |
There was a problem hiding this comment.
This can be any router, including the Rendezvous. Ideally what I would like to see was nodes to advertise that they are interested in a given topic in all the means they can DHT/Delegate/Rendezvous/... and then other more limited peers can rely on what suits them better.
I would rephrase the DHT to content/peer routing. I proposed some time ago the Discovery API, which would be a simple abstraction that would forward advertises/findPeers to the available routers. Go also has a discovery API concept similar
There was a problem hiding this comment.
That sounds reasonable and possibly worth adding to considered alternatives section. Here I describe current state of things and to my knowledge it does so accurately, isn't it ?
| 3. Name routers can deny service to peers resolving name too frequently. | ||
| 4. Name routers are not involved in publishing. | ||
|
|
||
| It is assumed that name routers will be infrastructure nodes, implying that they can be dialed from limited nodes like browsers _*(Have SSL certificates setup, or have a WebRTC address)*_ and can leverage DHT and PubSub so thay they: |
There was a problem hiding this comment.
Wondering if we can reuse rendezvous servers for the exact same purpose?
A rendezvous server is a libp2p node with a database that keeps all the multiaddrs registered for a given namespace. It receives registration requests and discovery requests.
There was a problem hiding this comment.
Another possible link here if they would be a different piece of infrastructure would be for the name routers to advertise their role via rendezvous + DHT, so that other peers could easily find such nodes in the network
There was a problem hiding this comment.
I think rendezvous nodes could be a perfect fit here, I just did not wanted to tie the proposal to any specific not yet available (as in deployed) solution so it is possible to iterate on this without been blocked on other pieces.
|
|
||
| Only DHT based implementation in go works out of the box. But it still fails to meet user expectations because: | ||
| 1. *Slow* publish and resolution. | ||
| 2. Requires continues republishing. (see [ipfs/go-ipfs#4435]) |
There was a problem hiding this comment.
Conversation with @aschmahmann left me with an impression that pubsub is less problematic as peers query network and anyone can respond with a record, which in practice happens to be a lot more effective.
@Stebalien Anything I should change about above statements or was that just a side note ?
There was a problem hiding this comment.
It's less problematic as long as someone who resolved the record is still around and still subscribed to the record's pubsub channel. So, for popular records yes.
But for unpopular records, no, you'll need to be online and/or republish regardless.
|
|
||
| ###### DNSLink Optimization | ||
|
|
||
| Name owners could include addresses to chosen name keepers in the [DNSLink][] record, which would enable name resolution without resolving an address through name routers first. |
There was a problem hiding this comment.
How would this interact with IPNS? IPNS doesn't use DNSLink.
There was a problem hiding this comment.
This is just DNSLink optimization, that would allow you to avoid querying routing nodes described in a previous section. When you resolve IPNS name you'd either already have name keeper address or you query routing nodes to obtain one and cache it forever.
There was a problem hiding this comment.
IPNS and DNSLink aren't really related. For DNSLink, you just query your local DNS resolver which is almost always very fast.
There was a problem hiding this comment.
Oh I think I know what the misunderstand is here. Today most DNSLink records are /ipfs/... while expectation with this done is that they will turn into /ipns/... and will not require DNS provider specific APIs to do updates.
Does this makes more sense ?
There was a problem hiding this comment.
That's the first I've heard of that. What's the motivation?
There was a problem hiding this comment.
That's the first I've heard of that. What's the motivation?
"What does success look like?" section calls out specifically related goals as success metric. That said motivation specifically is:
- Browser nodes can not update name (unless....)
- Not all DNS providers provide programatic API to do record updates. And ones that do have their own custom API so there is no general interface to publishing updates.
- Usually updating DNS record involves separate authentication, creating yet another hurdle for doing it especially in browsers but also beyond.
- We could have subscribe style interface for realtime stuff if domain name is just a human readable alias to
/ipns/..., which seems unrealistic otherwise.
If I'm not mistaken originally #42 covered a lot of this before it rescoped.
|
|
||
| <-- | ||
|
|
||
| ```flow |
There was a problem hiding this comment.
I'm not sure where a.com is coming from.
|
|
||
| At the high level this proposal promises an efficienecy of centralized publishing and resolution while retaining resilience of distributed system. | ||
|
|
||
| Proposed name resolution system is inspired by Domain Name System (DNS) as it introduces athoritative name resolvers _(from now on referred as)_ **name keeper** nodes. But unlike DNS, **name owners** _(private key holders)_ are in charge of choosing a name keepers and retain ability to change a name keeper in the future. |
There was a problem hiding this comment.
How does this actually work? We could add a set of "keepers" to the IPNS record itself, I guess (as long as it's under a signature). I assume that's what you mean, right?
There was a problem hiding this comment.
I think I go into much greater detail below, but general idea is that instead of having to route on every name resolution, we'd do it very infrequently because there will be specific authoritative node you can ask about current record. That way nodes will be able to resolve "name keeper" address once and cache for future name resolutions.
Hypothesis is that while name keeper can change, it will be infrequent enough that we can see huge gains.
There was a problem hiding this comment.
Ah, sorry, my question is: how are you specifying these "name keepers"? Where does the list live, how is it published, how is it authenticated, how do I revoke keepers, etc.
There was a problem hiding this comment.
I think you may have meant how name owners choose name keepers. I don't have thought through the specific here, but general idea is that name owner would provide a name keeper with a signed certificate, which it can use to prove to routing nodes that it is indeed the name keeping authority.
That said I'm pretty open to discussing / reconsidering many details of this proposal, mostly I'm pitching a bigger picture, that is lets make name publishing fast point to point operation. And make name resolution as close to that as possible.
There was a problem hiding this comment.
Got it. My thinking is that the keepers should be added as additional fields to the IPNS records. That way, there's no way to "roll back".
There was a problem hiding this comment.
how are you specifying these "name keepers"?
- You can create DNSLink record with
/ipns/${key}and multiaddrs to name keeper. - You issue a certificate to a name keeper authorizing them as a name keeper. Which they use to let routing nodes know & proof they are the authority for the name. General assumption here is that pinning services will assume "name keeper" role as they are always on, well connected and you tell them what to pin anyway.
Where does the list live
"Initial resolution optimization" attempts to describe it at high level. It assumes that infrastructure nodes can keep a list of "name keepers" and respond to queries from the network. If the name is unknown they can fallback to regular resolution DHT/PubSub and then cache the record forever. Note that here they resolve a "name keeper" not an actual record, and because those likely to change rarely no significant load is expected since there multiple layers of long term caching.
how is it published, how is it authenticated
Name keepers are in charge of publishing to DHT, and over pubsub (possibly rendezvous) announcing themselves as "name keeper" for a name. Again since name keepers are unlikely to change TTLs could be very high.
how do I revoke keepers, etc.
Again have not thought through all the details, but broadly speaking "name owner" would issue new certificate overriding old one to a different "name owner", which will than be responsible for updating the network. I expect pubsub would be an effective way to let routing routing nodes about the name keeper change. That said I'm open to alternative here as well.
There was a problem hiding this comment.
I realize I'm pretty vague when I talk about certificates, that is because I intentionally have not spend time thinking through all the details until this gets some traction. That said I think UCANs are providing a pretty good and generalized model.
Co-authored-by: Vasco Santos <[email protected]>
|
Closing this as it is not on our immediate roadmap. We will reopen when this work intersects with our future timelines and priorities. |
No description provided.