-
Notifications
You must be signed in to change notification settings - Fork 544
Request: Namecoin Support #260
Comments
I'll definitely give it some thought. The plan is currently to create a "shared petname" system called the app scheme. I want to explore that before a blockchain-based DNS replacement. |
Hi. I don't see them as mutually exclusive features. Actually, they seem complementary to me: if you are using the "xyz" scheme, a namecoin lookup for a |
Yes, I do agree. The question is simply whether to incur the complexity cost! Beaker is a one-man operation so far, so I have to pick my workloads carefully.
I do appreciate the offer, quite a lot! If you'd like to fork and try it out, I think that'd be great, but I can't guarantee I'll merge. RE: your dat woes, yeah that's a big pain. I'm working on a public peer service, which will solve that, and should be up soon. (Join the mailing list if you want to make sure you get the announcement.) |
Either way, I'm not pressuring.
That code would reside in the browser? Why not directly in the dat protocol stack? I'm not familiar enough with dat, but shouldn't a list of bootraping peers/trackers also be available to the dat cli as well? That being said, a beaker-only solution, is much better than nothing… |
Public Peers are basically bots that you can ask to rehost archives for you. The reason it's not baked into the protocol is, there's no automated system for asking a peer to host things for you. For that, we need a service. |
That makes sense, but how about some kind of peer exchange (pex) command that would be built in all dat peers where a peer can be asked for a list of known peers (and not just a list of hosted content)? Maybe I should be having this discussion on the dat project itself. Let me know if it is the case. |
Hi, Namecoin developer here. We'd be happy to assist on Namecoin support in Beaker as our free time permits. FYI, we're planning to release Chromium integration soon-ish, but the witchcraft we needed to resort to in order to get Namecoin TLS working properly in Chromium was rather unfortunate (and currently only works in Windows). It'd be quite awesome if Beaker might be interested in supporting Namecoin TLS cert validation in a way that doesn't require multiple layers of witchcraft. I wouldn't really be in favor of a centralized+trusted relay to the Namecoin blockchain, but we recently released (in beta) an SPV name lookup client (based on BitcoinJ) that takes circa 10 minutes for initial syncup (or circa 5 minutes if a semi-trusted API server is used). Cheers! |
Closing for now, we'll keep this as a consideration |
Hi,
I'm submitting this issue to explore the idea of Namecoin domain name resolution in the Beaker browser.
In a .bit namecoin domain name, there could be a value like this:
dat:"DAT_SITE_KEY_HERE"
And the user could enter the .bit domain name directly in the address bar of the Beaker browser to have it resolved automatically and transparently.
This could require the centralized "generation" of a static domain name registry that would be trusted (but configurable) in the Beaker browser to avoid having each user run and maintain his own local blockchain and namecoind service.
What are your thoughts on that?
The text was updated successfully, but these errors were encountered: