Hacker News new | ask | show | jobs
by kang 3924 days ago
From section 3.7.1 of the paper

>"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.
1 comments
drdeca 3924 days ago
Well, I would assume that you could trust the person signing things with a private key about whether it was what they wanted to be treated as the most recent thing to be signed with the private key?

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?

link
_prometheus 3924 days ago
(IPFS author here)

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.

link