Skip to content
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.

namecoin integrations #41

Open
jbenet opened this issue Sep 10, 2015 · 15 comments
Open

namecoin integrations #41

jbenet opened this issue Sep 10, 2015 · 15 comments
Labels
Candidate Dev RFP

Comments

@jbenet
Copy link
Member

jbenet commented Sep 10, 2015

(in an email to ipfs-users@googlegroups.com @jbenet said:)

As for namecoin, we want to at least support namecoin
names for pointing at content in IPFS. I imagine there are
other touchpoints, but let's start there. Probably something
similar to how we do it with DNS. in DNS, we map a domain
to a "unixweb" path with a TXT record:

   # format
   TXT dnslink=<unixweb-path>

   # examples
   TXT dnslink=/ipfs/<hash>
   TXT dnslink=/ipfs/<hash>/<path>
   TXT dnslink=/ipns/<hash>
   TXT dnslink=/ipns/<hash>/<path>

(there may be other protocols). I imagine this can be trivially
done with namecoin, and we can thus could start resolving
both:

   /ipns/mydomain.bit/<path>
   /namecoin/<path>
@Gaboose
Copy link

Gaboose commented Sep 12, 2015

If things are heading towards integrating with an existing blockchain (Namecoin, Filecoin) maybe try Ethereum instead? Name registration and custom currencies are trivial apps there.

@Gaboose Gaboose mentioned this issue Sep 13, 2015
Open
@JeremyRand
Copy link

Hi, Namecoin developer here. Sorry I took so long to get back to you, things have been busy here.

Our current spec does allow TXT entries for domains, so this should work pretty easily from the blockchain point of view. The other question is how end-user applications will look this up. I'm not super familiar with how you're enabling browsing at the moment -- are you using a proxy to let standard HTTP applications access the content?

