IPNS is Great. IPNS builds a decentralized DNS-like system and makes us possible to create a mutable website. However, IPNS also has its own problem and the problem is that IPNS could lose record. This problem will be pretty annoying sometimes when I use IPNS in my project. For example, Image that you are building a decentralized web forum and you decide to save an IPNS address as a pointer to user’s posts. Unfortunately, users are not tech-savvy and they will forget to, or just don’t want to, republish their IPNS address every 24H (Default IPNS lifetime). Maybe someone will say:” Why not let users push their posts to a special sever and then let the server publish posts to IPFS? ” Yes…It works and it is an effective way. Actually, the ZeroNet forum exactly uses the same model. (See their slide). But, It means centralized and the owners of the forum still have the right to censor, or prohibit, posts that they do not like. (I come from China, so you know why I hate censorship so much).
Anyway, saving IPNS records is a quite common need for many services. If it is a common need, It’s worth standardizing. And there are two ways to finish this job.
IPFS Feature
The first way is that makes this function to become a feature of IPFS. As I know, IPNS record is just special data in the IPFS world. Maybe we can pin this data and automatically update it when the data changed?
Common Stand
Or, We can follow the same stand and make some libraries to handle this job.
And those are my opinions. I’m not a native English speaker, so if I made any grammar mistake, welcome to point out.
I think this is a great proposal. IPNS is an intuitive tool, and I think an excellent way to popularise its use is to incorporate the functionality needed into the most widely used applications. For example, create the code needed to acheive this and then put it into ipfs-desktop. Have the ipfs-desktop, while running, renew the IPNS pins on a regular basis. When creating the code, construct it in such a way that it could be easily lifted and dropped into other such applications.
The ensuing user demand for this IPNS functionality ought to be sufficient to prompt other developers to use the code and keep it up to date.
That is the default indeed.
You can just publish an IPNS with a lifetime for 1 year (8760 hours). It works and is allowed,
The real problem comes when you update an IPNS record.
The network will then demand that update to come from the creator (the one that did the initial ipns name publish). Once a few nodes know this, it will propagate through the network (to the nodes trying to resolve it). But the initial update must come from you.
I don’t really see the point in both of your proposals. IPNS is a feature already… It’s just tricky to get your IPNS propagated to enough nodes to be available all the time. That’s the issue that needs a solution. And as an IPNS record is just some little data, the same rules (i assume) apply. A user needs to resolve it first (just accessing an IPNS hash does that) for that user to become a host of the IPNS record too.
I have a different proposal I would like to make it right now but don’t want to do alone.
What i basically want to make is a cluster (just free-standing, not with ipfs-cluster) of about 30 nodes. It needs a point of access (can be via a pubsub channel) in which users can say “hey, broadcast this IPNS for me”. It then propagates through the cluster. This application needs to be able to run alongside IPFS. So for example, if you want to help propagating IPNS records, you just install it (point it to your local node) and you’re up, helping the network.
The tricky thing here is spam prevention, some form of authentication and some form of an API.
Note that those “30 nodes” i mentioned would be the ones always running. It’s the minimal. Anyone should be able to join thus in time it should grow to much more.
You can see it as an PIN service for IPNS. It also needs some form of an API as well to allow users to integrate in their workflow, this again can be on pubsub.
And if everything is done over pubsub, it’s essentially completely transparent with not a single point of entry or failure. The pubsub name doesn’t count as a single point because you’re already on IPFS if you use pubsub.
@markg85 This idea is pretty cool. I have some thoughts about spam prevention and that is using the IPNS private key to encrypt updating information. I don’t know does it work, but as I know, IPNS based on public-key cryptography. So using IPNS private key to encrypt updating information should work?
And there are also somethings I don’t know how it works. If you use the pubsub as the way to update records, users must link to one of the PIN-cluster’s nodes to update. So how users found the address of the node and if this address is banned how users to found a new one?
That’s not a problem. Only the author of the IPNS record can update it. That’s by design i think.
That’s where the security and authentication issues comes.
First off, the user doesn’t need to be connected to the “ipns pin cluster” at all. It’s just traffic over pubsub. The user only needs to know in which channel to say “hey, update this for me please”.
The real challenge is in handling that very message of the user. How i would design it is that i would only allow the author of the IPNS record to ask the cluster to update that record. So somehow the cluster needs to be able to verify that the one asking for an update is the actual author. This on it’s own might be all the spam prevention too. Not sure about that yet though.
The cluster obviously has a site somewhere to register. There would be a good place to announce the pubsub channel in which users can send their “update my IPNS please” requests. It probably needs to have some more metadata along with it as a user can have multiple IPNS records. Right now i’m not even considering something with banned records as that adds a whole new can of issues to tackle. Right now the idea is just to keep IPNS records alive and easy to find for nodes to give IPNS a snappy response. But yeah, something along these lines is what i’m thinking about.
Lastly, this is totally transparent for the IPFS network. To make use of it you have to do absolutely nothing. You just visit a /ipns/hash url and your IPFS client presumably (that’s the whole goal) find a node very quickly to resolve the /ipns/ to the corresponding /ipfs/ address.
As my experiment, I still need to add test nodes manually, then they can communicate with each other. Maybe because pubsub still is experimental and most node in network doesn’t enable it.
As I said before. You can accept a new record encrypt by publisher’s ipns’s private key and ipns address should be the public key. So you can check if is publisher authority.
You know, ipns address is generated from ipns private key.
But it isn’t “that” trivial yet.
IPFS 0.7.0 made this possible. There keys are ed25519 for IPNS. That’s one part of the puzzle.
The other part of the puzzle is that the user’s peer id must be in this format too. If both are then you have the public key of the user (it’s embedded in the peer id) and you have the public key of that IPNS hash. With those two you can verify that the IPNS key was created by the peer id.
It’s all possible, but it requires the use of ed25519! As if you don’t have that then you need to ask the user to publish his public key somewhere. Then it becomes a whole lot more tricky.
And all of the above only works if the user uses pubsub from a node from which the user also had done the ipfs name publish command.
So those are 3 conditions that need to be aligned perfectly to even make it work.
On top of that, i also had the idea to just let a user know from any node that he wants some IPNS to be spread through the cluster. With that idea comes the issue of proofing. I’d need to “see proof” that the IPNS the user wants to publish is his to begin with. I’m not sure how to solve this one yet. We might just not add it…
I would like to make it right now but don’t want to do alone.