Another type of view is a key-value store, with a twist: keys can resolve to multiple values. This is because of the decentralized nature of the data. If two users write to the key foo
while offline, then sync to eachother, they will see both of their entries under foo
afterwards.
This type of key-value store tracks "links" on each message. The idea is that each message includes a list of message IDs of values that came before it, for the same key. Usually "feed-id@seq-num" is the message ID used. Here is an example of three messages that form a key-value store's history:
// feed.key.toString('hex') = 61f6a31961939bc03fdfdba661a15
[
{
key: '61f6a31961939bc03fdfdba661a15',
seq: 0,
value: {
key: 'foo',
value: 'bar',
links: []
}
},
{
key: '61f6a31961939bc03fdfdba661a15',
seq: 1,
value: {
key: 'foo',
value: 'test',
links: ['61f6a31961939bc03fdfdba661a15@0']
}
},
{
key: '61f6a31961939bc03fdfdba661a15',
seq: 2,
value: {
key: 'foo',
value: 'quux',
links: ['61f6a31961939bc03fdfdba661a15@0']
}
}
]
If seq=1 and seq=2 link back to seq=0 on this feed, what value(s) would you expect to see for the key foo
?
Try writing a key-value view of your own with kappa-view-kv with similar data to check your answer.
Once you solve this exercise continue to exercise 15