Hosting a simple static site on IPFS(gateway.ipfs.io) |
Hosting a simple static site on IPFS(gateway.ipfs.io) |
I started off mirroring my blog on Freenet and and now I'm experimenting with storing it there first and using a reverse proxy to make it available on clearnet [1]. This approach would work on IPFS and Morphis too. If the clearnet site gets taken down it's always available on the distributed store and it's simple to spin up a proxy somewhere else to provide clearnet access.
For systems where unpopular data goes away over time the access via the clearnet proxy provides more access to it to make that less likely since clearnet is full of crawlers, bots, search engines etc constantly hitting it.
[1] http://bluishcoder.co.nz/2015/09/14/using-freenet-for-static...
1. Add a TXT record to DNS <domain> with:
dnslink="/ipns/QmWGb7PZmLb1TwsMkE1b8jVK4LGceMYMsWaSmviSucWPGG"
See it in action here: https://ipfs.io/ipns/ipfs.io
WARNING: IPNS is still under dev. it's not robust yet, convergence may not be perfect.
While IPNS is indeed a way of assigning and reassigning names, it is not very user friendly, as it exposes long hash values as names, which are notoriously hard to remember. These work for URLs, but not for many kinds of offline transmission. Thus, IPFS increases the user-friendliness of IPNS with the following techniques.
[1] https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-...
For example, the ipfs.io site is hosted on ipfs/ipns, and available through the gateway at https://gateway.ipfs.io/ipns/ipfs.io/
>"Because this is not a content-addressed object, pub- lishing it relies on the only mutable state distribution system in IPFS, the Routing system. The process is (1) publish the object as a regular immutable IPFS object, (2) publish its hash on the Routing system as a metadata value"
How is the ordering done? In a quickly changing content, a blockchain would be required for ordering.
s/peedID/peerID :)
There should be some progress on ipns pretty soon, i'm working on a 'phase one' fix that improves upon the current situation, and will be replaced later by our final implementation once the specification and requirements for it are complete.
But, I might be misunderstanding some things about how the updates are sent.
I thought one just sent a message signed with the key with a newer ID and sent that to whoever was keeping track, and they would verify it was signed, and had a newer id and would share it further.
Is this not how it works?
I mean I guess malicious or lazy nodes could not toward things, but that would just make things not get updated, usually couldn't cause things to revert, and couldn't make up stuff, so...
That's how it works, right?
You're hitting on some really hard questions :)
the gist is that you use a "record system" that has some transport guarantees, for example relying on a dht has certain kind of properties, as opposed to relying on pub/sub over trusted nodes. IPFS has this part as pluggable, though we're focusing on a large public DHT first. DHTs are pretty robust today, though yes have weaknesses we're working on.
now, the key is that, on top of that, you build assurances around cryptographic freshness (i.e. "trust this record for a certain amount of time"). of course, "certain amount of time" varies with your notion of time (e.g. NTP, vs blockchain times, etc), so the user gets to set that.
if you're interested in how the "record system" works and will evolve, take a look at https://github.com/ipfs/specs/tree/master/records -- though admittedly this is not complete or exhaustive, as we have A TON to do and are focusing on pushing out reliable code.
https://github.com/ipfs/go-ipfs/blob/7fbfecf6fab5920317de2e9...
When new nodes enter the network, they connect to a subset of this list and use this as a starting point for discovery.
After that, queries/operations on the DHT will result in the discovery of other nodes.