Yeah, so this is the design decision that I don't really understand. Each message on the blockchain contains the author's public key representing his identity. If I already know the identity of the author, I could just go ahead and befriend him and later ask him or other peers who are his friends to share his "feed" with me. If the feed lives in a relational DB, I could then use SQL to ask for particular messages like:

"select * from posts order by created_at desc" or: "select * from posts order by created_at asc where created_at > <timestamp>" or: "select * from blobs where type = 'photo'" etc.

In other words, I could query the feeds the way I want to. Also, this allows the author to delete the content, although this would also require to send some DELETE requests to peers mirroring the author's feed and those requests would have to be respected, but that's another story.

The idea behind this is that it's streams all the way through, so there could be something more efficient to use for these "rolling" database that basically are streams of data. So instead of SQL, it's map-filter-reduce, a query engine that works over streams. https://github.com/ssbc/ssb-query/blob/master/README.md - https://github.com/dominictarr/map-filter-reduce

It's probably a result of going with pull-streams and basically architecture all scuttlebot tools/libs around pull-streams, so you want something that works over streams.

And yeah, Scuttlebot is not built with SQL as it's query language, but you could probably easily write something that understands both SQL queries and the file format scuttlebot stores the messages in. Thing is, you don't want to send these queries to other peers (they are all local), because the system is setup to be offline-first and only reach out to the network when it has to, not just for listing latest messages.

In general, you want all the action of fetching/syncing of data to happen exactly when you want it to happen, and then when you're done it doesn't continue until next "sync". So everything you do is local.

But then, if "query the feeds the way I want to" is the reason you don't like it, then so be it. But if it's just that you don't understand it, then reading through and digging into the different repositories will give you a better viewpoint. Start at the ssb-query and look what's using it and what it's using.

I didn't mean to be provocative, I just wondered what's the advantage of that particular setup. I guess your comment and the peer's explain it pretty well. Also, thanks for the links to the repos. I'll start from there.

Is there any dev forum on ssb or other place I could catch you guys at if I want to learn more or contribute?

I think they want to guarantee an unbroken chain of entries because a malicious client could otherwise omit some entries as a means of tampering with the message that was intended to be conveyed, or to censor some messages.