Publishing IP addresses

[rendaw]

For me the killer IPFS feature is a distributed DNS, which should be IPNS to the best of my understanding. However the name system CLI in go-ipfs at least seems to reject payloads that don't match a certain pattern, I think strings starting with "/ipfs/"? It would be great to be able to use it to give a name to a server, for all the typical uses one would want from DNS (web, mail, ssh, server-server communication, etc). Is there anything preventing this restriction from being relaxed?

I googled for a while and couldn't find any discussion on this topic and TBH I'm not sure this is the right repository, so apologies if it isn't.

[aschmahmann]

@rendaw this is probably fine, although discuss.ipfs.io is good for discussions and go-ipfs is good for go-ipfs specific feature requests.

For me the killer IPFS feature is a distributed DNS

I'm absolutely a big fan of this!

seems to reject payloads that don't match a certain pattern

In go-ipfs ipfs name publish it's valid to paths that look like /ipfs/CID, /ipld/CID or /ipns/{IPNS_ID or DNSLink}, while that could be changed to a more permissive structure /foo/bar I don't think it's necessary to achieve what you're looking for.

a distributed DNS

For many use cases you can already do this by simply using IPFS as is. In particular:

• If you wanted to map Hash(PublicKey) -> multiaddress (i.e. Qmxyz -> /ip4/1.1.1.1/tcp/1234) you can already do that simply by searching the DHT for that peer's address (ipfs dht findpeer Qmxyz), or more generally using the command ipfs swarm connect /p2p/Qmxyz followed by ipfs id Qmxyz.
  • This approach is restricted to finding the addresses of a peer via it's PeerID. However, if you were looking to have 100 nodes each with a different PeerID and then dynamically point Hash(PublicKey) at each peer over time this wouldn't work for you.
  • Note: I have used this pretty successfully (along with this https://github.com/ipfs/go-ipfs/blob/master/docs/experimental-features.md#ipfs-p2p) to be able to SSH into a particular machine without needing to know its IP address ahead of time (especially good since IP addresses may change over time), just its peerID
• If you wanted to map Hash(PublicKey) -> DNS address (i.e. example.tld) you can use IPNS where the value is /ipns/example.tld
• If you wanted to map Hash(PublicKey) -> arbitrary content then you can use IPNS where the value is /ipfs/CIDofMyArbitraryContent and then just get the content via IPFS (e.g. ipfs get /ipns/Qmxyz or ipfs dag get Qmxyz)
  • Note: Recall you don't have to use files you can create arbitrary IPLD objects
  • Note: This requires one more resolution step to actually resolve the content, although depending on your use case that may not be such a problem
    • Is this why you are asking to allow for laxer IPNS values? If so asking for multiaddrs to be allowed as paths (i.e. `/ip4/1.1.1.1...) is potentially pretty reasonable.

What kind of scenario were you thinking of, do any of these options work for you?

[rendaw]

Awesome! I was worried this wasn't in line with IPFS goals so it's a relief to hear!

My goal is, roughly, a consistent name that I could map to a server that might change over time, so I can hard code the address in scripts or configs, bookmark it, etc. (edit: and without having to get involved with the dns registrar mess)

The last suggestion might work, although it sounds like an extra-protocol extension, so for instance browsers with the IPFS extension wouldn't necessarily know what to do if they encounter it (if the browser gets a url that points to a document containing 34.123.123.4 or whatever, should it display the content, redirect, or show the http response of the ip http request with the current url in the address bar?). In this case I think the setup would be ipns name -> ipfs content addr -> document containing ip?

The peer id one sounds pretty close and tbh I wasn't aware of it, but I think it has these restrictions:

1. You can only map the current host's ip address, so if I couldn't publish an ip for a different host or a 3rd party server or something.
2. The peer id is the root key id, which is ephemeral I think by design - in discussions of backing up keys the root key was singled out as "shouldn't be exportable/importable". So if I lost the server and needed to recreate it, or wanted to fail over to another system for maintenance, the id would change.
3. You can only publish one ip this way, if you have multiple servers you'd have to run multiple instances of ipfs at least.
4. Not sure on this one, but are /p2p/... paths recognized in the same contexts as other paths? Ex: a hyperlink in a ipfs document containing href="/p2p/Qmxyz".