You are reading content from Scuttlebutt
@andrestaltz %hRnKqCwnTyvLbIhljJSCXZXaYx332NOmxZi3ApbFkF0=.sha256
Re: %/qbAfJ5ZK

100 scuttlebutt apps. Can you tell us why that is a goal? What do you hope it will achieve/ unlock?

@Mix It would help SSB grow in a healthy manner. SSB could grow as a product of Manyverse and/or Planetary growing, but the result would be a bottleneck, a sort of "centralized" situation where all responsibility falls on the shoulders of few. And since responsibility=power, it would also mean that power lands on the hands of few. In other words, I want SSB to grow, but in a decentralized manner. Decentralization means freedom to choose, freedom to migrate/swap, etc.

To be fair, I do want Manyverse to grow, but I don't want it to be the only (or one of the few) SSB app growing, I just want it to be the "SSB beginner's app".

If you look at the simplicity of creating web apps, that aspect of the web is healthy because there is growth and decentralization. On the other hand, the complexity of creating a web browser means that this aspect of the web had unhealthy growth because so many things are dictated by Chrome (Google) which hurts freedom of choice.

why db compaction before a2a? I am guessing you worry that a proliferation of apps means our dbs will fill up fast, but I don't feel that

I absolutely believe it would fill the DBs fast. I think you need some numerical convincing of this fact, because it's not something to "feel", it's something to measure and to prepare for before it starts happening to everyone.

For instance, on onboarding, we already experience OOM crashes due to lots of different (large) indexes being built simultaneously. Dominic got that with Manyverse on desktop, I'm curious how much RAM he has. My computer has 16GB and I've never gotten an OOM crash on Manyverse during onboarding. So let's assume he has 8GB of RAM, and that it's a fairly usual computer. That would be consistent with other reports of Manyverse mobile crashing on phones with 4GB or 8GB of RAM.

Enabling partial replication for common content (such as votes, posts, contacts, abouts) is paradoxically going to use up more storage, until we get sliced replication. And introducing sliced replication only makes sense if we also have deletions (in a ring buffer style) and db compaction. So assume you don't have deletion and compaction in any manner. vote / post / contact / about messages are roughly 75% of all messages according to this study by arj. "Partial replication" of those in practice means enabling index feeds. Index feeds means that for each vote/post/contact/about message there would be 1 index message published. Index messages are small, but they are still conventional SSB messages, probably the same size as a vote message normally is. So take the existing 1GB log and add +75% to it and suddenly the log is now 1.75GB large. That would cause it to get a OOM crashes more frequently. Add to that some new messages from new apps, and it would get a lot larger. I mean, I'm thinking 100 apps, not just 3 or 4 new apps. Some of those apps will be naively publishing messages (and rightfully so, because naive is often the most approachable for beginners and people just experimenting/getting-started with SSB, which I want to see more often). It only takes one naive app to publish a ton of content for your database to get full, and I'm only talking about OOM crashes, not yet about the hard limit of 4.3 GB.

I don't want to encourage an ecosystem of apps to build on a foundation that is going to crash soon. It would stain our reputation as a non-foundation for apps.

Join Scuttlebutt now