add partial centralization warning for Jami #1752

2020-03-02T19:30:48Z

lrq3000 commented

2020-03-02 19:30:48 +00:00

(Migrated from github.com)

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

#### 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  - [x] I understand that by not opening an issue about a software/service/similar addition/removal, this pull request will be closed without merging. - [x] I have read and understand [the contributing guidelines](https://github.com/privacytoolsIO/privacytools.io/blob/master/.github/CONTRIBUTING.md). - [x] The project is [Free Libre](https://en.wikipedia.org/wiki/Free_software) and/or [Open Source](https://en.wikipedia.org/wiki/Open-source_software) Software * Netlify preview for the mainly edited page: https://deploy-preview-1752--privacytools-io.netlify.com/software/real-time-communication/#peer-to-peer

👍 1

netlify[bot] commented

2020-03-02 19:31:29 +00:00

(Migrated from github.com)

Deploy preview for privacytools-io ready!

Built with commit a5f05411f2

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

Deploy preview for *privacytools-io* ready! Built with commit a5f05411f2815793576ce5a661937c1987d1322e https://deploy-preview-1752--privacytools-io.netlify.com

lrq3000 commented

2020-03-02 19:41:15 +00:00

(Migrated from github.com)

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

blacklight447 commented

2020-03-02 21:04:48 +00:00

(Migrated from github.com)

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

👍 1

Mikaela (Migrated from github.com) reviewed 2020-03-02 22:43:36 +00:00

Mikaela (Migrated from github.com) left a comment

I wonder if there could be any clearer link

lrq3000 commented

2020-03-03 02:12:26 +00:00

(Migrated from github.com)

@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.

@Mikaela do you mean something like [this](https://jami.net/why-is-jami-truly-distributed/)? This is linked by the first reply in the [issue](https://git.jami.net/savoirfairelinux/ring-project/issues/765) 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 commented

2020-03-03 02:13:34 +00:00

(Migrated from github.com)

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)?

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)?

👍 1

blacklight447 commented

2020-03-03 11:00:55 +00:00

(Migrated from github.com)

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.

> > > 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.

👍 1

dngray (Migrated from github.com) reviewed 2020-03-03 13:57:01 +00:00

dngray (Migrated from github.com) left a comment

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

Mikaela commented

2020-03-03 15:40:30 +00:00

(Migrated from github.com)

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

lrq3000 commented

2020-03-03 17:51:13 +00:00

(Migrated from github.com)

@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 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 commented

2020-03-03 18:05:32 +00:00

(Migrated from github.com)

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

lrq3000 commented

2020-03-03 19:54:08 +00:00

(Migrated from github.com)

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.

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](https://github.com/vuvuzela/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](https://tb-manual.torproject.org/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.

Mikaela (Migrated from github.com) approved these changes 2020-03-21 17:50:38 +00:00

dngray (Migrated from github.com) approved these changes 2020-03-22 09:21:35 +00:00

This repo is archived. You cannot comment on pull requests.

No reviewers

Mikaela

dngray