I am in need of a way to store content (just a few kilobytes, probably) that will be modified rather “rapidly” (let’s estimate it at 20 times a day or something like that), and maybe not always from the same peers.
It is important that this is all pointed to by a single URL, so it seems that publishing the CID of my content to IPNS with a generated key works well.
My problem is the following: after publishing from two (or more) different peers, using the same key, I don’t get the same IPNS name resolution from different gateways/nodes/etc.
For instance if I simultaneously run ipfs name resolve <hash> --nocache on both peers, the result is different (both return the CID that they published), and if I try to access it from a public gateway (gateway.ipfs.io/ipns/hash, etc.) from different geographical locations (sorta simulated by Tor routing) the file that I get back is different as well.
I see that after a bit of time (a bunch of hours, from what I’ve experienced) the IPNS record gets propagated and eventually the nodes agree on what CID they should be serving, but this is too slow for the frequency of mutability that I require.
I don’t necessarily need to access it from public gateways (although that’d be great); any solution that lets me find the very last CID published to that name will work.
Any thoughts, workarounds, or perhaps other ideas to sort this out? Thanks.
IPNS over pubsub works a bit better so that is good.
Onto the other, I’ve played around with --ttl and --lifetime now, and this seems to be great for “ignoring” older records once they expire (configuring a low enough --lifetime parameter).
Still, this doesn’t quite suit my needs because it might be the case that I run out of records and the IPNS name can’t be resolved to anything. The “20 updates a day” I said is just an estimation and you could very easily have stretches of no updates, so it is not easy to just set a --lifetime of 1 hour or something and be good with that. (From what I can tell, at least).
Do you have any other suggestions that could help to have the content updated as quickly as possible, yet always leaving the latest file up?
Ideally, this should work like a shared GDocs link.
It might help if you describe what you’re looking to do and what your requirements are. If you are able to relax the requirement for a fully distributed system you might be able to use something like the recent IPNS-Link.
It is good enough for speed but only if the last posted record of the node where I’m running ipfs name resolve has already expired, otherwise I’m getting the CID of the last ipfs name publish on this node even if there is a newer CID to resolve to (published by other peer of course).
The same is kinda true when accessing the IPNS hash via my browser at gateway.ipfs.io/ipns/hash or any other. I still can’t manage to force the most recent record to show up there.
(Side question: is there any way to resolve an IPNS name without fetching the file of its pointed to CID on a public gateway, or in the browser in any way?)
What I’m trying to achieve is basically a “public folder” accessible from a single URL with some text/JSON files that get updated from an external application (through js-ipfs probably). This will in principle be from a single peer, but I want to make sure it can work from multiple too (or rather, make sure that I can publish from a different peer to the same IPNS name seamlessly).
For the time the data is not updated on IPFS, my system is inconsistent. (I can afford some temporal inconsistency but not having it or reducing it as much as possible would be ideal).
I know this might be similar to a public database (I’m also testing out OrbitDB for this purpose) but if I can achieve it with IPNS alone that’d be good.
If the set of peers doing the updates is known in advance, you can tell them to connect to each other with Peering Agreements. That combined with IPNS-over-PubSub should help dramatically, as each peer won’t have to look for other peers having the relevant metadata, and any change will be propagated directly to all interested peers.
Otherwise, creating a Pubsub topic for the file subscribed by interested peers may help.
I think ipfs is more like you can’t use it to build instant messaging because you have to discover the peers, we can ask ipfs to implement presisdent connections that improves latency on new contents (chat message etc) being shared between previously connected peers, but we can also take ipfs for what it is right n that’s a file system, that’s more suitable to sit on the server, but of course at the end of the day it would be possible to tell everyone to buy their own server and that comes with ipfs pre-installed which will be a stack that other applications sits on top of like for example sharing 5GB files in chat room (but the chatting app talks directly to eachother in their own way skipping ipfs, they could sync settings using ipfs, I guess)