Sideproject: POC Substrate secure messaging integration

[bedeho]

POC Substrate secure messaging integration

Status

Available

Purpose

The purpose of this POC is to

1) Define a self-contained project which new developers can tackle as part of the mutual evaluation process for joining the Jsgenesis development team.

2) Generate some initial findings, specs and implementations which can make their way into a Joystream testnet in the near future.

Background

The platform should have a communication subsystem in order to facilitate participant coordination in a number of different contexts. A key component of this communication subsystem is a messaging system. In the future, a messaging board will also be introduced.

Recall that the platform has

1. a membership registry where each member has a unique (human readable) string handle, signing keys and a media-rich profile.
2. a set of moderator authorities which are themselves policed by the governance system.

Goals

The messaging system is integrated with the following ways

1) The namespace for user handles in the messaging system is the same as the handle namespace in the on-chain membership system. Specifically, end users will be able to resolve the appropriate handle for a messaging system participant by looking up an on-chain mapping from the user key to the handle.

2) The communication in the messaging system is authenticated and possibly encrypted (depending on context) using keys, directly or indirectly, from the on-chain membership system.

3) The rooms in the messaging system have human-readable names in a namespace governed on-chain. Specifically, end users will be able to resolve the room authority (which is most likely identified by a public key) based on a human-readable room name by looking up an on-chain mapping from room names to room authority identifiers. As a consequence, the moderator of a given room is also then determined by the chain.

Requirements

Messaging protocol

Must support

• direct messaging, with confidentiality
• group/room messaging, and this must observable by anyone, not only participants in the group
• non-moderating participation must work within browser constraints
• servers/relayers cannot read or forge messages, or alter message order

Benefit, but not an absolute must, if it supports

• receive messages offline, which are persisted. Assume exogenous incentives
• group/room messaging confidentiality
• forward secrecy

Practical

• Use some existing messaging protocol.
• Substrate runtime need not include the governance mechanism itself, changes to a governed state can be done through the authority key.
• Re-purpose an existing messaging client, don't build from scratch, must work in browser/Electron.

Milestones

1. Select messaging protocol & client after reviewing multiple options: e.g.
   • Matrix (in developement?)
   • XMPP
   • Whisper (in developement?)
   • IRC
   • HOPR (in developement?)
   • Something over Webrtc?
   • other...
2. Write high-level specification
3. Implement required changes in messaging client, and 3.1. Centralized (skip if confident): role of the chain is played by a hosted web service, and messaging client integrates with it, as test. 3.2. Blockchain: replace role of web service with substrate instance

Deliverables

1. Messaging protocol review, analysis and decision
2. High level specification
3. Altered messaging client
4. Substrate runtime + CLI

[bedeho]

We were provided these relevant links from Web3 about their work with Matrix, worth reviewing

• https://medium.com/web3foundation/messaging-for-web-3-0-building-an-anonymous-messaging-protocol-e29db72f4d19
• https://github.com/w3f/messaging
• Validity Labs implementation: https://github.com/validitylabs/hopr

[SCBuergel]

At Validity Labs we're working on HOPR as a low level communication protocol that provides metadata privacy and is running in a decentralized fashion with incentives for relay node operators. It's worth mentioning that storing messages, data sync etc are separate layers that for now are out of scope for HOPR but might be tackled in a suitable fashion by e.g. Matrix.

[bedeho]

Reference: https://cabal.chat/

Based on Dat (Hypercore) I think, should be easy to adapt to this project.

[bedeho]

Simple solution

There appears to be a simple solution to this sideproject, which is simple in the sense that it will not require creating, or even just altering, an existing wire or authentication protocol, nor even have any Joystream specific network or infrastructure running. Instead, it should be possible to only make some very high level changes to an otherwise suitable messaging client that uses some existing network (like keybase, telegram, signal, otr?), as well as make some very simple runtime level accomodations.

1.0 Proposal

Assume there is some operational network which has its own account system, handle and group chat namespace, storage model etc. which otherwise satisfies our other requirements on

• confidentiality
• group + direct messages
• offline storage
• open source reference client that works in browser

a) We allow each member to assign a participation identifier (e.g. handle) in this system as part of their membership profile in the runtime.

b) We allow each on-chain actor who is supposed to moderate a group chat to set, and update at any time, a group channel identifer (channel name) used in this system.

c) The client is altered so as

• When it runs into an unknown use in the messaging system, it attempts to resolve it using the runtime mapping, and then apply some policy based on whether there is a match, possibly such as.
  1. ignore or hide messages or requests from such a user if there is no match, or otherwise clearl indicate that they are not part of the platform.
  2. clearly show that a user with a match is verified in some way, such as showing a richer profile, or checkmark, or something.
  3. keeps up to date with events that change the on-chain mapping.
  4. the moderator can run software which either automatically kicks out any member from a group chat which is not found in the runtime mapping, or even explicitly keeps the group closed using internal access policy of the system.
• Resolves group channels using the on-chain identifier, and keeps track of changes to this mapping - automatically switching to a new group if the identifier changes.

This appears to both be simple, and give us everything we want.

2.0 Improvement: Preventing false claims about off-chain handles

A very minor issue with this scheme is that a member can falsely signal that an off-chain handle corresponds to themselves, while in reality it does not. In practice, this seems to be a minor issue, as the incentive to do this seems very low. However, if we wanted to solve this, an easy solution is to include a verification status to the handle claim that lives on chain, and use a manual challenge response process to allow some runtime level actor to sign off on whether the on-chain member controls the off-chain handle.

In theory, this could be automated, since the member can directly trigger such a process conducted by the runtime, where the runtime can authenticate a challenge, by validating some chain of signatures from the response to the root authority of the messasing service itself.

Both approaches seem hardly worth it currently.

[bwhm]

I have long been a supporter of looking into using Keybase for this. At least as a temporary solution.

When it comes to verifying a user name, Pioneer already has an easy way of signing/verifying messages in the GUI. I'm thinking we would only have one "closed" channel (curators) at this stage, so making them jump some hoops would be ok.

[bedeho]

The only substnantial drawback of this approach is that the user will have to double authenticate, they would have to sign into Keybase in Pioneer, so to speak. On balance, seems worth it?