SSB downloads the whole feed so it can guarantee that a peer hasn't maliciously withheld certain previous messages from the feed.
I guess (waves hand vaguely) that constraint probably isn't relevant for version control, because subsequent commits would fail to apply…? Not sure. But if you're only interested in recent history, you could probably do something like a shallow clone.
This way, you would know about all the messages and blobs, but only download those you want, and match their content against the hash. Of course, this comes with less replication, therefore less availability.
> The first time you join the network there will be a lot to download and process. For real, this “inital syncing” process can take up to an hour and use a couple of gigabytes.
Are you saying the ssb project's website is wrong here? (I don't use ssb, so I'm going by what's documented only)
- Your SSB client downloads feeds you follow, plus feeds they follow, and possibly feeds they follow too
- When downloading lots of new feeds at once (for example, the first time you sync) your client makes no attempt to prioritise which feeds it downloads first
- Your client downloads all blobs (attachments) greedily
- Your client indexes downloaded messages (for example, to find the recent messages from all feeds); its implementation of indexing is slow and heavy; until indexing is complete, the app is unresponsive
None of these assumptions is necessarily true of an SSB client, but they're generally true of popular existing clients.
SSB doesn’t have a root node, so if you think of yourself like an island the data transfer required from your first “bridge” is going to depend on what you are bridging to.
In practical terms, if you join one of the SSB pubs published in their documentation, you’ll sync whatever is on that pub.