I’m pretty new in Filecoin and IPFS technologies and probably this may have been discussed previously, or there is already a project for this but anyway, here goes:
(I’m aware of namecoin, but maybe this add some additional advantage as it may be more agile/more integrated with IPFS)
It is possible to use the proof of work of Filecoin to create a decentralized name system for IPFS so that it could be used as an higher level IPNS ?
The miner would add to the blockchain the pending identifiers requested by the users as long as the name hashes do not collide with previous ones in the blockchain. He can demand a fee for this service.
Names could have a hierarchical structure, of course: “haskell/lib/parser/…”
names are hashed and become IPNS hashes, so no new data structure is necessary.
once a name is added to the blockchain, the owner can handle his own hierarchy maybe manually, maybe creating his own blockchain.
There are many problems in this sketch of proposal. I obviously can not know many of them since I have not enough familiarity with either IPFS or blockchain. Probably shorter names should be harder to register than longer names, and a proof may be necessary for registering some names.
1 Like
Why, instead, don’t you use Ethereum Name System? (ex: ens.domains )
Check the filecoin whitepaper btw.
According to the Filecoin Whitepaper, the developers see a decentralized naming system as one of the possible future use cases. So I assume you would be able to micropay in ƒ, and the system would store your name record. Don’t know about hierarchies. But since URLs are basically paths, I think you’d only need to register the domain, e.g. skynet.ipfs, and all subdomains like blue.skynet.ipfs and paths like skynet.ipfs/haskell/lib/parser/* would be covered. (?) There will also be a Bridge, e.g. to the Ethereum blockchain et al., so the Ethereum Name System would in my view be compatible.
1 Like
I see this more integrated with IPNS and Filecoin. Basically it is a way to obtaining IPNS identifiers from reserved and meaningful strings. much like people reserve car registration identifiers. Little infrastructure changes are necessary. I think that it is a low hanging fruit.
An hierarchy could be simulated by registering identifiers with slashes /a/b/c. So initially you can either serve files under this hierarchy or be able to administer subdomains for /a/b/c/ . But the first option, which is the common sense one used in protocol agnostic name systems like DNS or (i guess) EtNS, is not the one that I intend.
Originally my idea is that every path is converted into an IPNS identifier and accessed trough IPFS. There is no file serving using HTTP + paths. This makes the naming system tightly integrated in IPFS, unlike other naming systems.
The idea is that every path, for example, /a/b/c/d/e/myfile.pfs is hashed to compose an IPNS identifier. So the owner of /a/b must own all possible identifiers under that subdomain. Otherwise it would be collisions. So he should “administer” that subdomain. So you have to micropay to the owner of /a/b to register /a/b/c and so on.
1 Like