Why interoperability is fundamental for web3 messaging! / Steffen Kux

Transcript

yeah hello nice to be here my name is Stefan Cooks I'm from Corpus Adventure Studio to produce we have three applications and one of these applications we have builded in the past is dm3 and today I want to talk about why interoperability is essential for web free messaging before before we start I would like to have a question to you how many messaging applications you have on your phone only one two five maybe your phone looks like this the Mind looks like this not exactly but almost

so what we have in messaging is there are a lot of messaging applications and all these applications are their own closed ecosystem and even if you go to the vet 3 space where we have a lot of new small messaging Solutions also those Solutions are mostly not connected so it looks a little bit like this so we have decentralized services or even decentralized services but what they cannot do is sending transactions or sending messages between these ecosystems so now is the question now why do we need this interoperability is this really important or is it not

so when we look to some some questions in in the communities a lot of people are asking for interoperability even in the web tube world so and especially in about three world where we have sometimes much smaller ecosystems it is important so have a look why do we need this so the first is we don't have a Messenger application which fits all needs so if you have one which has all functions which are possible somebody cannot use it or others are looking for special features maybe for features which are especially foreign

ecosystem needed maybe for a community of nft users or for a creativity community so messaging Solutions must be different and that's why yeah is this important that we have also the ability to communicate between these these ecosystems so another point is when we look at the current situation in the web 2 we have most of these very big companies controlling all the communications and yeah we need into our probability to not have these Mighty companies to control all of this so I already talked about diversity I will go in more detail a

little bit later and also what I mentioned before is when we have special tuned applications for ecosystems it makes the ux much better so and one thing which is also not unimportant is the regulation so in Europe at least there are some regulations in the messaging space and there will be the requirement in the future that messaging services need to be interoperable interesting to see how this will happen but we can starting with three and can do it in a very interesting and very easy way so when we talk about interoperability there are different phases of inter

interoperability and and I want to focus on this definition because otherwise we might think of different things so the phase one and this is what we are focusing on is that we are into operable in exchanging messages so that means if there are two services or two protocols two applications and they are into our into our variable that means they can send messages from one service to another service how they store the messages how what they do with it is in the responsibility of these EU systems or of these applications but they are interoperable by able to exchange messages so phase

two would be that we can replicate messages between these interfaces so that the user can decide I use F1 and I can use also app2 and all the messages are shared in both applications and the phase three would be okay we have all resources shared so that we have only one ecosystem when we look in to the point how complicated is this for the for the producers of these applications then we see that phase one that we only exchange messages is the easiest approach and this is the approach we think we must go in the first step because if we are able to exchange messages then we can have

different ecosystems with different applications and different protocols but we are able to to have this possibility that we can exchange these messages around these different applications I already talked about it yet diversity is a good thing so we we learned it in that three year diversity in clients was very important now because if one client is not working well then maybe the other is it makes uh Equity much more stable and from the messaging standpoint so I mentioned it before it makes it much better for the end users if we have a diversity in applications because then we can focus

on the on the community which is using these applications and then do all or bring all these features which are needed there and in other ecosystem maybe other functions are much more important and that's why it is very important that we don't try to have only one messaging solution in the future so how these big messaging providers are trying to do so but that we have a lot of different applications which which help people to select what they really need so let's now have a look into web free messaging and what do we mean with web free messaging

when we talk about web free messaging we talk about messaging Solutions building on top of that free technology so first of all encryption is common standard we need encryption end-to-end encryption for every message every information we send also signatures are very common with signature we can prove where or who was the one who created a message who is the owner of of some information and so on decentralization is also a very important topic I will go in more detail to this point a little a little bit later and also interoperability as I explained it now is something we really need in

web free messaging to build such and good ecosystem which helps the user to be self-solving so that the user can decide what service is the best for me and what should I use to make my communication in the way I really like it to the registry is a Regency is also something which is very important I don't know who of you used encryption in email so like pgp so I tried it I did send my public key around with my emails and I hoped honestly to receive some encrypted messages you can guess how many encrypted emails

I received zero I nobody used it because it's really not easy in email to use encryption because you don't know where can I find the information from the other one to decrypt or to encrypt messages so in in bed three we have some technologies we don't have in web 2. so we have decentralized applications and decentralized applications allow us to have Central Records and it sounds a little bit strange but if I have a centralized solution others have to agree or have to trust this in that three I can a decentralized application

completely trust us but Central so that everyone can access this and yeah I will talk a little bit later how we at dm3 implemented such a central but decentralized registry so when we look at web free messaging architectures we see there are a lot of different ways to do it the central approach even if this is not really web free is done by some of the applications and this is also how decentralized big web 2 machine messaging Solutions work you have a centralized service and all the messages are directed over the

centralized service then we have these kind of broadcast or gossip networks so it started with whisper and there are others like xmtp work will and more who are using this approach here you have a network from decentralized nodes these nodes are connected and if you send a message you inject the message into this network then this this message is broadcasted in network and the receiver can get the message out of the network if he is able to decrypt it another way to do it is I call it Hub networks so here you have