Regarding Ethereum -- I have a lot of respect for the Ethereum devs, as do the other Namecoin devs. However, Ethereum's flexibility introduces a lot of attack surface that simpler script systems like Namecoin's don't have. For complex contracts, Ethereum's complexity may be necessary (and it's quite cool for those applications). For simple things like naming, I think Namecoin is going to be more secure in the sense of having much lower attack surface. The Ethereum devs may have a different point of view.

@jbenet
Copy link
Member Author

jbenet commented Sep 26, 2015

@JeremyRand ipfs will resolve paths like /ipns/foo.com/bar/baz and /pns/foo.bit/bar/baz and /ipns/jsaifdjasifjdas.onion/bar/baz by delegating to resolvers shipped in the code. so for namecoin, we wouldnt want to have the entire blockchain along with us, so we'd probably use something like a light-client resolver.

re you using a proxy to let standard HTTP applications access the content?

That's right. Though we have a larger adoption plan:

  • HTTP proxy (both local, or global at https://ipfs.io) (easy, done)
  • IPFS in js -- node-ipfs running inside a browser tab (medium, in progress)
  • IPFS in the browser -- long term, submit patches to FF and Chrome. (hard, in progress)

Re Ethereum, yeah we'll support ethereum naming too. but namecoin too. we dont have to choose! :)

@JeremyRand
Copy link

Sounds like a good plan. Namecoin is working on SPV-based lightweight resolvers, so that should meet your requirement of not having the entire blockchain. Let me know if there's anything we can do to help. :)

@jbenet
Copy link
Member Author

jbenet commented Sep 27, 2015

@JeremyRand the roadmap i think looks like:

  • identify the best client to bundle with go-ipfs (we need the most help here).
    • (if it's in Go, better because we can use as a library)
    • it could just be a dns-to-namecoin resolver, which can work fine
  • once we select one, plan out the bundling with go-ipfs. (meat of the work)
  • adding .bit as a name system to IPNS (this is very easy given the above)

Additionally, is there a global HTTP gateway to resolve namecoin dns? something people have to trust, but can rely on for apps? If not, we'll expose one from https://ipfs.io as a convenience to apps.

@taoeffect
Copy link

(@taoeffect -- what was it you told me about?)

https://github.com/hlandau/ncdns

@JeremyRand
Copy link

Yes, if you're looking for something in Go, ncdns (by @hlandau ) is your best bet. ncdns also has a good chance of being the project officially endorsed by the Namecoin project long-term. There are three projects other than ncdns that can act as DNS to Namecoin bridges (NamecoinToBind, NMControl, and DNSChain), but those projects are not in a language that lends itself to reproducible builds, and as a result are less likely to be endorsed by the Namecoin project long-term (Tor Project uses Go partially for this reason). ncdns also tends to have better support for newer features of the Namecoin specs, in part because @hlandau is also the editor of the Namecoin specs.

I'm unaware of a public HTTP gateway for Namecoin DNS. I recognize that there is a demand for this due to the fact that we haven't released an SPV client yet, but my hope is that most users will do resolution locally once SPV clients exist. We can't stop people from doing third party trust, but it's not something that we think is healthy. If you do choose to set one up, I humbly request that you at least make it clear to end users that they're trusting the resolver, and what the implications of that are (e.g. that if the resolver is evil, or compromised, it could censor, hijack, or surveil requests).

Cheers.

@jbenet
Copy link
Member Author

jbenet commented Sep 27, 2015

@taoeffect @JeremyRand thanks so much for ptr to ncdns.

@hlandau please read up on this if you have some time and let us know if this would be interesting to help with.

@JeremyRand yeah i agree with all your points. the only reason for these gateways/trusted resolvers to exist is for strictly-worse trust models, where the application is totally hosed anyway/incapable of running third-party code/modules, or part of some bootstrap-to-adoption route, and has to do all its work over traditional HTTP. We think these use cases are important to address to ensure people have smooth adoption paths, and recourse to plug old legacy applications into new systems. Completely agreed about the "make it clear to end users that they're trusting the resolver, and what the implications of that are" (and to be fair, this is many steps better than traditional DNS as is, and some steps better than regular HTTP, particularly if the records are themselves signed. (we should make a trivial spec for that) and applications can check the sigs end-to-end.)

@JeremyRand
Copy link

FYI, ncdns can sign the records it produces with DNSSEC. The DNSSEC keys used are specific to the installation of ncdns, so users would have to trust the operator of the ncdns instance, but if you're just looking for a way to do integrity checks on the DNS records that ncdns produces (while trusting the ncdns operator), the DNSSEC signatures might be a good way to do so.

It's also theoretically possible to produce an offline SPV proof of a record existing in the Namecoin blockchain. Faking such a proof would require possessing a lot of PoW hashpower, which makes it substantially more secure. Furthermore, if a user asked multiple servers for such an SPV proof and they disagreed, the larger PoW would win (which almost always means the real blockchain would win). This isn't fully implemented in Namecoin yet, but down the road it would provide better security than just relying on a signature by the ncdns operator.

@hlandau
Copy link

hlandau commented Sep 27, 2015

The hlandau/ncdns/ncdomain package contains the core Namecoin d/ value to DNS RR array conversion code. You can use it as a library. godoc.

ncdns itself is a DNS server which serves .bit. It is designed for use with a local Unbound installation to provide .bit resolution, with Unbound handling all non-.bit resolution.

Alternatively, it supports suffix operation; e.g. if you were to obtain the domain bit.foo (or bit.somedomain.foo, etc.), ncdns will happily serve the d/ space under that (so nf.bit becomes nf.bit.foo). (This has some caveats when used directly (because HTTP vhosts, etc. won't necessarily be expecting the hostname with a suffix) meaning that in order for it to work, websites must be designed with the use of suffixes in mind. etc.)

ncdns has an optional web server which provides a web interface for looking up values. Some sort of HTTP API for obtaining either raw d/ values or DNS RRs by name should be quite possible and has been under discussion. If you only need raw d/ values, note that Namecoin core now has a REST interface for obtaining this information.

Another alternative is to use namesync, a daemon of mine based on ncdns/ncdomain which uses a patched Namecoin Core instance to live-sync all domains into a PowerDNS-compatible PostgreSQL database. This can be useful instead of ncdns in some circumstances: PowerDNS is probably a lot more performant and thus can handle higher loads, it allows the d/ space to be analysed in terms of usage trends, and you can also then use PowerDNS to dump a textual, BIND-style zone file. This file can be DNSSEC-signed if desired. The disadvantage is that this is a heavyweight solution not suitable for embedded use and it doesn't support suffix operation unless you have a specific suffix in mind.

The specification for conversion of d/ values currently lives here.

FYI, although currently the vast majority of d/ domains lack external dependencies, the specification allows delegation to nameservers, including secure delegation via DNSSEC. This allows large zones to be expressed by storing only NS and DS records in Namecoin. Thus d/ values should really be evaluated in the context of a proper recursive DNS resolver, ideally a DNSSEC-validating one.

If you have any issues with ncdns, open an issue or go to freenode #namecoin.

@llopv
Copy link

llopv commented May 25, 2017 •
edited
Loading

I have been working in this issue as a side project for the university. I didn't develop with go before, so my code is messy, but it is useful as a proof of concept. It can be found in llopv/go-ipfs@c206f41.

It uses namecoin's REST API, so you have to initialize it with a special flag:

$ ./bin/namecoind -rest

The blockchain size is about 2.72 GB and can cost several hours to be downloaded.

I registered distributed-wikipedia.bit with the following JSON:

{"ipfs": "/ipfs/QmT5NvUtoM5nWFfrQdVrFtvGfKFmG7AHE8P34isapyhCxX"}

So /ipns/distributed-wikipedia.bit becomes accessible:

captura de pantalla de 2017-05-25 22-20-34

@flyingzumwalt @Kubuxu @jbenet, do you think this could be interesting for the distributed wikipedia mirror project?

@whyrusleeping whyrusleeping mentioned this issue May 25, 2017
Closed
@flyingzumwalt
Copy link

flyingzumwalt commented May 26, 2017 •
edited
Loading

(removed my comment. It was off topic. I hadn't read this whole thread when I posted)

@llopv
Copy link

llopv commented May 29, 2017 •
edited
Loading

IPFS -> Namecoin

When it comes to an unixweb namespace for Namecoin, I agree with ipfs/kubo#3942 (comment) that /ipns/ is already over-populated. I would use /namecoin/domain.bit, /nmc/domain.bit or /bit/domain instead.

Namecoin defines many namespaces: d/ for .bit domains, id/ for identities, etc. We will use the new unixweb namespace to resolve IPFS addresess. Therefore, we are only interested in the d/ namespace, which is used for domains. Using other namespaces for domains is not encouraged anymore as it can be found here, here and here.

Other Namecoin namespaces (id/), as well as information of its blockchain is going to be able to retrieve using IPLD.

Namecoin -> IPFS

Regarding IPFS links into Namecoin's blockchain, I used "ipfs" as key and the ipfs path as the value. It is how it is used by tor, i2p and freenet according Namecoin's Domain Name Specification, and it was also present in ncdocs. Note that in the updated ncdocs documentation, Non-DNS Item Types section is not present anymore, @hlandau do you know why? Should we use a TXT record instead?

Is "ipfs" a good key for it or "dnslink" is better?

The proof of concept does not deal with .bit subdomains. According to the specification, the JSON stored in Namecoin should be something like:

{"map": {
  "en": {"ipfs": "/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco"},
  "ku": {"ipfs": "/ipfs/QmWY4KZXKTuspGSwYVDNbNLLZcmSiQ63Mdmz7eRd4KzBbb"},
  "tr": {"ipfs": "/ipfs/QmT5NvUtoM5nWFfrQdVrFtvGfKFmG7AHE8P34isapyhCxX"}
}

And finally, Namecoin blockchain is huge (a SPV light resolver is already in the way). Do you think it would be nice for IPFS to provide Namecoin lookups in the ipfs.io gateway?

@whyrusleeping
Copy link
Member

@llopv It would be really cool to have a go-ipld-nmc handler written like these: https://github.com/ipfs/go-ipld-btc https://github.com/ipfs/go-ipld-zcash https://github.com/ipfs/go-ipld-eth https://github.com/ipfs/go-ipld-git With that, you could have any ipfs node be a namecoin lightclient.

As for dns record formatting, i don't have a solid opinion. I'll let others discuss that part

@JeremyRand
Copy link

JeremyRand commented Jun 5, 2017 via email

@lidel lidel mentioned this issue Sep 16, 2018
Closed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Candidate Dev RFP
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@jbenet @taoeffect @flyingzumwalt @JeremyRand @whyrusleeping @Gaboose @hlandau @llopv