Maybe to moderate expectation here though: running a pub currently is easy, but setting up web invite generation requires mild webdev experience (at least I don't know any prebuilt solutions) and moderating the pub itself (i.e. blocking unwanted feeds and such) requires dropping into the commandline.

Hi @Giulio Prisco, no problem. The follow and replication mechanisms are indeed not the easiest. :P

I'll start by explaining the replication mechanism in a few more words, and then I hope answering your questions will be easier at the end.

Which feeds are replicated, and what does that mean?

By default, your client will replicate the feeds you follow, and all the feeds that they follow. That is, whenever your client can get its hands on their updates, it will store them, ready to be displayed to you and forwarded to anyone who asks.

To do so, your client will contact any peer it thinks might have such updates, if it can reach it. If the clients are on the same WiFi as you, that's easy. If you are on different networks and cannot establish a direct connection, then someone has to "bounce" the information. This task is solved by two different mechanisms at the moment: pubs and rooms.

What is a pub?

A pub is "just another ssb peer" once you speak to it, but it is different in some ways before that:
First, it announces itself as being a pub. Here is the message that my pub made.

{
  "type": "pub",
  "address": {
    "key": "@93JiSXW2dUogOnNJADVGKkNAjZJ1whw7nU0r/VIL1zE=.ed25519",
    "host": "muchmuch.coffee",
    "port": 8008
  }
}

As you can see, this is mostly just an invitation to talk. Anyone on the internet can connect to it it with the information in that message and exchange updates. The info needed is of course the address and port, but also the ID of the feed, because the "secret handshake" protocol that is used to exchange updates requires the "caller" to know the ID of the "callee". Of course, if you see this message on the pub's feed, you already know its ID, so that's quite redundant here.

The second way that pubs differ from other peers is that they usually distribute invites in some way. Some pubs do so with a web interface where you can copy the invite or scan it as a QR code. Others even put the invite in their own profile description here on ssb. Yet others are "private" pubs (like I happen to run one) where invites are handed around by hand, just to facilitate the replication of feeds I'm interested in.

What does "accepting an invite" actually do?

When I use an invite to join a pub, your local client will request the pub to follow me. This is called "accepting an invite."
Once my client sees that the pub is following me, it will publish two messages, in this order:

{
  "type": "pub",
  "address": {
    "host": "muchmuch.coffee",
    "port": 8008,
    "key": "@93JiSXW2dUogOnNJADVGKkNAjZJ1whw7nU0r/VIL1zE=.ed25519"
  }
}
{
  "type": "contact",
  "contact": "@93JiSXW2dUogOnNJADVGKkNAjZJ1whw7nU0r/VIL1zE=.ed25519",
  "following": true,
  "autofollow": true
}

Whether the second message is a good idea is the topic of some debate, but for now at least patchwork does it like this. It simply follows the pub, meaning that now everyone who used an invite on this pub will be in my "two hops" distance. This means that my client will immediately start downloading all the feeds of all the people "on" this pub. Depending on how many feeds those are, that can keep my machine busy for quite a while, and pollute my drive with a lot of unneeded or even undesirable data from perfect strangers. Hence the controversy.

But the first message is actually more important here: it announces to anyone who can see my feed already: "Hey, if you need updates from me but cannot reach me directly, here's a place to get them that should be reachable most of the time." And here again, you see the address and port, and the feed ID of the pub. This time around this is actually super important, because as I said before, the feed ID is needed to establish a secure connection to the pub.

Now, let's say you follow my feed. You probably have some reason to do so. Let's assume for now that you came across one of my posts in a thread or such. In this case, the moment you follow me, you already have a full copy of my feed up until now, including that first message announcing that "pub X follows me." Your client can now connect to my pub anytime it wants and ask for updates.
However, if your reason to follow my feed is that someone on the web told you to install patchwork and paste my ID into the search bar, you may well end up in the situation I described before: an empty page of a feed that you follow, but your client has no way to retrieve the data of my feed. This is because without my feed being stored locally, there is no indication as to which publicly-reachable peers could give you an update. To resolve this situation of an empty page, there are currently three possibilities:

First, your client can contact a pub that replicates my feed for some other reason than my feed. The replication should work even if your client has no idea that this pub replicates me, and just contacts the pub to get updates on some other feed where it does know that this pub will have updates. In that case you'd get all updates for my feed from the pub and that's it, from then on your client knows that it can get my updates on that pub (and potentially other pubs that are also announced in my feed).

Second, you could be on the same WiFi as someone who has my feed. In that case, connecting to them is easy, and again you'd download my feed, then be aware of all pubs that replicate me.

Third, you could be in the same room as someone who has my feed.

What is a room?

A room, like a pub, is usually publicly reachable on the internet.
To "get into" a room you will use a similar invite mechanism as for pubs.
However, the room will not follow your feed, and so your client will also not announce the room with a message. Your client and the room server simply both make an internal note that yes, you successfully entered the room and are authorized to do so again at your convenience.
The room now simply works as a relay. It "simulates" being on the same WiFi as other peers in the same room. So they become "possible connections" in your left sidebar in patchwork, and you can click to connect to them. If you do, the gossip exchanged between you and those peers will pass through the room server, allowing you to connect even if you're both behind NAT or such. From there the replication happens as before: once you connect, your client asks if the other side has any updates on the feeds you follow. "Oh yeah, there's this feed @MRiJ+CvDnD9Z... that I'm following, but I'm at sequence number 0." "No problem" the other side says, "I'm at sequence number 5466, here , take the whole load."
And from that point on your client will also know all the pubs to connect to.
Crucially, while all this gossiping passes through the room server, the server itself can actually not read any of it. It simply shuffles encrypted bytes back and forth between your client and the other side.
Also, in addition to getting the list of all pubs, your client will now know that that other client replicates me, and is reachable in that room. So it can go back to that room anytime and if the other side is online too, then they can exchange updates again.

So I hope the replication is now a bit clearer. Sorry it got so long, I just kept going there. But I hope we're now able to easily answer your questions:

What happens if I stop following all the pubs that I am following?

The short answer: probably not much. This is because the crucial bit is that they still follow you. Your followers will still be able to get updates from these pubs, as long as these pubs somehow get the updates. But assuming that you follow at least one feed who is replicated by one pub, the odds of that are pretty darn good. In fact, if your unfollow all pubs, you will now only replicate the feeds you follow and their friends. "Their friends" (the second hop) may include some pubs, and so you would still replicate those pubs' messages. But those messages are nearly all "I now follow @X" type messages, don't take up much space, and are actually quite useful to figure out where to get updates. But after unfollowing all pubs you will no longer replicate the feeds they follow, except of course if those feeds are in your two-hop distance anyhow, because either you or one of your friends follows them. This will easy the computational & storage burden on your machine and is one of the reasons for "keeping the social graph clean" as people call it. Meaning: don't create artificial follow messages (from/to pubs) that cause unneeded/unwanted replication.

The second question you had was roughly this:

Is SSB really decentralized if we rely on pubs so much?

At the base, the answer to this has always been: yes. Simply because it would work on wifi, so no pubs are strictly needed.
However, with a global ssb community that doesn't hang out in cafés all the time (especially during a pandemic) pubs were practically necessary before we had rooms. But even then, a single pub operator could not decide to block your feed anywhere else but on their own pub. If you had 10 pubs replicating you, all ten would have to be taken down to "silence" you, and even then wifi transmission would still work and there would be no reason you couldn't use any other pub.

With rooms, this has become even easier to defend, since the rooms don't even store & forward data. They're essentially just glorified NAT traversals.

And this is not even getting into the possibilities of exposing your local client via #tor or #yggdrasil, making it reachable by anyone from anywhere.

So yes, SSB is decentralized.

@Daan, tell us more about #tor I see two possibilities:

1. I connect with torsocks (only) and then no one knows what IP I connected from. This prevents external agencies from linking my posts to a fixed IP addr. All my gossip runs through the torsocks; from the point of view of the rest of the network, its as if my client was running on the tor exit node.

2. Someone suggested that one can set up an .onion address and somehow link it to my identity?

   "address": {
    "host": "asdfasdfasdf000000.onion",   // my onion address
    "port": 8008,
    "key": "@KswLLKHtpKd0Nay95TEmH4vKLYbOMkS6Co716pddmWI=.ed25519"   // my public ID
   }
   

   Thus, all gossipers will try to reach me there? If I'm offline, that clearly fails, but if I'm online, then the connection succeeds!? This is useful if I was running a pub, but I see no advantage over 1. if I'm just running a "normal client". (There's large disadvantage: you can't have an onion address unless you run a tor node, and that requires RTFM'ing and stuff.)

@Linas I have personally never gotten into those. But yeah, essentially making your local client into a "sort of pub" with the address being a tor or yggdrasil one.

requires RTFM’ing and stuff

If you're in the position to need tor, you really should RTFM for your own good. It's easy to get stuff wrong and end up leaking info to the clearnet. I know, not ideal, but I'm in no position to change that. 🤷 And I don't even really know what yggdrasil is. 😝

This is useful if I was running a pub, but I see no advantage over 1

True. Mostly it's useful as a counter argument against people saying that pubs centralize ssb. 😛
At the base, doing this is just another kind of NAT-traversal, but also it means you'll never have to publicly announce to the internet that you're doing ssb, and combined with tor bridges you can really gossip undetected.