IPFS+IPRS: general-purpose mutable key-value store?

[Ed Baskerville]

First up, IPFS is great. It actually just worked when I installed it. I inserted some content on my machine and retrieved the content from another machine across the country with no trouble. So—excellent work.

But for IPFS to replace, you know, everything, it needs to function as a general-purpose mutable key-value store, where the values are IPFS content hashes. I haven't been able to figure out myself how far along things are on that front.

So: is it possible, under the current implementation, to mutably map

(IPFS public-key hash, key) -> value [IPFS content hash]

?

The mappings would of course be signed by the public key, and presumably this could be handled by the existing DHT implementation.

And if not, is this what IPRS is intended to do?

I also see that you're talking about a general-purpose publish-and-subscribe system—how are things going on that front? If you had a mutable key-value store, it would be possible to do a dumb pubsub at the application layer on top of that. If the underlying key-value map scaled well, maybe that's all you would need?

Thanks,

Ed

[Stephen Whitmore]

Hi Ed! Lots of excellent questions. I'll do my best to answer. :)

> So: is it possible, under the current implementation, to mutably map
>
> (IPFS public-key hash, key) -> value [IPFS content hash]

Yes, you can do this today using IPNS[1]. Since IPNS already maps your
public key to an IPFS address (mutably), the idea is you'd create an
ipfs merkle object that has the link names of the keys you'd like. Say
you wanted a map that had keys 'foo' and 'bar':

# define an ipfs object (as a merkle dag)
$ cat > map.json
{
"Data": "",
"Links": [
{
"Name": "foo",
"Hash": "QmR6gieKLuNgqKZs6TRgRujmNoKfYtGtviZVvthM9NSy8g",
"Size": 20
},
{
"Name": "bar",
"Hash": "QmUfn33WZcMaGwwE5zBz7LAuHL16tQfxTeqbGrKpL362dr",
"Size": 20
}
]
}
^D

# add it to ipfs as an object
$ ipfs object put map.json
added QmQTw7kK7LdDG5xRjQLhAPiJdxm36ob3ngdrPr1NwTcRYr

# examine it to ensure it maps correctly
$ ipfs ls QmQTw7kK7LdDG5xRjQLhAPiJdxm36ob3ngdrPr1NwTcRYr
QmUfn33WZcMaGwwE5zBz7LAuHL16tQfxTeqbGrKpL362dr 20 bar
QmR6gieKLuNgqKZs6TRgRujmNoKfYtGtviZVvthM9NSy8g 20 foo

$ ipfs cat QmQTw7kK7LdDG5xRjQLhAPiJdxm36ob3ngdrPr1NwTcRYr/foo
foo's value

Nice! Now to make our node's IPNS entry point to it:

$ ipfs name publish QmQTw7kK7LdDG5xRjQLhAPiJdxm36ob3ngdrPr1NwTcRYr
Published to QmRc5iJERYKMjFsJ57jsxJhUjf86HL1WyqrQBTJrCCAnKN: QmQTw7kK7LdDG5xRjQLhAPiJdxm36ob3ngdrPr1NwTcRYr

Now we can lookup values using 'ipfs cat
QmQTw7kK7LdDG5xRjQLhAPiJdxm36ob3ngdrPr1NwTcRYr/foo' or even by querying
the public gateway:

http://ipfs.io/ipfs/QmQTw7kK7LdDG5xRjQLhAPiJdxm36ob3ngdrPr1NwTcRYr/foo
(if you've had 'ipfs daemon' running)

> I also see that you're talking about a general-purpose
> publish-and-subscribe system—how are things going on that front? If you had
> a mutable key-value store, it would be possible to do a dumb pubsub at the
> application layer on top of that. If the underlying key-value map scaled
> well, maybe that's all you would need?

Yep, you're exactly right! There's been a lot of thinking on this:

https://github.com/ipfs/notes/issues/64

and even an app-layer overlay network proposal:
https://github.com/ipfs/notes/issues/108

---

Hope this answers your questions! Thanks for writing: please feel free
to chime on any of these issues if you have any thoughts.


//noffle


[1] https://github.com/ipfs/examples/tree/master/examples/ipns

> --
> You received this message because you are subscribed to the Google Groups "ipfs-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ipfs-users+...@googlegroups.com.
> To post to this group, send email to ipfs-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ipfs-users/1a51a18a-4373-474c-985c-878e982f77d5%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Stephen Whitmore]

Oh, and to look it up using IPNS now that you've published, you'd just
replace /ipfs/Qmsomehash with /ipns/Qmmypublickey, e.g.

$ ipfs cat /ipns/QmRc5iJERYKMjFsJ57jsxJhUjf86HL1WyqrQBTJrCCAnKN/bar


//noffle

On 02/22 11:35, Ed Baskerville wrote:

[Ed Baskerville]

Awesome, thanks. I think I understand things much better now. And I'll follow those discussions on GitHub, looks like that's where the action is.

While I'm asking, a few more questions that this triggers...

(1) Would it be considered bad form to run multiple IPFS daemons with *different* public keys on the same machine (even same interface) as a way to distinguish, say, different app instances?

(2) Does it currently work to run multiple IPFS daemons with the *same* public key, either on different machines or on the same machine?

(3) If you can do (2), what happens to competing IPNS records?

[Stephen Whitmore]

> (1) Would it be considered bad form to run multiple IPFS daemons with
> *different* public keys on the same machine (even same interface) as a way
> to distinguish, say, different app instances?

It shouldn't be a problem: peers are addressed by their public key *and*
their network address, so multiple local daemons may look like this to
the rest of the IPFS world:

/ip4/104.131.131.82/tcp/4001/ipfs/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ
/ip4/104.131.131.82/tcp/4002/ipfs/QmRc5iJERYKMjFsJ57jsxJhUjf86HL1WyqrQBTJrCCAnKN

> (2) Does it currently work to run multiple IPFS daemons with the *same*
> public key, either on different machines or on the same machine?

I haven't tried this, but it should work! There's no authority on the
network that could know you're doing this for sure / stop you.

> (3) If you can do (2), what happens to competing IPNS records?

My understanding is that you'll clobber each other's. From the
perspective of other peers on the IPFS DHT, you're the same node, since
you're using the legitimate private key, so they'll trust you and
replace the entry.

There's talk of building CRDTs on top of IPFS to make these sorts of
data structures more viable. It's a huge thread with lots of points all
over the place, but may be a good place to start:
https://github.com/ipfs/notes/issues/40


//noffle

> > an email to ipfs-users+...@googlegroups.com <javascript:>.

> > > To post to this group, send email to ipfs-...@googlegroups.com

> > <javascript:>.

> > > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/ipfs-users/1a51a18a-4373-474c-985c-878e982f77d5%40googlegroups.com.
> >
> > > For more options, visit https://groups.google.com/d/optout.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups "ipfs-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ipfs-users+...@googlegroups.com.
> To post to this group, send email to ipfs-...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/ipfs-users/a731166e-1407-4deb-b011-33187d6da881%40googlegroups.com.