Replies: 17 comments 43 replies
-
|
Could this be done in a peer based way? Namespaces are usually a point of centralization... And if you don't use a centralized authority managing it, you tend to get all kinds of shenanigans like hogging. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah we're working on a domain-name solution that we like better than the old method. We have two basic ideas that we're debating...
Both of these would be Hyperdrives that maintain The directories would probably work like This is a tough call. Directories centralize much less control since they enable people to configure as many as they like, but they don't work like domains. Domain-listings can work the way domains have previously worked, where I'd be |
Beta Was this translation helpful? Give feedback.
-
|
Update on this-- Maf is currently working on something called HyperDomains or HDNS (Hyper Domain Name System). He's designing it as a Hypertrie structure (not a Hyperdrive). He's investigating whether it'll be possible to store the entries in an encrypted form so that you can't enumerate them, but that's in development. Using a Hypertrie will give it some interesting properties. First, it's peer-to-peer like everything else in the Hyper* stack, so you can fetch the data from the swarm and leverage local caches. Second, you can optimistically sync the dataset before doing lookups, so it should be possible to get private lookups by downloading more entries than you need. The registry won't be a blockchain; it will be centrally managed. We're going to make it possible to reconfigure which registry you use so that "forking" is possible, as is layering-in custom/private domain namespaces. Obviously social consensus around names is a tricky topic so "forking the registry" is a complex thing to do, but I think it's important that kind of action is possible. We're planning to stay compatible with the ICANN domain namespace. To do that, we'll allocate at least one TLD for ourselves (probably For other pre-existing TLDs, we're thinking we can come up with a staged process for integrating them into HDNS. At first, we'd run HyperDomain tries for the existing TLDs and use some kind of process for registering HyperDomain entries under DNS names you own. That might be something like setting a TXT DNS record under One other thing, though this is still being debated: I'd really like to have an HDNS TLD which is free to register. We'd have to figure out some novel rules for dealing with squatting and the like, but since we expect everybody to be able to create new Hyper* sites for free, I feel like there should be a domain-name space which is also free. (Similar to how everyone expects to publish to NPM under any name without paying.) I'd really prefer that it be a TLD and not a subdomain. At any rate, I'm looking forward to my |
Beta Was this translation helpful? Give feedback.
-
|
Why not on a blockchain (or append-only log)? You could make an entry to 'this is my public key', 'this is the domain I'm reserving', 'this is the period I'm reserving it for' (periods capped at say 2mo, renewals can go to 6mo, then 1y, then 3y). Later on 'this is the domain', 'this is the new public key', 'this is my signature of moving the domain'. Afterwards, 'I'm pointing domain to there', 'this is my signature', with possible overrides. The only problem I see is spam (reserving every domain). You can't really rate-limit an user, other than making it computationally expensive (the bar needs to be raised, and what about mobile devices). I can suspect some logic with 'max 3 domains pointed at resource', but the resources (hyperdirves, users, identities) can be generated rapidly as well. The spam problem for users should be addressed anyway. |
Beta Was this translation helpful? Give feedback.
-
|
Is there any plans for how existing websites can redirect to a Hyperdrive, though? Say I already rent |
Beta Was this translation helpful? Give feedback.
-
|
We can consider this. Folks: give a thumbs up on my reply here if this interests you. Give a thumbs up to my other reply for the hyper* native approach. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm. It cannot be both? |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I think that's a possibility |
Beta Was this translation helpful? Give feedback.
-
|
I like this as a progressive enhancement on top of the existing web. Where you can move from that onto the Hyper-web without having to knowingly make the move. Kind of like how one were upgraded from http to https or http 1 to http 2 |
Beta Was this translation helpful? Give feedback.
-
|
IIRC I saw a demo using a well-known path on a webserver to jump from |
Beta Was this translation helpful? Give feedback.
-
That’s one of the things dat-dns did. |
Beta Was this translation helpful? Give feedback.
-
|
I'm looking at a scheme for creating |
Beta Was this translation helpful? Give feedback.
-
|
@pfrazee Why do you consider it a hack? I felt it was a very good use of the |
Beta Was this translation helpful? Give feedback.
-
|
@voxpelli Both of the dat-dns solutions are a little icky. Using DNS TXT records is fine but I dislike using TXT instead of having a real record type. The The main thing that |
Beta Was this translation helpful? Give feedback.
-
|
@pfrazee One good thing with |
Beta Was this translation helpful? Give feedback.
-
|
I'm more and more of the opinion that legacy DNS is irreparable broken, and that I wouldn't mind if it's merely a second-class citizen in any future Beaker setup. I understand that people want to maintain a link with their if ('beaker' in window) {
var redirect = new URL(window.location)
redirect.protocol = 'hyper:'
window.location = redirect
} |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
I think this is a possibility (hyper:// would basically not use ICANN DNS) but I don't think it's our only option. I'm looking at a scheme for creating hyper:// domain entries using HyperDomains rather than the legacy dat-dns hack. I'll describe it in another comment/answer (ctrl+f for HyperDomains). |
Beta Was this translation helpful? Give feedback.
-
|
You shouldn't need to execute javascript to be able to jump from one web to another |
Beta Was this translation helpful? Give feedback.
-
|
That's why I called it a "second class citizen". Also, this discussion has moved on from this. |
Beta Was this translation helpful? Give feedback.
-
Any particular reasons? It can be a bit difficult to mange because it doesn’t follow zeroconf auto-discover contentions. But it’s not fundamentally broken.
This will hurt performance. DNS lookups are significantly faster than DNS+TLS+HTTP+HTML+JSexec. |
Beta Was this translation helpful? Give feedback.
-
Sorry, I problably wasn't 100% clear on this. I was refering to the current DNS system as a whole, not So for me the
Right, that's what I meant by "second class citizen". Personally, I'm okay with that trade-off. There's also a slight more performant alternative that requires a bit more work. Beaker currently adds @pfrazee Maybe it would be good to future-proof this by adding something like |
Beta Was this translation helpful? Give feedback.
-
|
@brechtcs I'm open to something like that. Is the User Agent the best one to do it? Could also consider a different header, like |
Beta Was this translation helpful? Give feedback.
-
|
I like the idea of using an "Upgrade" header, because it's true :) I don't know the spec that well though, can you just assign it an arbitrary value? If not some servers might return an error when encountering an "Upgrade: hyperdrive" (or whatever value you settle on). But I guess it doesn't really matter whether it's implemented with a header or the user-agent string, both should be quite straightforward to use in an existing HTTP server. Using Nginx for example: server {
listen 80;
server_name example.com;
if ($http_upgrade = Hyperdrive) {
return 301 hyper://<key>
}
# remaining Http config as normal
}Would something like this be acceptable for your use case @da2x? |
Beta Was this translation helpful? Give feedback.
-
|
(I’ve already written and submitted this reply but I can’t find it in the thread. Sorry if you guys see it duplicated.)
The Tor browser uses this to auto-discover .onion addresses on .tld sites and side-grade future requests to the current origin over to the .onion side. So the first page-load happens over HTTPS (everything is already set in motion and the request is being fulfilled.) Future requests are sent to the alternate service instead, though. From the user-perspective in the Tor implementation, they see https://example.com even though its served from hashhash.onion. The spec requires the alternate service to have the same HTTPS certificate as the original origin. So the .onion service must have a certificate for example.com. We can mitigate that requirement by redirecting from https:// to hyper://. Changing the origin protocol changes the origin so security is maintained. The auto-discovery happens over a HTTPS connection that is domain-verified by the origin’s certificate. It should be as secure as HTTPS without any MITM vectors. |
Beta Was this translation helpful? Give feedback.
-
|
There are a number of considerations. Namespaces are a scarce resource and create demand. They are difficult to administer (think visa.p2p). I would ask to possibly rethink this approach. For me, domain namespacing (dot notation) was always a failure of DNS, ever since inception. DNS failed as content discovery and led to Google and Yahoo! There were many indexing approaches before the oligopolies took over, content discovery was once a flourishing industry of innovation and exploration (webrings anyone!), now it is owned by a select few entities that filter our discovery and ultimately our lives. The dot notation system is not a natural language. It is a systematic approach to a directory based seek/find problem across a network. Domains used to be physically separated by walls and buildings. People don't use dot notation to search (well they kinda did search for shoes.com once upon a time, but direct navigation was killed by Google's omnibox). People certainly don't think that anyone 'owns' a keyword. With hyperdrive, we have a better system now, we have the chance to re-imagine federated search, we can do much better! I would look at combinations of tags as search terms so rather than:
I would consider using an alphanumeric string, using a so:
or
These terms would defined by the owner of the hyperdrive and could change over time. For example, if you were building a cool app you would call it
But let's say your cool app, was not getting discovered, as it was really a todo app with the wrong name, you could change the tags to:
The key thing to notice here is that the namespace is local and not unique, clashes are expected. Indexing then becomes a trivial local task and you can index based on your own parameters: e.g. how many hops away are the hyperdrives? 1 level, 2 levels, 3 levels deep? A search results page could be crafted to a template and off you go. Tags as I am proposing are similarly implemented in SSB as Nick Names https://handbook.scuttlebutt.nz/concepts/identity Spam becomes a local problem and you can filter based on what you know, what you want. Global hyperdrives are a matter of personal discovery and recommendation. It is still a name system but not a domain name system. You can control the filters. |
Beta Was this translation helpful? Give feedback.
-
|
I should say that then that typing bare words like
into the search bar could resolve to
Which could in turn result in a set of results, based on your own search criteria (i.e. proximity)
a direct hit to a hyperdrive would still be
|
Beta Was this translation helpful? Give feedback.
-
|
@paulharwood A lot of what you're describing is a distributed search system, which I also think is vital but solves a slightly different set of needs. I feel like what we can do is both -- domain names and search -- and then leave users free to not use domain names if it's not their jam. |
Beta Was this translation helpful? Give feedback.
-
|
Reading the comments below, this discussion has probably already leaked into a bigger domain of expertise and lost focus :) Yes, you're right, the decision is up to the user ultimately, choice is good. But I'd ask you to consider the paradigm of search over resource descriptors, which only exists in our collective cognitive behaviour set because existing naming systems are so bad at describing resources. I like the way that SSB/Patchwork allow community based naming, which is not search, but could extend into search.
We all have the mental model of domains scorched into our foreheads by commercial branding and day to day usage i.e. "amazon*.com*" rather than "amazon". Which is why I accept your point around letting users decide. But even the GTLD space is making that a nonsense now (companyname.blackfriday = $299 a year) and charging a hell of a lot of money for the privilege. I completely accept that DNS pinning a service is useful, and that this is probably for another discussion, but my point is: What is more important to describe using a naming system, the hyperdrive contents or the service behind it? [edit: punctuation] |
Beta Was this translation helpful? Give feedback.
-
|
At peril of perhaps jeopardizing the name security aspect of Zooko's triangle, I really like the idea of scoped namespace registration. For example, when navigating to
That way, website operators could ensure that all known links within their hyperdrive always point to the right address. Links created dynamically may still be subject to misresolution. Beaker could currate and provide a built-in name registry that would be a suitable starting point for most users. More advanced users could supplement or even replace that registry. |
Beta Was this translation helpful? Give feedback.
-
|
What's missing from the directory based solution like you describe is an answer for key-rotation. If (as in your example) Key rotation is a really important property for a system like Hypercore because users have to maintain their own private keys, and we need to expect those to get lost or corrupted. |
Beta Was this translation helpful? Give feedback.
-
This is something I've been thinking about a bit lately too. I wonder if it might in fact be too important to outsource it to an external solution like DNS or HyperDomains. Could there be a way to address this in |
Beta Was this translation helpful? Give feedback.
-
|
@brechtcs I don't know how that could be done without requiring users to maintain some kind of master private key, which I don't think is a great solution. I'm going to reply to another comment of yours with an in-depth explanation for why I do see HDNS as strong. |
Beta Was this translation helpful? Give feedback.
-
|
I do feel like making users maintain a master private key is workable. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with the master private key, as long as backups/recovery methods are built in. You can do Shamir Secret Share with the bip39 mnemonic and give the shares to three hyper-friends as a backup backup. |
Beta Was this translation helpful? Give feedback.
-
|
I change the topic to narrow the scope a bit. There’s a lot of interesting ideas but little is about the original topic. The top post is about mapping ICANN DNS to Hyperdrives. This is a feature that exists in Dat to facilitate seamless migration from a HTTPS website to a P2P equivalent of that same website. I believe it’s important to drive adoption among existing web-enthusiasts who’ve invested in their existing domains. Plus, you know, hashes aren’t meant for humans. DNS domains are. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, scope is important. But it is an opportunity to highlight the issue of using authoritative naming systems to interface with peer based, distributed filesystems. |
Beta Was this translation helpful? Give feedback.
-
No argument there.
But I'm not sure I agree with this. The large majority of non-technical user rarely use domain names for navigation. From my observations, the most common usage is a bit as follows:
Steps 1 and 2 already work perfectly on Beaker without any need for domain names. Step 3 will hopefully be solved in userland sometime soon, and doesn't require DNS support either. |
Beta Was this translation helpful? Give feedback.
-
|
@brechtcs I agree that distributed search is important because it does provide a fully decentralized answer to lookup (and is often a good UX). I don't agree that domains are not user-friendly; it's true many people use search, but I think domain names have had a lot of good utility. I also think it's important to reiterate, you won't have to use domain names if you don't want to. I do think HDNS is a notable improvement to existing DNS. Here's why:
Regarding centralization of the registry management, I think there are a couple of ways we can help that situation. The first thing we can do is making the TLD registries configurable. I see that as a similar solution to forking in FOSS: it gives users a way to overthrow the current leaders if needed. The second thing we can do is make it possible to override individual entries, or perhaps even layer multiple registries under a TLD. That way users can make non-global or personal name mappings. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, domains are useful to describe the location of a resource, but are bad at describing a service. e.g. take Personally, i'd love to see the typing of
[edit: missing slashes, removed conjecture] |
Beta Was this translation helpful? Give feedback.
-
|
I second that.
The choices you make most often will show up more towards the top over time.
Of course - if it really doesn't work, you might try different kinds of searches or use
Lastly, if you want to share a link and express your opinion or the opinion about the name of a hyper address you got from somebody else giving you that link - like even your autocomplete search bar could recommend you and offer you copy/paste, so that you would essentially pass on something like:
If another user was opening that link, their local browser would already know |
Beta Was this translation helpful? Give feedback.
-
|
Example: The Tor browser uses this header to auto-discover and serve traffic from a .onion address on a .TLD. The browser still shows example.com even though future requests are loaded over example.onion. However, this header could be used to redirect from https to hyper. The HTTPS server sends this header over HTTPS so there's is some built in security. The spec requires the Alt-Svc target to be served from a server with s certificate for the primary origin. Redirecting to a different protocol mitigates the underlaying requirements for this, however. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, this looks like a fantastic option. Maybe this is the opportunity to define the schema and pin the services together in a compatible way?
Resolves to/instead of:
|
Beta Was this translation helpful? Give feedback.
-
|
Test. (My replies to this thread keeps disappearing.) |
Beta Was this translation helpful? Give feedback.
-
|
Mine too |
Beta Was this translation helpful? Give feedback.
-
|
This is so weird. I get emails about new updates to this thread but I can’t see anything on GitHub. Maybe we need a Hyperdrive-powered gossip discussion board sooner rather than later. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, very interesting stuff here. Being a search guy here's my specific take on it. I'm not sure i know wtf i am talking about. But i am assuming there is some central 'swarm file' that maps a hyperdrive key to an IP address:
so it's some sort of "decentralized democractic dns" quite similar to a lot of the other decrentralized approaches. |
Beta Was this translation helpful? Give feedback.
-
|
*and people can downvote certain IPs and hyperdrives too, to help combat spam and spammy voters. |
Beta Was this translation helpful? Give feedback.
-
|
*additionally, voters could also supply keywords as to what they think best represent the hyperdrive they are voting on. and these keywords would be searched as if they were part of the title of the hyperdrive being voted on. |
Beta Was this translation helpful? Give feedback.
-
|
*lastly, you could restrict voters to a group of voters you trust. this would be similar to ICANN if ICANN consisted of a bunch of voters. that would make things even more immune to spam. like, several groups of people/voters would emerge as trustworthy, but perhaps differ in political views. and you could pick one to use when doing your searches. |
Beta Was this translation helpful? Give feedback.
-
|
it seems you already have a list of hyperdrives on a single page from your list.json file. this can be the dns lookup for now. :) |
Beta Was this translation helpful? Give feedback.
-
|
For what it's worth, I'm still supporting dat-dns inside Agregore and it's working great for my blog: hyper://blog.mauve.moe I've also got it seamlessly working with dat-store where I have it keeping a backup of my archive and serving as an HTTP gateway for any archives I store there. Then I use NGINX for setting up letsencrypt certificates and have it redirecting to the gateway URL. |
Beta Was this translation helpful? Give feedback.
-
|
Has there been any updates for something like this? |
Beta Was this translation helpful? Give feedback.
-
|
I think we're going to stick with the dat-dns solution for now (though we should talk about whether the DNS TXT record should change per some issues raised). As much as we like the hyper-dns idea, there's a complex social issue around appointing central-writer authority which has to be resolved: creating a market of registrars. ICANN solves that issue by artificially creating one -- they act as the coordinating point between accredited registrars but don't accept registrations themselves. Unless we did the same, or used a completely ownerless market (ya know, blockchains) then we'd be setting a bad precedent for the market by running the sole registrar. So, unless & until we can solve that, we're going to piggyback off existing DNS. |
Beta Was this translation helpful? Give feedback.
-
|
Something about DNS that I felt was an issue with the Dat versions of Beaker Browser, was that a Dat loaded via its key and that same Dat loaded via a domain name would be treated as two different origins. I've always thought DNS should just act as a mask for the regular Dat URL. Could that be applied to hyper:// or is there something valid that I'm missing? (security concerns maybe?) |
Beta Was this translation helpful? Give feedback.
-
|
I think the main issue there is that Electron doesn't provide a way for us to specify the origin to be something other than what's in the URL. In the past I considered redirecting to the public key version when you access the DNS version, but that can be a problem too because sometimes you'd want the flexibility of being able to change what the DNS points to. |
Beta Was this translation helpful? Give feedback.
-
|
I was thinking not even using Electron's own features for this and instead just having the address bar display the domain name while the webview loads the public key as normal. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that's a good idea for top level navigation. I wonder if it'd matter for when you have iframes or other resources linked to from within the page. 🤔 |
Beta Was this translation helpful? Give feedback.
-
Any plans to add
hyper://<dns>akin todat://<dns>? I noticed that the Beaker homepage, Hypercore Protocol’s homepage, and documentation isn’t available as Hyperdrives.hyper://e36050c2651b2bd0bd265fc311c122122a5490bc11a17606201964246b69e4ef/is nice and all but as a human, I prefer typingblog.hypercore-protocol.org.Beta Was this translation helpful? Give feedback.
All reactions