IPNS is quite a bit more flexible than it seems. Being able to get a value with a public key and set it with the private key, allows various constructions.
First off, there's the standard "I want an updating website".
This is quite bland - just the simple case of people who want to view the website having the public key,
and the author(s) having the private key.
An example is ipfs.io itself.
Second, there's verification.
Publishing something, directly or indirectly, onto an IPNS key is essentially a signature.
If that signature should have meaning depends on if it was published with the intent of signing it, so that'll be app-dependent.
It also makes revoking a signature quite easy, which could be a good or bad thing, depending on how you look at it.
If you want to know if something was "IPNS signed", you just check whatever structure the thing is supposed to be contained in, and if it's not there, it's not signed.
This is how Mewler does verification - "Yellow" mews are unknown, and when you load the feed of the person it's supposed to be by, if the mew doesn't show up, it turns red, else it turns green.
Third, there's blockchains. Yes, blockchains on IPNS.
Perfectly possible, you just make a keypair public. I say keypair because you make the private key public too, so everybody can publish to it.
Then you write a client that does the usual verify-revert-etc. to keep the blockchain working, using IPNS as the medium for the pointer to the top of the blockchain.
IPFS is particularly suited to these systems, since it's hash-addressed.
The obvious example would be something like Bitcoin, but other, somewhat more interesting systems, such as a public website index with keywords, or a comments feed, are also perfectly feasible.
There are probably a lot more structures out there.
The point is that there is a lot of flexibility in IPNS, despite it's simplicity.
Of course, none of this (EDIT: At least the cases where the keypair being written to isn't your direct identity, which means the blockchain and other things derived off of a central user-updatable index key.) is doable without the ability to easily write to any IPNS keypair given the private key.
I've noticed in the go-ipfs code that there is support for just this ability, only the support for a privkey parameter in ipfs name publish is missing.
IPNS is quite a bit more flexible than it seems. Being able to get a value with a public key and set it with the private key, allows various constructions.
First off, there's the standard "I want an updating website".
This is quite bland - just the simple case of people who want to view the website having the public key,
and the author(s) having the private key.
An example is ipfs.io itself.
Second, there's verification.
Publishing something, directly or indirectly, onto an IPNS key is essentially a signature.
If that signature should have meaning depends on if it was published with the intent of signing it, so that'll be app-dependent.
It also makes revoking a signature quite easy, which could be a good or bad thing, depending on how you look at it.
If you want to know if something was "IPNS signed", you just check whatever structure the thing is supposed to be contained in, and if it's not there, it's not signed.
This is how Mewler does verification - "Yellow" mews are unknown, and when you load the feed of the person it's supposed to be by, if the mew doesn't show up, it turns red, else it turns green.
Third, there's blockchains. Yes, blockchains on IPNS.
Perfectly possible, you just make a keypair public. I say keypair because you make the private key public too, so everybody can publish to it.
Then you write a client that does the usual verify-revert-etc. to keep the blockchain working, using IPNS as the medium for the pointer to the top of the blockchain.
IPFS is particularly suited to these systems, since it's hash-addressed.
The obvious example would be something like Bitcoin, but other, somewhat more interesting systems, such as a public website index with keywords, or a comments feed, are also perfectly feasible.
There are probably a lot more structures out there.
The point is that there is a lot of flexibility in IPNS, despite it's simplicity.
Of course, none of this (EDIT: At least the cases where the keypair being written to isn't your direct identity, which means the blockchain and other things derived off of a central user-updatable index key.) is doable without the ability to easily write to any IPNS keypair given the private key.
I've noticed in the go-ipfs code that there is support for just this ability, only the support for a privkey parameter in ipfs name publish is missing.