Your opinion about a new gateway of SSB

I am a big fan of SSB and I believe sooner or later it will serve billions of people. I prefer sooner and what to speed it up a tiny bit with what I can do. Therefore, I am building another simple public gateway of SSB content as a static site. There are two main purposes: first is to attract more people to use and build SSB (e.g. blogging, building more apps, finding more ways to use SSB), and the second is to help new users find interesting people to follow easily. The website is almost done and the only thing left to decide is how to deal with the publicWebhosting settings. Currently there are over 20000 feeds on SSB, 1284 feeds set it as true and only 55 feeds set it as false. The majority have neither set it as true nor false. On the safe side I'd better follow the same practice as viewer.scuttlebutt.io and only show the feeds who have already set 'publicWebhosting' as true. However, this approach will make the website much less useful to achieve the above purposes and also in my opinion discriminates against those who are not tech savvy as currently few clients support setting publicWebhosting easily. Therefore I would like to hear your opinion on what is the best approach. Should I display the feeds who haven't set publicWebhosting for the moment until setting publicWebhosting becomes easy?

#scuttlebutt #ssbc

I think public gateways are great, and we should have more beautiful/polished ones.
But I also think that they should be strictly opt-in, as they are now.
In fact the opt-out that you, @entron, describe used to be the default and it was intentionally changed to an opt-in.

If you want more than "this is how it was decided" though, here's what I have to offer: I think the mistake you're making is equating growth in number of users with success. Currently, ssb "kinda works" and yes, we could use many more devs. But ssb is not just a protocol/technology; it is also a community and a culture. "Growth-hacking" our way into the mainstream might actually kill the project dead, simply because what is currently implemented is not built/able to deal with the issues that come with that. Think moderation, regulation, censorship, ...
One rule of thumb a friend used for this is "Growth at the rate of trust." We need to build ssb to serve those that currently use it. Our resources are constrained enough for that. We really shouldn't be spending our (spare & rare) time on things that would only attract & serve people who are (currently) perfectly fine with how facebook & twitter work. They'll come around sooner or later, we don't need to be aggressive about it.

That being said I also think/hope that ssb will one day serve billions, and it would be amazing to have a static-site kind of viewer. Technologically very cool and given the size of the dataset probably hostable on a pi zero? 😀

Do you mind sharing a bit how you're going about it? Language, framework, design-wise? When new messages come in, do you re-generate the whole thing, or can you identify the thread/profile/channel pages that need updating?

Based on the feedback I will follow the opt-in way. I initially thought unset means "doesn't matter" or "not important maybe I will decide later" at least that was my reason. Obviously I was very wrong:) Thanks @moid, @sunset 19:36.

@Daan you give me a fresh angle to think. Indeed I agree with you bigger != better and faster != better neither. "Growth at the rate of trust" probably will not be very popular in a board meeting but I enjoy it and I will take it in mind when I build for SSB. Ideally there are two kinds of people I wish to bring in. One is people like you who share similar beliefs and who also would join the dev. Hopefully they will ease the resources constrain problem you mentioned and they will find a home. Everyone will be happy. The 2nd kind is more personal as I have a science background. I want to bring scientists here. The immutable feed history is perfect for scientists. This is the reason I will support latex in the website.

The tech part is hardly cool:) Many people here probably can redo it in two weekends and in a better form. I used hugo as the static site engine and python for other parts. I have close to zero knowledge in html, css, java-script and my design taste will not help me either. Therefore the look and function of the website itself is minimized and probably very boring for many. Also I want people to really use SSB clients rather than my website. I intentionally did not implement many functions which can easily achieved with clients of SSB.

I use google cloud for serving the content but I think one can also serve with a pi. The resource consuming part is hugo building as hugo is not targeted to big site yet. I tested for all current SSB content of 20K feeds and one needs a machine with 30GB RAM currently. Hugo also does not support incremental build so I have to regenerate the whole thing when new messages come in. Therefore, I plan to only update the site daily at least for the moment to reduce cost.