Canonical channel names and the matrix/whisper bridge

Messenger
1

There’s been some talk here and there about where you “are” when you’re chatting in Status channels.

Is the #ethereum channel in the Status app the “ethereum chatroom inside status” or the “global ethereum conversation shared by everyone”.

My personal opinion, is that it’s the latter, and I think this also squares with the web3 and whisper ethos and vision.

Channel names in matrix have a “canonical alias” which includes a namespace, like so #ethereum:status.im. This makes sense in the pre-web3 universe because there were no metaphors for a single massive unified p2p web of messaging. In web2 and below, every service was an island; every chat protocol was its own bubble. The #general channel in the Status Slack is not the same channel is the #general channel in a different Slack team, or a different service.

With whisper, this is kind of no longer true. It’s a new metaphor. There is no namespace.

In whisper we are generating channel names by taking the sha3 hash of the word “ethereum”, using just the first 4 bytes and this is the topic that whisper messages are sent under for public chats.

For the time being, to bridge Status’s incarnation of Matrix with Status’s incarnation of Whisper, there has to be a mixing of metaphors. Channel names in matrix like #ethereum:status.im will be truncated to just #ethereum and that’s the topic they will be sent under through whisper to get into Status.

I feel like this is not fully correct and shouldn’t be a long term solution.

Perhaps there needs to be a larger discussion about the handling of namespaces in general, now that we have a new metaphor in the mix.

There are varying levels of publicity for messages:

  1. Fully public: #ethereum
  2. Part of a public group or organization: #ethereum:status.im
  3. Part of an informal or private group: #ethereum:[some-shared-secret]
  4. Personal notes or thoughts, not meant for public: #ethereum:[my-personal-secret]

You can have many different conversations about #ethereum or #cats or whatever, some are fully public, some are just with some friends, some are just for you. Those are all different conversations but also part of the same larger conversation. They are linked to each other and inform one another.

Is there a way to explain this concept and also visualize a chat experience that incorporates these types of publicity distinctions?

5 Likes
2

I like the broadcast analogy that a whisper topic is like tuning into a radio stations frequency. I think public or private is more a matter of encryption and who can decrypt my messages. For example if we are having a one to one chat, that chat is happening on the discover topic (same topic where everyone has their one to one chats) but only you and I can encrypt and decrypt messages.

This pushes the radio analogy a little bit further in the sense that the content of the radio broadcast is encoded and only certain “radios” can receive clear sound.

1 Like
3

Hm, this is a tricky topic indeed, and brings my thoughts to the identity problem, in general.

If you think of the chat as “global ethereum conversation”, it sounds like something that quickly grows out of scale - it fails to take into account the local nature of the vast majority of conversations that we have. Like you point out, the general chat in status is distinct from the general chat over at… spotify, and there’s no real interest in mixing the two - in making it global, its meaningfulness is diluted proportionally to its growth.

In communication, the social network matters, and turning a blind eye to this seems wrong - I’m in particular intrigued by projects like Secure Scuttlebut which turn this into a competitive advantage to solve all kinds of issues, including spam and sybils: https://www.scuttlebutt.nz/stories/design-challenge-avoid-centralization-and-singletons.html, https://www.scuttlebutt.nz/stories/design-challenge-sybil-attacks.html

Understanding Decentralized Identity | by Richard Chen | The Control is a great intro to the problem, as it’s being looked upon from inside the bubble - perhaps there’s something in there that can be applied?

1 Like
4

Global conversations are pretty useful though, and it’s possible that you could have some sort of filtered overlay on a global conversation, which I think I’ve heard some people ideating about within Status.

You can also combine topics in Whisper. So you could do your own filtering, like say you filter on #ethereum but also #my-friend-group to only catch messages that straddle multiple topics.

The closest thing right now we have to global conversations are hashtags on Twitter. Sure, they don’t share the same conversation with hashtags on Facebook, or anywhere else, but it’s the largest single audience converging on shared topics, so it’s as close to a global chatroom as we currently have.

5

ah, that’s an interesting way of looking at - think of them not as channels, but tags that dynamically come and go for each post you make… this makes a lot of sense if your post fits in many “categories” or topics… but is this the case for the bridge?

6

This isn’t really how the current Status chat protocol is designed unfortunately. You can use multiple topics but it’s my understanding that the chats are each encrypted with a key that’s generated from the channel name, which is also a single topic, so I’m not sure how that would translate to multiple topics = multiple “tags”.

7

My answer to this right now would be: I don’t know. These all seem like reasonable questions.

My meta question would be: if we just decide to go down some route and try it out, how hard is it to reverse this decision? If it isn’t too difficult I’d just go for whatever the simplest design is and iterate from there.

8

Agreed, @oskarth. I think the solution at this early stage is to just bridge the channels in Status as they are, to the channels in Riot as they are, so:

