kubo
kubo copied to clipboard
ipfs
Ability to republish third-party /ipns/ records
The publishing node for an /ipns/ name might be offline for an extended period of time; it should be possible for other nodes interested in the node's content to republish the name so it doesn't expire.
This could be done by having nodes explicitly configured with names to keep alive (once automated republishing of your own name is in); or nodes might just refresh records when they resolve them.
Yep agreed. On Tue, Aug 23, 2016 at 23:19 Tangent128 [email protected] wrote:
Type (bug, feature, meta, test failure, question): feature Area (api, commands, daemon, fuse, etc): dht Priority (from P0: functioning, to P4: operations on fire): P1
Description:
The publishing node for an /ipns/ name might be offline for an extended period of time; it should be possible for other nodes interested in the node's content to republish the name so it doesn't expire.
This could be done by having nodes explicitly configured with names to keep alive (once automated republishing of your own name is in); or nodes might just refresh records when they resolve them.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ipfs/go-ipfs/issues/3117, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIcoVQBJPciE7xuNjqtBMFcY0S0iewpks5qi7g1gaJpZM4JrmR6 .
@Tangent128 thanks for filing! Your own name currently gets republished automatically (as long as your node is online of course). We can expand that mechanism a bit and expose it through some api.
My 2 cents:
When I access normal IPFS data, I'm implicitly agreeing to host that data for a while, it should be the same when I access an IPNS record. Popular IPNS records are therefore automatically widely available.
If explicit action was required to host the record, it's unlikely many would do it, leaving IPNS de facto centralised.
@mattseh good point, rehosting ipns records should have the same feel to it as other content on the network. I'm not yet sure how best to do that though, multiple people rebroadcasting the same ipns entry isnt super useful, you really just need at least one. More causes spam (and doesnt actually improve availablility any)
Maybe we could measure availability of IPNS entry, IIRC we query for 20, 16 is accepted as done, otherwise we wait for some timeout. If we reach this timeout, but we have good number of entries (10+) we can rebroadcast the right one back to the network?
Also do we send the right IPNS entry to a peers that sent as a outdated ones?
To add to my point: There is a nice use case for IPFS in general, where a group of computers that are networked together but not connected to the internet can do a lot of useful things, for example sharing files.
If they wish to share files that are updated from a feed that is powered by IPNS, this falls over unless the IPNS owner is part of that network, but this would often not be the case, for example with a popular podcast feed.
First of all, I apologize for my bad english. Hope that you can understand it. (But it very important topic for me, so I'm try to expound my point of view!)
When I access normal IPFS data, I'm implicitly agreeing to host that data for a while
...and when I pin some IPFS object, I'm explicitly agreeing to host that object permanently (until I not unpin that, of course). So maybe the upcoming mechanism of republish third-party IPNS records should contains the same two mode? And process of explicitly republishing of IPNS entries should be named «ipns pinning»?
At least, «ipns pinning» itself would be very useful: when the validity of every IPNS link completely depends on uptime of the node which publishes certain content (let's call this node «Origin»), it's a sort of centralization again, isn't it? But everything changed when appears other nodes interested in the «Origin»'s content. If this nodes (let's call them «Keepers») will have ability to explicitly republish IPNS record of some «Origin», the last state of content that referenced by this record will be available in case of «Origin» temporary go offline, and even completely disappear someday, until all «Keepers» not disappear. (Something like parity in availability of IPFS objects and IPNS links, right?)
Thus, execution of «ipns pinning» maybe should recursive pin IPFS objects which are linked with given IPNS entry too — for ensure consistency of all linked data, not only list of hashes. But on the other hand, some extremely large data published by «Origin» may cause network and/or storage issues on the «Keepers» nodes...
It is possible with keystore.
# generate key
ipfs key gen --type rsa --size 2048 shared-key
# move "$IPFS_PATH/keystore/shared-key" do different machine
# on different machine
ipfs name publish -k shared-key /ipfs/Qm...AAA
Reopening, as we still can't "pin and provide" IPNS records signed by other people's keys.
This would be super useful to have built into go-ipfs. Would outside contributions or a devgrant be appreciated for this functionality?
Yep! Some pointers and previous issues are mentioned in the linked issue (https://github.com/ipfs/go-ipfs/issues/1958#issuecomment-1026322601).
A lot of the work here is UX so would recommend anyone taking this on to post an issue describing their approach to make it easier to discuss before doing all the coding and wiring up. If people would rather discuss once there's a PR + some live code that's fine too just a greater risk that they'll have to rewrite some code.
