Me and @Hiure have been exploring #ssb-browser and "client-server" solutions for using SSB on local community contexts. Why would we want to go back to client-server?
Well, many users in the communities we live have such old devices that even ssb-browser might be a problem (we need to do more actual testing). Another thought we had was that it's better to encourage people to share buying single-board computers then better phones. The client-server architecture also gives the UX that most users expect to have.
Like #cashless we've started exploring the #feedless way of running SSB completely on the server. @rchaves created his own publishAs method, which is completely different from @Dominic's ssb-identities. It consists of passing an id's secret to the function, which then uses
ssb.getLatest to get a feed's "latest state" and uses it to
ssb.add a new message to the database.
I like this way as it keeps things simple, the db is kept safely on the pub machine. We can have different pubs following each other to create more data redundancy. This way we'll be using SSB more like a federation of pubs then p2p. But we're looking for a progressive experience where every type of device (including a Kindle) can participate, and as data-awareness happens a person can progress to having more responsibility over their data.
But feedless has gotten outdated, so I'd like to achieve something similar using ssb-db2 and ideally #ssb-crut as well. But when I tried migrating the publishAs method to ssb-db2 I got a warning stating that I shouldn't use
ssb.add this way as it's risking a fork. Makes sense but... Is there a better way of achieving this? @arj @andrestaltz