Patchwork: Default gossip file

[christianbundy]

New user experience sucks because you can't even see any content until you've redeemed a pub invite and really there's no reason we can't just include a gossip.json with some of the most stable pubs. This would let new users see pubs, follow them, and at least read content even if other people can't see them.

[Powersource]

I see your point and I don't mind the centralization too much (e.g. we already recommend pub servers on the wiki) but idk. And idk if this would improve the ux very much, especially compared to adding e.g. peer invites.

I have a feeling @staltz has more elaborate opinions on this than me.

[staltz]

New user experience sucks

This is true, and we need to find solutions for it (PS: I'm currently working on building SSB rooms to solve these kinds of problems), but including a default gossip file is an easy solution in the short run but a seriously problematic in the long run.

really there's no reason we can't just include a gossip.json with some of the most stable pubs

I'll give 4 reasons. The scale reason is the most practical one.

Scale. If suddenly 100k people download Patchwork and start using it, then I believe that all of the current stable pubs would suffer and crash. If 100k is a too hypothetical case, then we're not building SSB to truly scale. Moreover, if pub operators would decide to scale up their pub infrastructure, then we're talking about building complex infrastructure that is both difficult to operate as well as important to operate correctly. This is centralization, and a few years after that we'd be running essentially a centralized social network.

Privilege. Another problem with a default gossip file is that this would immediately create a two-tier system where some pubs are "official" where other pubs are not. This is problematic because: (1) people starting new pubs would have difficulty promoting their pub to "patchwork default" status, (2) default pubs that no longer exist would have to be purged from the "default list".

Off-grid. Patchwork so far has been working great as an offline-first app, and this is not just hypothetical, there are people in Cuba who do not have internet connection but are beginning to use Patchwork to communicate between themselves and with the outer world. It does not make sense for these Cubans to experience Patchwork automatically making outgoing connections to a bunch of hosts they don't want to connect to. In another scenario where people have internet connection but are constrained by a small limit for bandwidth, they want to be able to control how their software makes requests to the wide internet. If Patchwork connects only to a specific pub that they set up, that's good, but if it connects to 10 pubs with gigabytes of data, that's very bad.

Community boundaries. We (people in this thread and extended friends-of-friends) already know of "bad" groups and persons that are using Patchwork to communicate between themselves. If new "bad" users join by using Patchwork, we would have difficulty blocking them from interacting with us. It would be contributing to increase the "rando problem", not decrease it.

What we need to do instead is increase the ratio of servers/user, and this is done by making it easier to start and maintain a server. We also need to consider all sorts of solutions for onboarding and friend discovery, I'm open to discuss this carefully and thoroughly, but I think there are certain precious qualities of SSB that we need to protect. Design of decentralized systems has to be done very carefully, with the opposite of "ship fast" mentality, because once something is built and published, it's very difficult to revert decisions. For instance, I wrote one kind of server solution and gathered feedback, but ultimately decided to not publish it publicly because if it were deployed at a decentralized permissionless scale, it would have overall negative consequences, and it would be irreversible.

[christianbundy]

Thanks for writing up that response. I feel the same on all of these issues, I suppose the difference is that I don't see any material difference between maintaining a "pub registry" on the SSBC wiki and just shipping those within the app.

The status quo is that we're depending on a few official pubs for new users to connect to, which does have huge issues with scale + privilege + community boundaries, but I suppose doesn't have bandwidth considerations since you can choose to only connect to one pub. I'm not very excited about pubs in general, and I'd much rather have a system where peers can directly connect to each other without the need for a public IP (discovery-swarm?), but it seemed like an easy win to get new users connected without having them click through our wiki.

If Patchwork connects only to a specific pub that they set up, that's good, but if it connects to 10 pubs with gigabytes of data, that's very bad.

I think this brings up a good point, if we have some some starter gossip file with a list of known peers then it should be opt-in only.

[staltz]

The difference between the wiki and a default gossip file is that the wiki is much easier to update than the gossip file, and for people distributing patchwork manually (e.g. USB), that gossip file would be potentially outdated. The update of the file is delayed according to the releases of the app.

PS: it seems like you're assuming those pubs are open invites. I regret helping to make open-invite pubs, I think the best way for Scuttlebutt to scale is for users to invite new trusted users.

[christianbundy]

that gossip file would be potentially outdated

Yes, but the worst-case scenario is that all of those peers are offline and we're back to the current situation where new users can't peer with anyone at all. The worst-case scenario is the status quo. I think this would be especially for people who are restoring their secret from a backup but have no gossip.json, since you can't use a pub invite without bricking your feed.

Maybe a better alternative would be to subscribe to a discovery-swarm where pubs can announce their address while they're online? This would solve the "users without gossip.json can't peer with anyone" problem without hardcoding anything in the client (although I have a nagging feeling that most DHT implementations hardcode some centralized servers too?).

[christianbundy]

I think the best way for Scuttlebutt to scale is for users to invite new trusted users.

I'm a bit conflicted on this, because I think there's some utility in connecting people with Scuttlebutt even if you don't trust them well enough to follow them personally. For example, it would be nice to have a token that, when used, introduces you to other people who used the same token. I'm imagining posting this on a telephone pole, a subreddit, a chat room, etc., where the people who see the code might want to connect to each other rather than just the person who posted the code.

Or maybe I've been spending too much time playing with Cabal... :wink:

[Powersource]

I have a nagging feeling that most DHT implementations hardcode some centralized servers too

Yeah every project that I know of that uses a DHT uses centralized bootstrap nodes to get the network started.

And afaik I don't think discovery-swarm uses a DHT by default (but as a backup), they have I think a bunch of central DNS servers/trackers that everyone uses. (hyperswarm is gonna use a DHT by default I think, but with bootstrap nodes of course)

[ahdinosaur]

i think a built-in list of bootstrap pubs is different from the list of pubs wiki page, because building the list of pubs into the app forces everyone to use the public pubs, whereas providing a list of pubs allows users to _opt-in_ to using public pubs. changing to built-in public pubs would force everyone to join the main Scuttlebutt community continent, rather than being able to be an island, and i think helping people create islands is far more important than helping people to join the continent.

[staltz]

I think there's some utility in connecting people with Scuttlebutt even if you don't trust them well enough to follow them personally

@christianbundy then you're probably going to like SSB rooms, it will help find and connect with new strangers.

I think a better evolution of linking to the wiki is actually two-fold: (1) linking to instructions how to set up your own servers, (2) mentioning a hashtag you can use across different social networks and 'places' where you can find random rooms and pubs.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?