#ethereum (Whisper/Status) ↔ #ethereum:status.im (Matrix/Riot)

It’s a larger conversation about channel names that may involve changing how the Status chat protocol addresses channels.

I talked a bit with @Matthew about this in Riot and he has some super interesting insight from the Matrix side. This is an issue they’ve been thinking about a lot and have some ideas about.

9

So: Matrix also has the problem of how to name decentralised conversations, as conversations are also fully decentralised via merkle tree replication over the nodes who participate in them (where the nodes happen to be servers today). The way we do it is to assign a random unique ID to the room at creation - something like !QtykxKocfZaZOUrTwp:matrix.org. The ID happens to include the domain name of the server which created the room in it, but this is purely to make the ID a bit more unique - it is not used for routing purposes. In the nearish future we’re moving these over to being Ed25519 public keys, in order to remove DNS as a dependency from Matrix (see Removing MXIDs from events - Google Documenten for gory details).

Then, to actually discover the room itself, Matrix supports the idea of aliases - these are human-readable pointers to a given room ID, and look like #name:domain. A given room can and does have multiple aliases - for instance, the room linked above has the following set of aliases:

#matrix:matrix.org
#matrix:half-shot.uk
#matrix:m.12o.nl
#matrixhq:mt.tlebear.win
#matrix:mt.tlebear.win
#matrixhq:cadair.com

…and about 20 others. As you can see, aliases can be on different servers, and they are simply a way for users to discover a given room. Rooms can optionally also define a canonical alias, which lets them declare which of the many aliases they prefer to be known by (in this case, it’s #matrix:matrix.org), but this is just a convenience to help confused users :slight_smile:

Now, for the case of bridging between Matrix and Whisper, the way the namespace would work on the Matrix side of things is that a given Status channel could be exposed by multiple different bridges running in Matrix. So for instance, the matrix.org server could run a bridge which exposes #ethereum in Whisper as #_whisper_#ethereum:matrix.org. Another bridge run on the status.im Matrix server could expose the same room as #ethereum:whisper.status.im. Alternatively, status.im could just define an alias to point at the bridge run by matrix.org and so have #ethereum:whisper.status.im as an alias to the same matrix room as #_whisper_#ethereum:matrix.org.

For the problem of how to handle namespacing of names in Whisper itself: please please please please don’t use colons as a delimiter - we deliberately chose the #foo:bar.com and @foo:bar.com nomenclature in Matrix to avoid the URIs getting confused with other protocols. Perhaps you could use slashes or pipe symbols or something?

I also wonder whether you would be better off naming the channels off a pubkey (like we’re moving to) rather than just hashing the name of the channel, as this then gives you support for nameless conversations and avoids rainbow table style attacks on discovering channel names. Then you’d need a separate discovery mechanism for the channels themselves, of course, but that level of indirection sounds useful - and you can have nice stuff like multiple aliases for the same room like we do in Matrix.

(Obviously, a more interesting conversation here would be how to converge Matrix and Whisper semantics together somehow, but right now both projects have their work cut out getting their existing protocols to work, let alone breeding them together :slight_smile:

2 Likes
10

@noman did something happen to this? It’d be great as we could use it to bridge:

  • Embark (Gitter)
  • Nimbus (Gitter)
  • Protocol (Riot)
11

for nimbus, if riot is bridged, that’s enough… we’re bridging our gitter to riot.

12

hey @oskarth :slight_smile: as far as I know, the whisper bridge got to the point of working - GitHub - noman-land/matrix-whisper-bridge: A two-way bridge between the matrix protocol and the whisper protocol is the URL. @noman got as far as asking me to provision it on the chat.status.im Matrix server that we run for Status, but there then seemed to be some confusion over how official the bridge was and the conversation went cold. We haven’t checked the code at all.

1 Like
13

I believe receiving back from matrix on the status end was the difficulty - also not sure of any details beyond that or don’t recall @noman

14

hm, weird - matrix->wherever should be trivial. https://github.com/matrix-org/matrix-appservice-bridge/blob/master/HOWTO.md is an example of how it works.

15

Hey all, sorry I missed so much.

I kind of got busy and stopped working on the bridge right around the time everyone moved from Slack, thinking we were all-in in Status and bridging wasn’t needed anymore.

Last I heard, some of my work was expanded upon in a fancy new JS library made by @rramos, @iurimatias and @barry, which does a lot more stuff. At this point, the bridge should almost definitely use that code instead.

This brings up an interesting point that I was struggling with a little when thinking about bridging both Slack and Riot but from different servers. Unless there’s a single bridge, bridging all the sources out to each other, how do you prevent bridged messages from one source from being duplicated by other bridges?

Edit: Last I remember, Status whisper messages don’t have any sort of globally unique IDs do they? Like a UUID?

1 Like