You are reading content from Scuttlebutt
@Alexandre Oliva doesn't consider #git-ssb P2P

I've contacted the author, but they seem to believe that #SSB does not meet some criteria to be considered distributed/P2P. Reasons have so far been that some documentation uses the term decent(ralized) (as if that ruled out distributed/P2P), and the importance given to pubs in documentation, that seems to suggests to him that they're indispensable for discovery of peers.

I'm trying to explain to him that pubs are no different from regular peers, except that they're labeled as pubs and they have stable addresses, but that peers can be discovered from any other peers, and that any nodes at stable addresses can issue invite codes.

Would anyone more authoritative WRT the SSB protocol like to contact the author and offer some clarification? (or maybe teach me, in case I'm the one missing something ;-)

I don't mean the community to flood him with corrections (that would be hostile), just for one or two people sufficiently familiar with the protocol to help me get SSB and git-ssb recognized as P2P. Any volunteers?


That's a good article. But it doesn't understand git-ssb. It puts git-ssb in the category of running your own git server over git or HTTP protocol, and says that git-ssb uses an Unpacked strategy. This is the case if your only interaction with git-ssb is via a public git-ssb-web gateway, e.g.

A new system that would fit in the client-server category is git-remote-gemini.

Originally git-ssb used an unpacked strategy, but early on switched to using git's Smart Protocol. git-ssb stores repo data in immutable content-addressed packfiles. When you push to a repo, git-ssb takes the packfile received from git and adds it as a ssb blob, along with an index file for it generated by git; then it publishes a message to your feed with the ref updates and linking to the packfile blob and index file blob. When you fetch from a git-ssb repo, git-ssb queries your ssb-db for git-update messages for that repo, uses the message data and index file data to identify which packfile blobs are needed to fulfill the request, fetches those blobs, merges the packfile data online, and passes the result to git. So it is like on-demand packing, although the packing is mostly a passthrough of the existing packfiles (pull-git-pack-concat). When you browse repo data using git-ssb-web, git-ssb-web similarly searches for git objects and reads them from the packfile data to build the web page responses.

The code for the unpacked strategy, although no longer used by git-ssb as such, is still in the library pull-git-remote-helper that git-ssb uses. This library is also used by hypergit and mango (another P2P git system, last active apparently in 2016).

The way git-ssb-web operates as a git remote does use the "dumb protocol"; there is a TODO to fix this: %+l2Zwl7.... git-ssb-web as a git remote is primarily for its use as a gateway server.

The 5MB limit is for each packfile, not for files in a repository. 5MB is the default blob size limit of ssb-server/ssb-blobs. Peers may increase that limit, but resulting large blobs will only be received by peers that also increase the limit accordingly.

The use of public gateway servers should not obscure the peer-to-peer nature of git-ssb+ssb-server. IPFS operates public gateway servers. hypergit has a web UI but I'm not aware of any public instances. I have not seen the other P2P git systems having web UIs or gateways.

SSB itself, rather than having a set of bootstrap or tracker servers, has dozens of public nodes (pubs), and hundreds of user nodes (peers). Peers connect to eachother based on their social graph and network reachability. Data flow is based on network connections and the social graph. There are trade-offs for applications: for example, to find a repo's latest state, you need to replicate the feeds of its author and contributors. If you are a new user, you need someone to follow you for your feed to be replicated by other peers.

Another P2P git thing: git-airpaste. Kindof a proof-of-concept; only works between two users on a LAN.

The article should mention that igis-remote and ipld-remote use Go, not Node.js. Also there is apparently a typo where hypergit is called HyperDat.

If Daniel would like to connect with SSB, I am happy to provide a pub invite.

@Jackson de Jesus

... if you couldn't convince him, maybe just @andrestaltz even.

@Alexandre Oliva

my difficulties are mostly related with my lack of knowledge of details of the protocols. I have some intuitions about it, from observed behavior and from stuff I've read over my time around, but I've never got down to the details.

another difficulty is that the author keeps going back to the notion of pubs as different, very special and essential entities in the network, as in necessary to mediate all non-local communications between other peers. I don't think that's how SSB works, but our docs seem to be readable in a way that supports that notion. it might be beneficial for people who actually know the protocol and the docs to get in touch with that person to figure out what drives them to this IMHO incorrect conclusion, so that we can improve our own docs.

@Alexandre Oliva

thanks, @cel , for the data. I'll pass it on.

Daniel claims to have tried SSB before, but not feeling comfortable with a permanent record of personal data, so I guess he's not coming back.

@Alexandre Oliva

I just went through and I can see why Daniel would have come to his conclusion.

There is indeed no hint at how one peer might find the address of another, except for pub messages in streams, that would presumably only name other pubs.

I thought addresses, even transient ones, were recorded from direct connections, and passed on by gossiping, but there doesn't seem to be any hint of how such data might be passed on to other peers. Help?

User has chosen not to be hosted publicly

@lxoliva peer addresses are discovered from pub messages and the LAN (UDP broadcasts). There is not really any gossip of addresses other than that - besides Manyverse DHT and people sometimes swapping gossip.json / conn.json files. Addresses from direct connections are not generally recorded.

I think there might have been a WIP for gossipping peer addresses a while ago, but I don't remember what it was called.

@Alexandre Oliva

hmm, this means he's right that there's no way to discover remote peers, you always end up going through pubs

but then, how come my node managed to start a direct connection to e.g. @cel-desktop , that I didn't even know about a couple of minutes ago? surely it's remote, not a LAN-recorded address, and presumably it's not a pub. does this mean it has a fixed address that you (or someone else) announced in a pub message?

I believed there had to be some way to discover addresses, since I often see my node connected to various peers that AFAIK are not pubs. I think some of the connections are even incoming connections, though I've never published my address (I'm on a dynamic IP, behind NAT). per what you say, all of my guesses and assumptions were wrong: they have to be outgoing connections, and they must be recorded in pub announce messages, even if they're not pubs proper, so they'd better be fixed addresses.

which suggests the article author is right, after all: SSB does not have peer address discovery: if your address is not announced in someone's message stream, nobody will be able to connect to you, unless they happen to run into you on in a LAN, or if both parties rely on Manyverse's DHT. it's only P2P for peers with pub-announced addresses; anyone else must rely on the mediation of a third party with pub-announced addresses for communication (again, with the LAN and DHT exceptions).

I'm not sure whether the distinction is relevant, but the author seems to assign it great importance.

thanks for setting me straight! I'll pass it on.


Yes, I published a pub message for this id, here: %+kJmq/h...

Also I forgot to mention rooms. A peer can connect to a room server, and then connect to other peers in the room or receive connections from other peers in the room. Room connections are relayed/proxied through the room server, but are still end-to-end encrypted with secret-handshake.

It has been theorized that peers could negotiate a peer-to-peer (IP to IP) connection via a room connection, but I haven't seen that done yet.

Current room client implementations I think only connect to rooms that have added by the user specifically, rather than connecting to random servers like some do with pubs.

Join Scuttlebutt now