This post on the #Jami blog highlights some of the ways users have to manage #P2P apps differently from those that depend on servers:
https://jami.net/the-jami-quirks/
@strypey great necessary article that is relevant to many decentralised technologies. Very important to spell it out like this for users. I really appreciate the solutions that the Jami devs come up with, and how easy they make for users to use them. For example, I love their solution for decentralised group video talk: one user becomes the server, which can be decided by the group beforehand considering their bandwidth and computing power, I guess.
@strypey it’s an interesting idea. I wonder how it handles that at the moment. I learned about it in this post I think: https://jami.net/free-as-in-freedom/
@stragu there's been a number of major updates to Jami since we ran our test, including making their update repo more accessible to @trisquel users:
https://jami.net/download-jami-linux/#open-modal-triquel-8.0
I'm keen to run another #VOICE test of Jami voice chat to see if the UX has improved, ideally with a few more people (5 or more), to see how well it scales. Anyone keen? We currently coordinate using:
#voicechat:matrix.org
@strypey I’d be happy to help, depending on availability! See you on Matrix.
@stragu
> one user becomes the server
This wasn't made clear by the UI when the #VOICE group tested Jami. It would be better if the subnetwork formed by a group chat could dynamically assign the server role to the most powerful node (factoring in both computing power and available bandwidth). That would allow the person who started the group chat to leave without everyone else having to start a new one from scratch, to keep talking.