communities which are which have a more or less centralized server and these communities are then connected with other communities so that they can send messages inside their own Community but also connect to other communities like Matrix or others are doing this in this way some special messaging Solutions are building messages messaging services on chain they are of course not using each rooms would be a kind of expensive but they are using a power chain on polka dot or something like this to use this blockchain or this special purpose blockchain as layer for the messaging solution

there might be a Solutions about this is useful but yeah it might also have some problems in the future with scalability and so on with Team three we are using a solution we call it delivery services it's a little bit familiar with this how we have it now in the email world you have these in the email World these post office service and then you send a message to the server and the user who wants to get his message can then collect these messages from the source and adapted to the web 3 world we have these delivery services as independent servers or independent nodes and the

user can decide yeah which nodes I connect to and then he can receive the messages which are stored temporarily on this service so when we now we talked about some features how their free messaging has to look like we talked about some architectures and now we have to think about yeah what is really the essence of F3 messaging so I was inspired from a talk at the last Defcon where we talked about subtraction now if we have a problem just look at this problem and break it down to the real Essence and when we look at web3 messaging we have actually

only few things we really need to do the first thing I already mentioned is the registry we need a central but decentralized registry for information for the communication information like public keys and the information how to deliver messages and we need a network of decentralized nodes where we can send the messages to and this this actually is the really essential thing and if we now remember the things we talked about into our probability we think also this is something which is really important so that we now can build an ecosystem where different applications can be or can

work together 15 free we started one and a half year before to build a decentralized web 3 based messaging application but after our MVP we switched our direction of development to build mainly a protocol a protocol to allow web3 messaging and a protocol which is able to allow indoor or properly between other protocols as well so we call it a layer of zero messaging protocol because it's a very lean protocol which can be included in other protocols and services without changing

their architecture and by this making is very easy to connect a product to the dm3 network and by this becoming interoperable with the other network then I already talked about the registry we have a ens based regulatory I have a describe it in detail and we have this as a decent class Network and our focus of course as of all the things which are important for mode on messaging like encryption privacy preserving and so on and one thing which was also a very important thing we discussed from the very early beginning that we need

scalability from the beginning now if this protocol should be available for a lot of different ecosystems then it must be scalable by Design from the very early beginning so when we look at this picture it is only to visualize how this protocol is is organized we we have this well right here so we have this base layer where we have ethereum and ethereum name service so that we use this name Service as regularly for our information and then we have this transport protocol which is this lean layer 2 transport messages from one service to

another service and on top there are some protocol extensions and you can build your own applications on top of it or you can use companies applications we provide for this this is the same picture only with more detail I don't want to go in detail you can look into these Pages later by yourself and see there are a lot of extensions for all features you need for modern messaging but they are separated from the base layer because it's important to have a lean base layer for the interoperability and then have additional protocol extensions to solve all the problems you have and you need to solve

let's talk about the registry we are using ens and having the profile the communication profile as text record on your ens name that means if you have an S name you can publish your your profile your communication profile there and here the user others can find the public keys for the encryption they can find the information how to deliver the message and of course ens is based on ethereum doing all this on ethereum might be a little bit expensive and that's why we are using also ccip the cross chain into a probability protocol from chain link to also link Auto resources to ens now you can have the information on chain

you can have it on Layer Two in optimism or other protocols you can have it even on a centralized service you can have it on other chains with this IP it's very easy to include it and with this if some solution some protocol integrates their registry however this registry is organized into ens it's very easy possible using ccip and with this we can can have our Central source of truths we know all information about communication are bind to some name in the ens we talked about the decentralized

decentralization is very important for web free messaging and for dm3 we decided to have the simplest possible approach how to build this decentralization and we do we are doing this by using these decentralized and delivery service nodes that means these are nodes which are a relay for the messages so when I want to send the message to some receiver I send it to his or her delivery service and they are stored cached on the server until they are picked up so that then they are managed in the application so every user

can decide what the level of service he wants to use he can run his own delivery service can run multiple delivery resource use existing services and so on by this the user can decide what are the delivery services I want to use and also if I have other ecosystems which want to join the dm3 ecosystem they can use such a delivery service as gateway to their services so as it is visualized in this picture on the button so that other ecosystem can be added and have their own delivery service or the services so that they are reachable from the DMV Network and then in checking the messages into these other networks yeah I mentioned it already that every

user can decide to use one or more delivery services so if I run for instance my delivers at home and then I can have a second or third deliveries in my profile so that if my personal delivery is down then another service can be used and with this the user can be sure that there's no censorship because he can decide to use all every other deliveries to a to the send or to relay his messages when other services want to join then they're using these deliveries as really is so that they can receive the messages

and then however the network works on the other side in check this matches in the other network if this is for instance such a broadcast network then they take the the message from the DNZ Network package them in a message format in their Network and redirect it in their other messaging Network or if this is a centralized service then they receive the messages with the delivers those and then work with this in their centralized service and with this it's very easy to bring other ecosystems together with dm3 because they only need to implement this Gateway and with this they can throw in this connected ecosystem

