It’s a decentralized/distributed P2P CAS (Content Addressable Storage), P2P protocol stack and set of tools for leveraging any data and creating decentralized / local first applications of different sort.
It contains tools for manipulating blocks, merkle trees, E2E encryption keys, mutable references, etc.
The primary goal of HBS2 is to organize team work in git without using GitHub or similar centralized services.
At that moment (2018-2019) Radicle did not work well for me / it was not clear if it really works at all.
At the current moment it I believe Radicle works pretty well (But I do now know fo sure).
Radicle is Git-centric, i,e it relays on Git storage (which is not good for managing large data amounts), and ot implements some sort of git protocols propagation via P2P Gossip network.
HBS2 do not relay on Git storage or protocol, it implements a CAS with P2P replication and implements Git remote protocol helper for git to work with HBS transparently.
I.e all git objects are stored not only in Git storage, but in HBS2 in hbs2-git own data format.
Therefore, hbs2-git is just an application for for HBS2, one of many.
For an instance, this very web site is an another HBS2 application
It is largely inspired by Syncthing. We initially tried to set up collaborative workflows using Syncthing to share repositories or just binary data—but we didn’t have much success.
Quite literally, while sitting at the same café table on public WiFi, we couldn’t even send a file from one user to another.
Git repositories cannot be safely shared among multiple users via a shared file system or a shared directory like Syncthing, because it isn’t a pure CAS—it contains enough mutable files that cannot be safely or deterministically synchronized using Syncthing.
Syncthing is host-centric, meaning it requires knowledge of host keys, which is inconvenient.
In HBS2, the units of synchronization are blocks, Merkle trees, or references—none of which are tied to a specific host. Instead, trust in the data is established through trust in the keys used to sign the data or the communication channels.
Additionally, unlike Syncthing, HBS2 encrypts data not just at the transport level but also at the storage level, ensuring that data can be distributed even by network participants who do not have access to it.
Still, I’m using Syncthing for synchronizing some of my personal data between my hosts.
But plan is to migrate to HBS2 ASAP (hbs2-sync project).
No, it is not.
There are bunch of protocols/projects that use JSON for everything. Like Nostr, etc. HBS2 does not.
JSON is both bulky and ambiguous, yet somehow still limited.
SEXPs were way better than JSON far before JSON even existed.
In fact, JSON just a poor man’s SEXPs. However, I’m not trying to rebuild the world.
HBS2 uses CBOR within protocols and data structures, while uses SEXPs as glue — because CBOR is compact, fast, less ambiguous, and easier to cryptographically sign.
Note, that HBS2 uses UDP as well as TCP, so compactness is important.
Maybe CBOR isn’t the most compact format out there — but it’s widespread enough to make up for it.
However, if you prefer JSON, it’s always somewhere nearby:
$ hbs2-peer poke | hbs2-cli [json [top:stdin]] | jq
[
[
"peer-key:",
"5GnroAC8FXNRL8rcgJj6RTu9mt1AbuNd5MZVnDBcCKzb"
],
[
"udp:",
"0.0.0.0:7354"
],
[
"tcp:",
"tcp://0.0.0.0:3001"
],
[
"local-multicast:",
"239.192.152.145:10153"
],
[
"rpc:",
"/tmp/hbs2-rpc.socket"
],
[
"http-port:",
5000
]
]