add partial centralization warning for Jami

[lrq3000]

Description

Resolves: #1727

Changes:

• Add label warning that Jami is partially centralized
• Extend description to mention all communications are end-to-end encrypted, including through TURN servers if used.

Check List

• I understand that by not opening an issue about a software/service/similar addition/removal, this pull request will be closed without merging.

• I have read and understand the contributing guidelines.

• The project is Free Libre and/or Open Source Software

• Netlify preview for the mainly edited page: https://deploy-preview-1752--privacytools-io.netlify.com/software/real-time-communication/#peer-to-peer

[netlify]

Deploy preview for privacytools-io ready!

Built with commit a5f0541

https://deploy-preview-1752--privacytools-io.netlify.com

[lrq3000]

Sorry I didn't know the syntax for links in a label, now it's fixed :-)

[blacklight447]

The preview looks great so far, ill leave a review tommorow!

[Mikaela]

I wonder if there could be any clearer link

[lrq3000]

@Mikaela do you mean something like this? This is linked by the first reply in the issue I linked in the warning, so from the issue, the user can easily go there. I chose the issue because it's a lot less verbose and it specifically addresses how to workaround this issue (ie, how to self-host), whereas the blog post while being maybe cleaner only describe the issue without providing any solution.

[lrq3000]

Also I just noticed they say in the blog post that:

Furthermore, the data that users choose to share is always transmitted through entirely peer-to-peer connections, except when a TURN server is necessary. Even then, it is fully end-to-end encrypted and never stored elsewhere than on the end-users’ devices.

Maybe we should add that in the description (that it's always end-to-end encrypted)?

[blacklight447]

Also I just noticed they say in the blog post that:

Furthermore, the data that users choose to share is always transmitted through entirely peer-to-peer connections, except when a TURN server is necessary. Even then, it is fully end-to-end encrypted and never stored elsewhere than on the end-users’ devices.

Maybe we should add that in the description (that it's always end-to-end encrypted)?

Seems like a good idea to me.

[dngray]

I'd probably do this for consistency, seeing as we used "E2EE" elsewhere after explaining it.

[Mikaela]

Would it be possible to say in the warning what exactly is not decentralized?

[lrq3000]

@Mikaela Here is the list:

• push notifications
• the OpenDHT proxy
• bootstrap
• name server
• TURN

If you think it's not too long, I can add it in the warning.

[Mikaela]

Oh, I see, yes, that is too long. What would be the equivalent decentralized list?

[lrq3000]

Oh, tough question, I think that's still a topic of research. I think Session (Loki Messenger) implements workarounds for some of these:

• push notifications -> no real way around having a central server if phones aren't rooted, but what Session does for example is that the server is only used to regularly ping the phone and it's the phone which connects to the network to check if there are any new messages, the server has no clue (info from one of their blog post IIRC).
• the OpenDHT proxy -> federated servers (Riot) or onion-like nodes (future Session) or onion-like proxy nodes (current Session)
• bootstrap -> no clue, but I guess fixing the previous may also fix the need for a bootstrap.
• name server -> Alpenhorn (Vuvuzela bootstrapping and name resolving system). Also probably interesting to look at what some blockchains are doing to associate names with a public key.
• TURN -> no real alternative to my knowledge, or have a list of federated TURN servers, that's all. Or don't use them (it's optional in Jami BTW). Even the TOR bridges system works in a similar fashion, even if there are several nodes to choose from, it's not decentralized, you need to specify a specific server to use as a relay.