of Team three nodes so what do I need to do if I want to include Maya my solution my important into dm3 so first I have to integrate my existing registry into ens so that others can find the information how to connect and how to communicate then I have to implement a delivery service which connects to my network or I need to implement a way to ask other networks for messages both with ways are possible and the third thing is that I have to add the dm3 encoding to uh to my clients

and because these methods are encoded and encrypted in the dm3 version and too short and to send it then I need to use this encryption or this encoding so that I can work with the dn3 messages and these are all steps not more is needed so I don't need to change the way how I store messages I don't need to change anything my client except adding this method to yeah to decode the dm3 messages one problem I have not yet discussed but is very common in messaging systems is spam

we know it from email at least 50 percent there are statistics they say over 90 percent of messages in the web 2 world are spam in the three worlds we have some interesting possibilities to what we can do to prevent our networks from being spent in the future so there are message or methods which can be done on protocol level and there are things which can be done on client level on protocol level we can use things like the sender needs a special talk or special nft or amount of tokens to being accepted or

you can check that this account is really a used encounter that it has announced bigger than a given number and with this it makes it much more expensive and complicated for spammers because if they need announce on this address a special token there or amount of tokens they have to do a lot of work to to build addresses to spam otherwise they are blocked also whitelists and blacklists are possible but we know blacklists don't work don't really work and white lists are well restrictive and on a client level we can do also something which is not possible in web 2 we can add tokens to a message

and the user can if the user says okay this is a spam message then these tokens are burned and if this we can make it very expensive for spammers so that if you said okay I'm spammed too much I only accept messages where tokens in the world of one dollar are added to to this to this message if this is not if this is not a Spam the sender receives it back if not it is burned very effectively to make it very hard for spammers to send a lot of spam messages and in that three we can build these spam reduction methods very easily

and we think Forever Three messaging ecosystem it is very important to have these spam protection rules from the very beginning so let me summarize what we have talked about today so indoor probability is really essential for messaging especially for the web 3 messaging world so compared with we have two messaging worlds perhaps three messages is small even if we count all the messages together we are smaller than some of the smallest from the web 2 world and if we are starting to build a lot of isolated ecosystems it might be not possible to get a lot of traction so

that it might be a real relevant solution for the future if we are able to implement into a probability then we can build and show that and connected ecosystem is possible and then even with for instance dm3 it is possible to include web's two solutions so that we can build this connected messaging ecosystem we need for the future so with Team three we have a very lean protocol which can be easily integrated the the current version is available it is already implemented by some of some messaging Solutions and of course we invite all others to check it to test it and to integrate it in their product

yeah everyone can partake df3 is an open source and public good product so all sources are available for free and we of course invite everyone to use it and also to participate by Yeah by influencing what comes into this code what should the protocol do in the future yeah we we started in initiative we call it the messaging into a probability initiative where we invite a lot or all other messaging solutions to participate we have already had a lot of discussions with a lot of different protocols and yeah it just started it's not too late

to join you are invited to join because of the time I jump or the roadmap you can get this information and have a deeper look into it and see what parts of their development are planned for the future that we have now finished as I said the base layer protocol we started also to implement and to specify all these extension protocols so that we can provide a lot of different important and nice features for the future okay thank you very much for being here are there any questions [Applause] the delivery service this shares the

state with all other delivery service I guess or no no this this is not the case because if we would do this then we have a lot of Graphics between this delivery service so the delivery service always receives information or a message and stores it and if the user wants to receive it it goes to his level service and they are not sharing the information because then we have a connected Network which cannot be scalable in the future but this the sender and the receiver need to use the same delivery service then right it One Direction is also always One Direction only so if I want to send a

message to you I use your delivery service order one of yours or even I send it to all of your delivery service if you want to send a message to me you look into the registry and see what Maya delivery service are and to send it to this deliverable service okay got it thanks thanks for the presentation and just to make sure I understand if um client A and B build on your protocol I can talk to you from client a and you can reply to me from client B right yes and and then is there a way to dispatch content so the messages based on the context of those message for example if

I'm talking about movies it's going to be dispatched dispatched on the Netflix client but if I talk about um travel it's going to be dispatched on the TripAdvisor client they have what do you mean with so what we are talking about is peer-to-peer messaging yeah there are one user and another user and they want to exchange messages yeah but but like sometimes you know we have like groups and then we talk about a bunch of stuff and mixing like everything right okay yeah so group messaging is also an extension of the protocol the base protocol is only peer-to-peer but an extension is also group messaging and yes you say okay there are also some flavors on the

messages so they can say okay this message is for a special purpose and or for a special topic and the protocol also supports this so that you could also add this information depending on the client now if there's a client say okay I can understand this categorization it can do it even if another client says okay I cannot do it then messages are in a row so the this protocol says okay how to exchange the messages also you can add some special flavors but then the client has to support it yeah build up there of course okay when that

comes live we will probably share it on Twitter we are Publishers yeah so um okay when you say we you mean yeah and also as I said before team three is open those public good and we are not defining how the standard has to be we are collecting and if there are some requirements just let us talk and we want to build a community protocol which fits to most of their Community requirements yeah is good okay thank you very much there are resources all are free be free to

go to this resources get your information thank you very much [Applause] [Music]