NameCoin as an I2P name service
Posted: Thu Sep 08, 2011 5:51 pm
I2P lacks advanced DNS support from the beginning. There are addressbooks. There is a private addressbook for every user and there are public addressbooks that are being consulted by other users. Different users might use different set of public addressbooks. For example, inr.i2p is rather popular (i2p.to gateway respects inr.i2p entries), but it's not enabled by default. Every I2P user has its own view of I2P web. It is not guaranteed that everybody will be able to follow any particular i2p link (except for .b32.i2p links). Address-helpers also help find i2p destination, but it is possible to inject another i2p destination into private addressbook this way. I2P is in ancient ages fully utilizing hosts.txt
Another problem is non-eepsite services. For instance, there is no way to specify MX entries. There are also no hosts and no ports in I2P. There are anonymous destinations. hosts.txt doesn't specify hosts. It lists name-to-destination mapping. We can't launch another service on another port because any particular i2p name refers to just one destination, so they are mostly eepsites. In fact, there is just 1 mailserver (mail.i2p), and there is no way to launch another one linked to mail.i2p. Well, we can agree to refer to smtp._tcp.mail.i2p to find @mail.i2p's I2P SMTP server, but a problem still remains. With regards to email and xmpp, unsynchronized view of I2P namespace is not acceptable. Centralized view isn't highly desired as well.
NameCoin feels like a breath of fresh air. I2P users are potential NameCoin users. NameCoin records are in JSON and it seems that one can put I2P destinations instead of IP addresses into DNS zone records.
http://forum.i2p/viewtopic.php?p=35652
http://forum.i2p2.de/viewtopic.php?p=35652
Another problem is non-eepsite services. For instance, there is no way to specify MX entries. There are also no hosts and no ports in I2P. There are anonymous destinations. hosts.txt doesn't specify hosts. It lists name-to-destination mapping. We can't launch another service on another port because any particular i2p name refers to just one destination, so they are mostly eepsites. In fact, there is just 1 mailserver (mail.i2p), and there is no way to launch another one linked to mail.i2p. Well, we can agree to refer to smtp._tcp.mail.i2p to find @mail.i2p's I2P SMTP server, but a problem still remains. With regards to email and xmpp, unsynchronized view of I2P namespace is not acceptable. Centralized view isn't highly desired as well.
NameCoin feels like a breath of fresh air. I2P users are potential NameCoin users. NameCoin records are in JSON and it seems that one can put I2P destinations instead of IP addresses into DNS zone records.
http://forum.i2p/viewtopic.php?p=35652
http://forum.i2p2.de/viewtopic.php?p=35652