This is a transcript. For the full video, see Peer-to-peer Collaborative Editing Using Yjs & WebRTC - Tag1 Team Talk #007.
Preston So: [00:00:00] Hello, and welcome to another episode of Tag1 team talks. I'm your host Preston So, editor in chief and author of Decoupled Drupal in Practice. I am joined today by three of my wonderful friends who are going to talk with us about webRTC and some of the amazing applications that we can apply to it, including Yjs and collaborative applications and a peer to peer setting.
I'm joined today by Kevin in Germany. Kevin is the founder and the project lead of Yjs and the realtime collaboration systems lead. Yeah. At Hagwon. We're also joined today by Fabian Franz in Switzerland, senior technical architect and performance lead at Taiwan. Fabian is one of the top of Drupal, seven core branch maintainers.
He's also one of the top 50 contributors to Drupal eight and maintain it for several Drupal core subsystems, including big pipe dynamic page cache and feed API. Right. Also joined today by Michael Myers, managing director of Tag1. And it's a real pleasure to, sit with you all today and to talk a little bit about some of these very exciting and cutting edge topics.
by the way, this, this session will be recorded and available on YouTube as well. As on tack one's website. So, if you want to check out our past tag one teen talks, please go ahead and navigate over to tag1.com/tagteamtalks. And if you liked this talk, please remember to subscribe to our YouTube channel, share it with your friends, with family.
And with that, let's go ahead and start with a little bit of an introduction about Tag1 and why we're so interested in this topic.
Michael Meyers: [00:01:40] Awesome. Thanks Preston, Kevin, Fabian. Great to see you guys again. Collaboration is a big part of how we work together and get things done. And, it's becoming a really important part of applications.
And we're working on a number of collaborative applications right now, that enable people to whiteboard together. create an edit, share documents together. And we think that this is going to be a secret, the cool part of a lot of applications moving forward. And, the topic today, I think is really going to accelerate the adoption.
Preston So: [00:02:16] I couldn't agree more. And I think that peer to peer collaboration is an incredibly, incredibly relevant topic for so many enterprise organizations, as well as so many of us who work in content. And one of the things that we know now, that's a recent development is that webRTC, which, which enables this direct peer to peer communication is now supported on browsers.
But first let's take a step back and, and, you know, I want to ask Kevin and Fabian what is exactly a peer to peer application or what we're kind of terming these days a decentralized application.
Kevin Jahns: [00:02:47] Hey, so yeah, that's an awesome question. I think there are a lot of opinions on what the centralized means as an application.
I think, something that comes up more and more, and, that is not really viable. And is, our applications that communicate directly with each other to maybe save some server load, or to be more robust. And, it's come up, with webRTC, which has no stable and supported by all the browsers. And I looked it up just, just, last year, mid last year, they released the stable webRTC version.
But even before that, it was well supported by all the process. They can also communicate with each other and, yeah, it's basically the easiest way to create, a decentralized application is now in the web, like in my opinion. And, yeah, so I would classify everything that uses webRTC to share data.
it's kind of decentralized, an application. there are also many frameworks that use, webRTC as an underlying technology to, share and sync data and maybe even store data. for example, there's that protocol and, IPFS to a certain degree also use it as this. So yeah, that's how I would classify it.
Fabian Franz: [00:04:19] Yeah. So people want homes familiar with the acronym at PFS is internet file system. Basically it's a huge storage spare. The date is off, so we'll just double it across several different computers. And it's absolutely insane. It's like they have like a decentralized YouTube, but when you're watching the video, you're not getting it.
Oh, Google servers, Amazon service or whatever, but you're getting it from some computer on the board that has asset data. It's very cool. But getting back to reality, one appliance for distributed peer to peer is what we're doing right now is conference calls because, No provider, not even Google or Amazon, what's it like to have that huge spills of having all the traffic widgets for their server.
And then again, for all four of us, that really don't make sense. So right now, we, for basically connected, we are a peer to peer connection with each other. Everyone is getting this feed directly in that. And, this is basically, one of the foundations for them. Well, he's can voice calling over the internet.
It's and the nice thing, and that's what they're talking about now is how we can utilize this technology in the browser, in the context of why jazz for calibrators, text editing whiteboard, etc.
Kevin Jahns: [00:05:43] Yeah. Right. I think the, the main application for webRTC at the moment is for creating conferencing solutions, right?
so there's Google Hangouts, there's open paths. like there are many, applications that use webRTC, but only for sharing, sharing media data, like, screen recording or webRTC recording and something that is not well known to a lot of people is that you can also share data with webRTC, but there's something missing.
And that is you resolve conflicts because if you have more many peers, you will have conflicts between the data that you are working on. So when you want to share data, you need some algorithms, some approach, some protocol to, resolve these conflicts or, like the site, what is the latest version and, Yjs, supports is exactly built for that?
Like if you were having, been on the latest talks that we did before this, Yjs is a framework for collaborative editing that is completely network agnostic. So you can, yeah, you can enable collaboration over any network. Is it your existing communication layer or webRTC or simple web sockets or even a mesh protocol?
That all works. And now there's a there's a webRTC provider officially supported and rep for Yjs. I've been working on this for quite some time. And yeah.
Preston So: [00:07:26] One of the things I'm curious about is, you know, because we've jumped right in and talked about Yjs, can we give a quick summary of, of, of what's a good definition for webRTC? Like the one or two sentence kind of, here is definition that we can offer our listeners today.
Kevin Jahns: [00:07:42] Yeah, we should have done that.
So, to go back, webRTC is a protocol that allows you maybe not a protocol. It's, it's a protocol as TCP is a protocol that allows you to create direct communication from one brother to the other, basically works like TCP. But, for it has the advantage that it can punch hole through net layers through proxies to the other side.
So the problem that you're facing is, you are in your local network, behind the router and you're behind the internet service provider. And now you want to create a direct communication, to your friend, to you to share media data or to collaborate on a document. And, webRTC is exactly that it's a protocol on how to, how to make that possible, how to punch the hole through the network and how to establish a communication, that goes through these NetApp layers.
Yeah. It's kind of complex, but actually it is not it's. so the way this works is as a client, you find out your external IP address. And, some additional information. and then you sent this as a candidate, did it on how you might be able to be reachable to the other peer. And that peer like decides, okay, is this an acceptable method for me to communicate?
Can I do the same? Can we connect like that? Then this client finds out its own external IP address and some other information and senses SS session description to the other peer again. And if they decided that this is okay or way to communicate with each other, then they can create a, a connection to each other.
And this is all defined in webRTC. It's, it's kind of complicated, but there are libraries that make this really easy and approachable.
Fabian Franz: [00:09:54] Yeah, what exactly do I need to do if I want to, let's say we do have two computers. We are, crossing the net. And, now I want to communicate with you, so, and I know you address.
Hey, great. but one thing, so basically start the webRTC connector. And then, I'm putting in your IP address. Would that be kind of, would it be like some unique identify how I would reach you or that you generate. For me to reach or how could it be?
Kevin Jahns: [00:10:32]Yeah. great question. Like how can we establish a connection with each other?
Like we could define that I have a unique identifier, but, in order to exchange session data, Do you need some other networking layer to communicate that session, that session description, right? The external IP address, all these information that I talked about, and this is usually done by a signaling server.
And let's say signaling sofa is not really a requirement. You can use any, any way to exchange these signaling data. For example, you could use email to send it a friend of mine instrument current. He used QR codes to communicate the signaling data from one mobile phone to the other. It's really cool.
He has a researcher at, wth often and, yeah, this is also a way to do that. And this is completely peer to peer and, physically approachable, but most implementations use a server central server. To reach the other client, establish a temporary connection exchange, the session description. And then if you have a direct connection between the peers and the settling server, it's not really necessary anymore.
Preston So: [00:11:56] Sorry. So one question I had is about security. You know, I think with all this direct communication happening between these peers, you know, once you establish that connection, there's, there's some security applications there, is webRTC an encrypted protocol?
Kevin Jahns: [00:12:09] Yes. It's by standard it's encrypted.
So all the, it's not an optional, every webRTC connection that you encrypt is, that you create is encrypted by default. So it's basically a public, it's an, biometric, encryption protocol that is well known. And it's, it's integrated in this, in the, webRTC protocol in
Fabian Franz: [00:12:40] tears as energy users, public key cryptography.
Was that what you were saying? Like, I sent you my public key, we as a Sigmadek shovel, which people's trust. And then, you can encrypt the data with it
Kevin Jahns: [00:12:53] Yeah, right. but you don't really interact with the, with your, public, private cheese. this is done by the browser. Usually it is added to the session description data.
So, also there's a new certificate that is created for every connection that you do as far as I know. So, yeah, within the information that I sent to you to establish a connection. There is this certificate. and it is a requirement, in order to establish a connection. So webRTC is secure by default, but you said
Fabian Franz: [00:13:33] us sending me the, the box with which I can then, send you the box back and you'll have the key to open the data.
Kevin Jahns: [00:13:41] That's exactly right. We already do the, all this, product. We already sent the data back and forth. Right. So we can just attach a certificate and it's secure. So why wouldn't we do it? but you said something interesting here. we both trust the signaling server. yeah. So do we really need to trust the signaling server?
So this was something that, yeah, that was interesting to me, because I developed a signaling server that you don't need to trust. And this is also possible with this is possible with isymmetric, encryption, which basically says if you both, if all the peers have, have, shared secrets, some certificate, maybe.
And they can communicate through the signaling server without trusting the signaling server, right. This is easily possible. but it's unfortunately not done by a lot of people, but to me, it's a really interesting concept.
Michael Meyers: [00:14:48] And that's how Yjs works, is it can work with an untrusted signaling server.
Kevin Jahns: [00:14:52] Yeah. So the new buyer RTC, well provider a, it supports, signaling through an untrusted server. So, yeah, let's jump right into it. So why webRTC is, the communication layer and it provides a method to exchange signaling data. through a very minimal, simplistic, implement signaling. So the implementation, the idea here was that you can easily, we implemented in any other language.
It's basically some, something like a published subscribed server. You basically sent message to a room and everyone who's subscribed to a room receives the data, but, they actually data like the session information. It is encrypted with a key that only the peers know. so this is how we can, well encrypted data without, trusting the server.
And for example, I provide several signaling servers, that you can use for free. They are public. And usually this is a bad idea, right. But, for this scenario, if you want to develop your own application, just get started. You don't have to set up your own sickening server. you can just use a default one and it's also easily scalable because popular subscribed servers are easily scalable.
Fabian Franz: [00:16:19] So, let me explain this a little bit more for people are maybe less familiar with, technology security and purpose and all those things. There's basically two ways. For example, Michael and me can exchange the secret message. We can both define it. Code verb. Like bird, for example, or check one, two, that might be a little bit easy to get.
and now was that code word? We can securely exchange a message. This is quarter symmetrical. encryption, there's another part of encryption and that is public key cryptography. And you all use it because it's kind of how the HTTPS works. That means someone has a secret and he's, publishing the other part of that secret.
I've already explained it quickly, but just again, it's basically I sent Kevin and box, should that Kevin sent me a box to bitch only. he has the key, but it's open and I put my secret message in there, close the box, and now was tended back to Kevin. but no one else has a key, not even me. So once I put this thing in the box and closed it down, no one can open it except Kevin and this baby thing, the problem is now.
And for the first part, How do we exchange things? And now I'm one of the pods numbers. The first part of how a signaling server would be working is that everyone would be saying, Hey, my box or my public key is this. And they will be sending it to the Sigma name server and the signaling server would send it over right to the address.
However that, because it sits in the middle. You could as well say, Hey, I sent my own public key and, this one, so men in the middle at tech. So that's what we want. So, but Kevin, and now we can put us into WordPress or Drupal context as basically, all of those editorial sections are starting on the Drupal side, for example.
So all of those sessions have. Tupac, they trusted the HTPs to let side so we can generate a token. We generate the token one, two, three, four, five, not as secure, but anyway, we have the token and all of them have the same token. They know the numbers of analysis, but the signaling server does not know it.
And what Kevin has done now is basically the, we can use a signaling server as a signaling server server, never now out of a secret. So basically we can now as soon as we are connected exchange data, we are secret token that we got from Drupal and. We can use any signaling room serve on the net. And this is very, very cool because it's also very, very common problem.
The problem of setting up your own signaling server, us more of that side, right? It's mostly UMass, et, etc. And not having to trust that. So because, because I worked in it's enter ending, but what it's called. We are directly encrypting our messages. We, as a secret key, we now entrust, we don't have to trust Cigna service so anyone can set up a signature seller for us.
And I think that's a huge win in that. And this could allow Yja, as to be why Timor used, because you don't have to set up a note server, you don't have to set up a slope. HPV is polling. So whatever for those. In this sort of connection to start, you just use any public signaling server and once you're connected
Kevin Jahns: [00:19:53] to a secure, right.
and again, you said something interesting here. This was a great explanation explanation, of all the concepts here that you can use just by using a secret server. at secret key, you can make sure that only people who have real access to the document can actually read it. And you said something interesting here is, to one of the segmenting servers, because this is something I want to talk about.
you with why Y RTC, you can access many signaling servers at the same time and just find people on one of these servers. So, if two people are connected to the same signaling server and they are accessing the same room, They can now, they will find each other and create connection with each other.
so I'm not in the dimension of, this is you can use it is to scale your server or your signaling information, sickening servers by setting up many sickening servers. And, if you want to connect to a specific room, you are going to use one of several specific second meeting servers. So the servers don't really need to communicate with each other more.
This is set to the client site now, the client decides which seconding server they are going to decide to use. And, yeah, this, this allows you to not set up some complex server environment where you need to have renders or pops up node that is, that you need to scale to many instances. If you have a large application.
Now you can just connect to many sickening servers and hopefully one of them is reachable by all the clients and, yeah, this is how they are going to exchange their data.
Preston So: [00:21:57] That's really wonderful. And, and you know, one of the things I did want to want to call out is that what you see is something that, you know, as you mentioned, Kevin has been historically used primarily in conferencing solutions. but it's also used in places like a web torrent. you know, that protocol, some of these really interesting peer to peer technologies.
but I guess I'm really curious about one thing. you know, we've talked a little bit about how signaling and why we have RTC works. is there any sort of maximum number of peers or what are some of the limitations of, why of our TC and how many peers or, or, or how much, you know, how, how, how many people can be connected at the same time?
Kevin Jahns: [00:22:40] Yeah. yeah. So what happens when you create a session between many peers, they all connect to each other. So, naturally this might be a huge network. So if you have 20 people that are working on the same document, you're going to connect to 20 people and they are being, going to be a lot of connections.
It is completely fine if one of the connections fails, because the document updates are going to be forwarded through all the peers. As long as this network is connected with each other. So, something that you don't want is that this network is going to be split into two networks, but both networks are connected to the same room.
so this is something that you want to avoid because I'll send you agreeing to fragment your document. this is why by default, all the connections are just connected to each other. this is the simplest solution to that, and it usually scales where well. And, easily are up until, 20 or 30 peers or so, on a mobile device, it might be even less because I'm doing that on a mobile connection, might impose some more restrictions and might be slower.
but all you need is one peer that is connected to all the other peers. And then you are going to receive all the data. so I would say like, don't have don't plan to have more than 20 or 30 connections, for why webRTC. This is basically the limitation, maybe in the future, we can optimize that, but I'm not sure.
because you need to make sure that all the peers are somehow connected with each other,
Fabian Franz: [00:24:26] speaking off, connected or to each other. And . That's an interesting question. So let's say, Michael is in America. We are here in Europe and we are, always as a, his whole marketing team. And, we are also collaborating together.
So we are collaborating together across the ocean and Nelson someone that's that's huge cable. There are moments. Or if a fish is having a bite, whatever. so now we have like this petition, where they are working on the document. We are working on document, but we are not no longer connected, even if we all connect to each other.
we are no longer connected. So, I haven't bought Yjs was at once the connection
Kevin Jahns: [00:25:16] established. I'm sorry, can you repeat that question? Like the problem that occurs in this
Fabian Franz: [00:25:24] scenario, basically the network petition, there's three people in America and two people in Europe that are working on things together.
And, so now, you make updates. I make updates each T our updates obviously, and they also make updates and they all see the updates. And now. We get reconnected because the cable gets fixed. how does by chance do you have a set
Kevin Jahns: [00:25:50] case? Okay. Yeah. so as soon as one client from one petition connects to the other client, from the other connection petition, they, they are going to sync their content with each other.
This is what, Yjs is all about it can sync everything. It can always think. if you have, if you petition, like if you, in America, you created like this huge document. And, in Germany we created like a different document that looks very different and has stuff, different typos. then you are going to sink and this thing might not make a lot of sense.
So you want to make sure that. the timeout between the, like when the fragmentation is solved, it's not too long. otherwise it might be really weird if at some point, Oh, wow. There's a lot of content apparently, but, it will just sink as soon as a petition petitions are somehow connected to each
Fabian Franz: [00:26:51] other saying I could problem.
And for example, I mean, we both sat here in Europe and, Yeah. And then, I assume all of Michael changes and you also sync all of Michael's changes, but I'm a little bit quicker just thinking my changes. And then I'm sending my changes that have seemed already to, to you already put the gift flag as SIM storm or something.
and how do you,
Kevin Jahns: [00:27:18] yeah. that's, that's a good question. Like for white S it's actually not a big problem. So, obviously there's a lot of deep data that might be transmitted. So when you have two huge petitions, like 10 clients on the one side and 10 clients on the other side, and then you just receive 10 clients at the same time and you think was 10 clients, like synchronously.
well, you were received the same data 10 times, but, why'd you as will recognize, okay, this is a duplicate of the content that I already received, so I don't have to apply to my document. And, this is something that is very important because, you will receive applicants all the time. Even with using the web socket connection.
Every time you make an update, the server will sent the update back to you or another client that is somehow differently connected. We'll also send the client, the update to you. but because each update or like each character we talked about this before is uniquely identified. We always know, Oh, that, okay.
I received this character, but this ID is already defined. So I can just throw it away. I already applied the update, right? So that's no problem.
Michael Meyers: [00:28:44] Kevin is this peer to peer cap, specific to collaborators. So for example, let's say, you know, we're, we're editing a document together as a group and we have 40 people.
can it be 20 people that are editing in 20 people that are, that are just watching? Like, is there a cap on the number of Watchers?
Kevin Jahns: [00:29:05] Nope. It's so they all should be connected to each other. So, it's, it's not, it's not like that and who will docs? I know it's exactly like that. You can have like 10 or 20 collaborators on the same document, but, if you have more than that, there's a fixed number.
If you have more than that fixed number, they can only view the document. Until a certain degree. And then even that breaks up, then you can always see 'em updates on the document, like flashes of content. so this is how it was like two years ago when I checked this. so in, in, why webRTC, this would be the same, until certain degree, and then you might get into trouble because, you shouldn't have too many connections open at some point, the browser will say, okay, I won't take any more connections.
I think at 120 connection, also the, in Chrome, at least it will just say I can't accept anymore and it will throw errors. but. If you are lucky, the connections are still somehow alive and there is no fragmentation. So this will still work, although it is not recommended. if you really want to have huge number of collaborators, you should use a central server or some other approach for that.
For example, why web socket really scales well with a lot of users? And you can also optimize this, just use why webRTC until the cap of 30 users, and then maybe connect to us a web socket server. but yeah, this problem hasn't been solved yet.
Michael Meyers: [00:30:51] I would say for most use cases, 30 active collaborators is, is sufficient.
And like you said, if you do have a case where you need a large number, you can always scale back to a centralized server model for that specific instance.
Fabian Franz: [00:31:04] Yeah. Also it's of course would be possible to have a different algorithm for us. It would be additional work and it's not implemented right now, but if someone really wants to do it, no one would stop him from just having a signaling server, which allows to select any peer.
And just listen to the updates as peer PS giving basically. And because every update is sent to everyone. so you can just listen to any peer and then you have like 20 people actively collaborating and then every one of those has one additional connection to one viewer. So let's definitely, if connection gets lost, obviously you need to select someone else, some other collaborator.
So it's technically possible just not implemented.
Michael Meyers: [00:31:48] So I just, for clarification, this is on a single document. So let's say I'm a large media company, like a newspaper. And I have lots of authors writing, lots of documents. Each individual document can have 20, 30 collaborators. so as an organization, we could have hundreds or thousands of people collaborating simultaneously on different documents.
It's just a single document cap of that.
Kevin Jahns: [00:32:15] Right. Exactly. Like this is only limited to the same document. And usually this is enough. You don't want to collaborate with more than 30 people. This won't be product.
Fabian Franz: [00:32:25] Also, if you are, if you are a really huge media company, I guess you might have some money for a few shares.
Kevin Jahns: [00:32:35] Ah, that's true. I mean, where RTC is, it's really cool, but if you really want to have, Secure connection is if you really want to make sure that the clients are able to reach and share the data you want to use wide web sockets. Right. But if you interested in using serverless applications, like don't have, you don't really need to set up anything for this collaborative approach.
If you want to have collaboration as a drop in feature for your product. Use why, why RTC? Because why not? Because before it was non-collaborative and now you have why you have webRTC support in all browsers. It will like most of the time it will just work. And if you run into troubles, you have too many features.
It's still better than having no calibration at all. Right.
Fabian Franz: [00:33:27] The majority
Michael Meyers: [00:33:28] of Drupal users or WordPress users are the long tail, you know, millions of websites that are run by individuals. So the power of this is that, you know, if Drupal or WordPress were to support this, as someone with, you know, a personal Drupal site, I could have collaboration with peers without having to add any software to my application.
It would all be included in the distribution. That's what this enables.
Kevin Jahns: [00:33:57] Yeah. Yes,
Fabian Franz: [00:33:59] exactly. This is exactly what you download the Drupal module. You have to special editorial that by jails and abled, as we've talked before, you need a special editor for it. For example, has asked that are available right now.
And, then, you basically just enabled this module. Use monitor public signaling server, but you would configure in the module and basically you would start your document. It will connect to the signaling cells, server and someone else, but also in the same document, nature, sickening server and overcame because after the signaling server has connected as to you, there's nothing more for it to do.
And we will be collaborating like if we had a central, so. Yeah,
Preston So: [00:34:50] that's pretty
Michael Meyers: [00:34:51] mind blowing. I mean, literally any CMS or any type of application out there could implement this very quickly, with minimal overhead.
Kevin Jahns: [00:35:01] Alright. and, yeah, I mean, this assumes that there's public server as well. Like it's always available.
I would be interested in setting up an organization to just scale these Publix instances so we can have more users as it support that. Another option that we might want to take is like, if we might be able to implement, the server implementation in other languages like PHP, that would be really interesting to me.
Just support this signaling in the server directly. cause the sickening server at this time, it's 100 lines of code, right? That's yeah. And easily do that in any language, just we implement the approach. And, one doc, you can have it, the whole approach, like the signaling, collaboration, everything on your site.
And it will also work in intranets. and if it doesn't work, it's still better than before
Fabian Franz: [00:36:02] I think this, I think this is a time where CGI bin slash pur let's shine again. No, just, actually for, for things like, PHP there's techniques available to the signaling server, for example, long polling, where you're basically using one connection very long.
And as soon as data arrives, it gets threatened too. You can also use frequent poles, Bittrex amazingly. Well, all of us things like, varnish, for example, Or or any CMS Asti. So, that's an amazingly efficient way to keep your own also server, because as soon as your data expires, there's for example, a new client, you just expire it and it gets fetched once, but it's a server and I'm supporting this actually way more feasible than it was 10 years ago.
As soon as you use something like modernish possibly. Even cloud flare out on its more advanced tiers, et cetera, because you can read it. No even carcinoma would work because it just needs cash tax or cash and validation. And you basically can have six signs, pull it every 10 seconds. Every one second is no big deal.
All of the ads. and, we'll just get one request once a data, Expires. And that's a very, very cool way from when polling today in 2020, that is actually, not as well, used, because many people are kind of like said, Oh, is bad, has been, Betty works amazing. Well, as soon as you put a CDN on it, so that's another alternative.
Just have a very simple pitch, peak time push some cm CDN before it. And, X player, the cash, as soon as the data updates and you have almost real time signaling without any overhead on the server. Right.
Kevin Jahns: [00:38:06] You should
Fabian Franz: [00:38:07] post about that. This is cool.
Kevin Jahns: [00:38:09] Yeah. Interesting. I mean, there are so many ways to scale that I would be interested in exploring this whole field.
I mean, I just want to say web sockets are also super supported in a PHP. I hear here. but long polling is also a very viable option. I know that a lot of applications, a lot of, software prefers a long polling instead of web sockets. another thing that you could do is, somebody brought up that up in the WordPress, GitHub organization.
I think I, you could use, the pinks that you always sent to the server to, Like when you open a word, it couldn't book site, for example, you send pings and intervals to the server. Something that you could do is you could make it sure that, if a client it's to connect to you, you just append some information, like the session description information to this thing, right.
Just leverage the pink. I, some information to it because at something that you do anyways, so why not combine that?
Fabian Franz: [00:39:21] Yeah, definitely. But as aspect, short polling is also very valuable in that. And I'm always, it depends also on your mind. I like, because this polling approach is only used for the actors documents where you are, you are actually on, basically even if you ping every second, but you have to large the scale service somewhere.
it, it might not even matter in, in the, whole wheel of saints. Because, really, you only, only if you're really edit the document bills is polling half men who cast obsess every five seconds. For two, we use problems. We problem this polling and all those sayings and baths. Then the WebSockets really shine as when you have
We have polling and Bronco really does not scale anymore.
Kevin Jahns: [00:40:17] Right. That's true. I mean, and if that doesn't work anymore, if you really have a huge application, if you really need it, you can always switch to any other protocols. So this should be, supported, like use, the web socket server, if you really need it.
and it should be easily scalable. Right? so yeah, many opportunities, everything is exchangeable and it's a perfect drop and replacement. A drop in feature. if you want to enable calibration in your application, it's always better than before. Like in my opinion, without like it's better than without collaboration.
Another thing that I want to bring up is here, the mesh support. I think we talked about this some time. so, why jazz collaborates like exchanges, they document updates. Using, a broadcast channel, which is a browser API to communicate to other tabs, something that Y webRTC does it, it manages these connections to the other tabs.
And if you're, if you have this in another tab, you won't create another, what artistic see connection to the other chap. so this is one of the cool features. You can also combine this by using other wide U S providers. For example, if you want to have webRTC, and then at some point in the middle or at the beginning of the session, you decide, I also want to use another protocol, for example, why debt, which is support for the debt, communication layer, or if you want to use a web socket.
You can also support WebSockets and share your data over peer to peer webRTC and web sockets and the debt protocol, and just hope that anything of that works. So, this is another new feature that I implemented that all of this is Mashable. I would be interested in, in supporting Bluetooth connections to, just for the heck of it.
If you find, if you open your phone and, you want to collaborate, the first thing that you could do is crabby. If there's another device that supports why'd you and I exchange the data using Bluetooth, because why not? It's measurable. And it will also work while you are not connected to the internet anymore.
Because it's Bluetooth, it works locally, right? this might be awesome. Or conferences where, I have this one conference where I wanted to show why jazz. And, of course it failed because there was no connection or it didn't work because we didn't have the bandwidth to support all these devices, like 150 people accessing the same server through the university network.
So I thought, man, it would be awesome if there was some physical way to transmit the data and, well, looking forward to why Bluetooth, peer to peer connection through, through a Bluetooth, coming in 2021, lots of opportunities here.
Yeah.
Preston So: [00:43:42] Wonderful. Well, we are just about out of time here and I want to say first and foremost, thank you so much to Kevin and Fabian and Michael for joining us today. One quick, last thing, Kevin, where should people go if they want to learn about why webRTC, is there a demo available of this as well that, we can try out and play around with.
Kevin Jahns: [00:44:03] Yeah, go to dot Def. There's several demos. The website uses web sockets and webRTC. Now I just do that to find out how many peers I can support with a webRTC. So, so, just open it on a lot of devices and, Let's see what happens. so, another thing go to the GitHub repo, guitar shop, dot com slash wide U S it's the watches organization find out about all the connectors that we support or the, editors that we support.
And, yeah, I'm looking forward to more Tag1 talks, especially look at the first two, three, Tag1 talks about collaboration. using watch S to find out more and, please ask any questions in the, get in the discussion board, discuss, thought why'd you stop Def there, are there some people and helping you out, if you have any questions, any suggestions on the website, if you want to see a specific application, you have an application developed and you want to show it off, please post it there.
Preston So: [00:45:21] Wonderful. Well, thank you so much. And just as a reminder to our audience, thank you once again for joining us for this Tag1 Team Talk. Tag1 Team Talks is the series about emerging web technologies, consisting of webinars and podcasts about some of the most fascinating technologies on the bleeding edge of the web.
By the way we post all of these talks at. Tag1.com/tagteamtalks. And all the links we mentioned today will be included and posted online with the talk wherever you're looking. And if you liked this talk as with every single Tag1 team talk, please remember to upvote subscribe and then share it with all your friends and family.
As always, we love your feedback and any suggestions, if you want to hear about a particular topic, if you want to bring Kevin back, if you want to bring avian back more often, we'd love your topic suggestions, please. Write to us at tagteamtalks@tag1consulting.com. Once again, a real fond thank you to Michael, Kevin, and to Fabian.
Always a great time to see, you know, to see you at the hangout. And I'm looking forward to the next one of these as well. Take care. Thank you.