Skip to content
This repository has been archived by the owner on Dec 27, 2022. It is now read-only.

Request: Namecoin Support #260

Closed
up4 opened this issue Jan 18, 2017 · 8 comments
Closed

Request: Namecoin Support #260

up4 opened this issue Jan 18, 2017 · 8 comments
Labels
feature request Suggested change that's under consideration but not yet on the roadmap

Comments

@up4
Copy link

up4 commented Jan 18, 2017

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?

@pfrazee pfrazee added the feature request Suggested change that's under consideration but not yet on the roadmap label Jan 18, 2017
@pfrazee
Copy link
Member

pfrazee commented Jan 18, 2017

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.

@up4
Copy link
Author

up4 commented Jan 18, 2017

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 xyz://abc.bit address would then try to resolve a "xyz" value in the "abc.bit" domain (instead of a "dat" value). I would love to offer a fork/pull request for Namecoin support, alas, dat seems to hate my network topology (double nat) so I will have to have a double-nat-friendly dat first...

@pfrazee
Copy link
Member

pfrazee commented Jan 18, 2017

I don't see them as mutually exclusive features.

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 would love to offer a fork/pull request for Namecoin support

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.)

@up4
Copy link
Author

up4 commented Jan 18, 2017

Beaker is a one-man operation so far, so I have to pick my workloads carefully. […] I can't guarantee I'll merge.

Either way, I'm not pressuring.

I'm working on a public peer service, which will solve that, and should be up soon.

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…

@pfrazee
Copy link
Member

pfrazee commented Jan 18, 2017

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?

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.

@up4
Copy link
Author

up4 commented Jan 18, 2017

The reason it's not baked into the protocol is, there's no automated system for asking a peer to host things for you.

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.

@JeremyRand
Copy link

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!

@pfrazee
Copy link
Member

pfrazee commented Apr 19, 2017

Closing for now, we'll keep this as a consideration

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature request Suggested change that's under consideration but not yet on the roadmap
Projects
None yet
Development

No branches or pull requests

3 participants