search

ssbc / ssb2-discussion-forum

not quite tiny, also not quite large
17 stars 1 forks source link

"Feed" field, msg "type", no root #5

Open staltz opened 1 year ago

staltz commented 1 year ago

I noticed you renamed the subfeed field to feed which is sensible since this is distancing itself from metafeeds jargon a bit.

But (and I'm not just nitpicking, keep reading...) what if the name were type instead? I'm afraid that feed would be confusing since we already have a "feed ID", but more than that, how about we remove the need for content.type, if we can assume that all messages under a given nested feed are by definition of the same schema. And this means the schema can still have optional fields. For instance with the classic contact messages, the content.type is always contact but there may be content.following boolean, or content.following may be absent if the content.blocking is present. All of this is to say that we could remove content.type and then people replicating these messages can know that there should be only one schema, even though the schema allows some flexibility. I'm not suggesting adding the whole schema in p2panda style, though.

Otherwise we are risking some duplication: msg.value.feed might be "post" which might be the same as msg.value.content.type.

And then, why would we need the top-level feed? Since all messages were assumed to have a content.type, this means that all minibutt feeds should be "nested". In fact, might make sense to not talk about "nesting" since there is nothing "contained" inside anything else. It's just "tagged" with a type.

And that leads me to tags: if we do what I suggest above, then we don't need tag 0 neither tag 1, we would only have the "end of feed" marker, which we could do in a different way.

arj03 commented 1 year ago

When I changed it to feed for a short while I contemplated calling it just type. I think there are two things here: feed might make it a bit more general. This would mean that it would be possible for someone to create a hierarchy if they wanted to. So this comes back to how much flexibility we want. After we made the change in db2 to allow multiple feed types, then adding a new feed format is not that scary. So maybe it's okay that this is just for social stuff. So we really made it super simple.

The other point is that if we use this for the type, then it's one of the bigger breaking changes from classic SSB. At least we need to restructure things a bit in db2 to work it work. Not that that's necessarily a bad thing, just something to be aware of. I'm all for decreasing the size of messages as you can see :) It really does add up when you have lot of them. Also we probably need to tweak jitdb anyway to make it handle edit/delete better. So we do have to make some changes anyway.

The next step for me is to try and play around with this a bit. Then we can hammer out the details. I do like where this is going.