#ShowerThought the great weakness of federated social networks is the dependence of accounts on individual instances. Even in #Zot networks, where #NomadicIdentity can be used to clone 'channels' across multiple instances, users have to understand how to set up clones, remember which instances their clones are hosted on, and hope at least one of those instances still exists if their primary instance vanishes, never to return. (1/2)
What if we could create a single server "cloud", to which anyone could contribute storage and processing power? All accounts exist in that "cloud", rather than on any given droplet within it. There could be multiple ways of contributing; dedicated VPS, desktop apps contributing processing power when connected, mobile apps when plugged in and on unmetred data, SETI@home style tools that contribute unused timeslice etc. My understanding of #HoloChain is that this is their goal. (2/2)
@teaneedz I think that would be essential to making the system socially and legally practical, yes. #Jami is an example. My understanding of the way it works is that by running a Jami client, I am contributing timeslice to the distributed computer that helps users connect with each other (and maybe even routes call data). But I can't see anyone else' communications over Jami and I'm not responsible for their contents or consequences (morally or legally).
@strypey I didn't see enough info on their website to understand their encryption implementation other than brief verbiage related to text messaging. Not saying it's not a zero knowledge E2EE solution, but they need to spell it out.
@strypey yes, jami. If we look at true E2EE messaging, in the consumer implementation, there are just a handle of products existing and maybe only two I trust. It takes lots of attention to detail to get it right. Those aren't distributed solutions, but I wouldn't trust a new federated solution without the right team and skillset behind it.
@teaneedz the team developing #Jami has existed for more than a decade. It used to be called #GNU #Ring and is still part of the GNU project. It originally started as a SIP client called #SLFphone. Given that the routing is serverless and relies on other clients, the design must aim for zero knowledge #E2EE. Auditing the implementation of the encryption, and whether it achieves that, is definitely above my paygrade ;)
what can users can do? Install apps on all your devices and keep them running, promote your Jami username on your homepage, user profiles etc, help other people install and learn to use it, suggest it any time anyone wants to voice/video chat with you, give UX feedback to the developers, to help it become more user-friendly, encourage other #FreeCode chat apps to implement the Jami protocol, at least the voice/video part, so their users can chat with Jami users.
> This is a conundrum for p2p communications
... with devices that depend on battery power. True. Although I think it has as much to do with the efficiency of subsystems that handle things like push notifications as the apps themselves. I suspect grown-up GNU/Linux coming to mobile devices will lead to improvements in this that aren't possible with kindergarten OS like #Android.
@AmarOk @nurinoas @teaneedz
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!