Feedback

[staltz]

I'm hyped to see this! Thanks for coming up with something so quickly. I'm aligned with everything you said in the "goals" part of the spec, and most of the technical stuff seems familiar to me given buttwoo.

Here are some questions.

Dropping the linear requirement is indeed important for fork protection or fork merging, but wouldn't it make sense to drop sequence and bring back previous? Because the sequence because it's based on incrementing numbers obviously creates a total order among the msgs, but a chain of previous would create a DAG of your msgs. This would provide a way to partially order the msgs (instead of total order) and those msgs that are not comparable would mean a fork and then you can resolve the fork with a merge. But as far as I understand if you have sequence numbers then you have to choose to elect one of the forks as official and drop the other fork. Without a merge, that is. Or, how else where you envisioning merges of forks in minibutt?

The other question I have is about that request in the simple replication. I didn't understand the dictionary, could you expand with more details? Also, what are the types of those fields "reverse", "limit", etc. Numbers? Booleans? Strings?

@arj03

[staltz]

Oh and one more thing, let's call this "metafeed alternative" as "nested feeds", just to have a new word for this pattern.

I believe there could be a design of nested feeds that doesn't require you to announce the existence of a subfeed with those tags etc. Each announce msg is basically overhead. And it creates the possibility of sub-subfeeds, which I'm not sure we need (see e.g. the v1 structure of metafeeds where there is only depth 4, and depth 1, 2, 3 are just overhead because all the actual content goes only in depth 4 and there's no depth 5). Could there be a design of nested feeds such that you don't need to declare subfeeds? E.g. the first time I publish a chess msg, I do that under the feed ssb:minibutt/QlCT8a9g010/chess without announcing it. Peers who want to replicate this just EBT request for this feed ID, regardless if I ever created a chess msg or not (if I have never created one, then that nested feed would be empty, i.e. no peers would have its data when they get the EBT request).

[arj03]

I'm hyped to see this! Thanks for coming up with something so quickly. I'm aligned with everything you said in the "goals" part of the spec, and most of the technical stuff seems familiar to me given buttwoo.

Great to hear :)

Dropping the linear requirement is indeed important for fork protection or fork merging, but wouldn't it make sense to drop sequence and bring back previous? Because the sequence because it's based on incrementing numbers obviously creates a total order among the msgs, but a chain of previous would create a DAG of your msgs. This would provide a way to partially order the msgs (instead of total order) and those msgs that are not comparable would mean a fork and then you can resolve the fork with a merge. But as far as I understand if you have sequence numbers then you have to choose to elect one of the forks as official and drop the other fork. Without a merge, that is. Or, how else where you envisioning merges of forks in minibutt?

You can think of sequence as a soft ordering of a DAG. Meaning that you can detect forks (same sequence) but that the "merge" is a bit less specified. You can get a bit closer by looking at the timestamp, but I don't think that is in itself a problem. If it's important for your application that you can resolve forks, then we already have a very good tool for this: tangles. I do expect edit / delete to be tangled btw. Just that we don't need the whole chain to be strictly ordered. I'll make that more clear in the docs, because it's clearly really important.

The other question I have is about that request in the simple replication. I didn't understand the dictionary, could you expand with more details? Also, what are the types of those fields "reverse", "limit", etc. Numbers? Booleans? Strings?

I'll update that section so it's more clear. It needs some justification and numbers that I have on paper.

Oh and one more thing, let's call this "metafeed alternative" as "nested feeds", just to have a new word for this pattern.

Good idea with a different name to keep things separate.

I believe there could be a design of nested feeds that doesn't require you to announce the existence of a subfeed with those tags etc. Each announce msg is basically overhead. And it creates the possibility of sub-subfeeds, which I'm not sure we need (see e.g. the v1 structure of metafeeds where there is only depth 4, and depth 1, 2, 3 are just overhead because all the actual content goes only in depth 4 and there's no depth 5). Could there be a design of nested feeds such that you don't need to declare subfeeds? E.g. the first time I publish a chess msg, I do that under the feed ssb:minibutt/QlCT8a9g010/chess without announcing it. Peers who want to replicate this just EBT request for this feed ID, regardless if I ever created a chess msg or not (if I have never created one, then that nested feed would be empty, i.e. no peers would have its data when they get the EBT request).

Yeah, I basically started from the other end saying that I want these feeds, and then left out the part of what kind of structure we need to realize that. We could, as you say simply start with this and then if we do find that we need some more structure we can always add it. The "root" or "empty subfeed" feed is not used with the ones listed.

[arj03]

Great feedback. I mulled over the sequence versus previous and I think people will forever be confused if we don't do previous, so lets stick with that. The overhead is not that bad with 16 bytes hashes. I believe I have incorporated the rest of your feedback as well.

[staltz]

Neat (and logical) that previous would be an array.

About the shs problem, well spotted. And yes it would be a good opportunity to take this problem into account when designing shs2. I believe also that reusing a keypair across many devices may break other assumptions in the ssb stack, so we gotta keep our eyes open.