This presumes that recruiting new users is a priority.
yeah, as a developer it's quite frustrating to sink hundreds of hours into trying to make something better, only for it to still be terrible! i'm pretty sure all the ssb developers i know would agree it's a problem worth solving at the moment, as it's talked about a lot by both new and old people here, most of us are just stretched thin with all the things.
i'm actually hopeful that @dominic's recent upgrade to muxrpc
with backpressure might solve the fundamental problems with pubs, good code is hard!
i'm also loving what @Aljoscha is doing with the rust implementation, wow that's a lot of amazing work!
what i've done with ssb-pub
(powering @one.butt.nz, @ssb.rootsystems.nz, and @ssb.mikey.nz) has proven to not be enough, my pubs are still finding ways to crash without being restarted.
i also echo what @rich said, i've come to realize that ssb's high barrier to entry has been a feature not a bug, it's had the effect of creating a strong boundary for our solarpunk community to grow in a nurturing environment.
I did even consider hosting an ssb pub server just so that next time around it isn't such a hassle.
Is there an easy tutorial for that?
@inoas your experience of struggling to get in, then thinking 'I better do something to make it easier' is in my opinion, an ideal case for recruiting the kind of people that are most useful to the SSB community right now
Even when the UX is extremely smooth and hassle free, people still are likely to have a bad time here unless they come with a motivation to contribute, share their interests, and learn together. (Notice this is v different from most folks experience in popular social media spaces, where I expect to have my attention farmed and groomed until I am placidly zombie-scrolling and occasionally signaling to check I'm still in the appropriate filter bubble.)
I'm not advocating for buggy UX, but I am in favour of anything that guides people to arrive with a contributor's mentality.
I mean I believe SSB needs people working on hard problems like pub uptime more than it needs people confirming that pubs are flakey.
this is related to a conversation i was having with @dominic about having a dashboard that lets you see the health of your connections and pubs.
he's already been collecting stats for this in the command sbot status
lol at anyone suggesting that being buggy is a good thing, or that we don't want to be accessible. I want ssb to work well because I want it to make a difference in the world.
If it works well, we can create artificial barriers if we choose to. If it doesn't work well we arn't choosing those barriers.
Oh, also I wrote a script to test which pubs are currently active (metric: can I connect to them)
The good news: there are ~300 pubs (okay look like they regenerated a new key, etc)
The bad news: I was only able to actually connect to 25!!!
Well, ssb is a well designed but poorly implemented distributed system. It's highly robust in the face of massive failures! It's way more important for a distributed system to be well designed than well implemented, since errors will happen in the well implemented system too, withstanding errors being the main criteria for being well designed.
That 300 people have started a pub is actually pretty great, but I think the problem is that most of them didn't run it inside a restart loop, etc. We could probably fix this by say, building that restart loop into sbot pub command, and or hooking into what ever start up services the OS provides. (not that hard since most servers are just gonna be ubuntu) but this is one of those medium size tasks that exist in the minds of people too busy to do them, because we have no better way to track them.
The other problem, is that current replication is unscaleable (it was appropiate at the time, but not anymore!) so whenever a peer connects it makes possibly thousands of requests for feeds that mostly probably havn't changed. Okay, I'm gonna stop writing this and start actually figuring out what I need to finish up to deploy ebt.
@haileycoop asked
And how does a decentralised self-governing social network project set priorities anyway?
by people pitching in and doing stuff that helps achive that. Making ssb more scalable and efficient is my personal priority. If you value that, then please look for a way you are able to help, then help in that way.
Just chipping in to say I just deleted my .ssb folder & haven't got a functional back up (I'll write about that in a separate post).
I ran through the canonical guide: https://github.com/ssbc/patchwork which links out to listed pubs here: https://github.com/ssbc/scuttlebot/wiki/Pub-Servers
The only pub which worked was:
ssb.ekata.social, run by @mashiweirk and Base48 Hackerspace
I wonder if there is a way of making a standard ~/.ssb/gossip.json
available so that people can join with a client which has a little more info to get started with...? Thinking out loud here. That might well be a horrible idea from a privacy point of view.
True, someone would need their pub key for that to be useful...