%/qbAfJ5ZKKz57a/BWIU2YxGtQNNdeLd+DblQ1aj2X1I=.sha256I tend to make the strategy for Manyverse clear (see roadmap), but my strategy for SSB is slightly different. Instead of boring the reader by repeating my thoughts on Onboarding, Sustainability, and Safety, I'll try to share my vision for SSB that is necessarily not Manyverse.
Of course, there is some overlap. Lots of goals that are part of Manyverse will directly benefit the SSB ecosystem. For example, in the past: ssb-conn, rooms, ssb-blobs-purge, ssb-keys-mnemonic. And examples for the future: onboarding via broker auth or something similar, etc.
So let me talk about the non-overlapping goals.
First, I really would like to see a hundred apps thrive on SSB. I don't want Manyverse to suck up all the possible use cases. I think diversity is rich and sometimes you need to break away from the constraints of "a normal social app" such as Manyverse, to build wild things. I myself have a handful of ideas I'd like to build. I can't wait to see what else people build.
So a hundred apps. 100 is just a symbolic number, but it also means that a lot of things have to happen before we can see such thing happening. Developer experience has to improve, etc, but I think biggest of all is that app-to-app interop has to be seemless, has to "always work", has to never become a source of headaches, and has to be well specified and documented.
One hint towards that direction is my opinion that apps should not share the same database. The common flume database used to be the primary point of interop for apps like Patchbay, Patchwork, Oasis, etc. This way of interop has been tough already with just a handful of apps, they constantly stepped on each others toes indexes, imagine then with 100 apps. Removing the common database from the picture means there has to be something else, some other convention for sharing data. I believe that convention should be something I call "A2A" (app-to-app), which is just a fancy way of saying that apps should connect to each other just like normal peers connect to each other, and then there should be some authorization flow (this is what broker auth is) to allow app A to get special data from app B (such as the social graph). It doesn't have to be broker auth necessarily, it can also be shs2 so to allow LAN A2A.
Unfortunately, we can't just build A2A today. Well, not without creating a bunch of headaches. So I propose we solve those headaches first, and then it'll enable building A2A in a proper manner, allowing apps to be created easily and without freaking out developers.
To repeat a blob I shared before, notice "Cross-app bootstrapping":
The dream of several apps on SSB was revived during our #ssb-ngi-pointer project when we realized #metafeeds would be great not only for partial replication, but also for app-dedicated feeds. This way, when you play chess with friends, you can replicate only chess feeds, not all the other stuff. If you are not interested in chess, then you wouldn't replicate it, because you wouldn't even have a chess app.
But you should still have a way of tying all these feeds together. You would have "subfeeds" (created hierarchically) for apps on the same computer, such that they all point to a parent metafeed. But you could also have "side feeds", i.e. #same-as for linking desktop feed with mobile feed, etc.
#metafeeds is a way of linking feeds hierarchically, and #fusion-identity is a way of linking feeds horizontally, in other words #same-as. These two aren't ready for production yet, and that's something that needs to be worked on before we get to "cross-app bootstrapping".
And before we can put metafeeds into production, we need database compaction in place, for reasons I already shared before.
So my strategy for this year is summarized in the graph chart I shared above.
Hope this resonates!