Hey everybody, welcome back to Magic Orthodoxy. My name is David and this is a deck review. Today we're going to look at the Purple Limited Deck from Illusionist.com and Peter McKinnon. What is the Purple Limited Deck? Well, after the success of the Limited Edition Red, Illusionist sat down and discussed the possibility of actually making an unlimited version. After going back and forth, they came up with Blue. So, Blue came out in early 2013 and you might remember I did a review for that a long time ago. So, even after Blue came out, Peter still felt like he wanted to have another color. And so, Purple was kind of like his vision in having that come to life. And so, now Purple is available. It has Peter McKinnon's signature on the tux flap, kind of like as an homage to him because he's the creator. But it still contains all the qualities of the original LTD that we all liked. So, very subtle, dignified diamond back, really thin white borders and a crisp, buttery finish. The tux case is all purple, wrapped all the way around with no words or design at all. It just has LTD right there on the front and you'll see some sort of like, kind of a paisley decoration there in the back. The tux top is completely blank. The bottom has some ad copy about Illusionist.com. There's that Peter McKinnon signature we all know and love. And that is it for the tux case. Let's take a look at these cards. These cards are printed from the United States playing card company and they do come on a retail stock. They do have a standard cut and air cushion and boss. And if you'd like to learn more about stock, cut, or finish, you can click the link below in the description. Everybody always asks how cards feel, how they handle, how they perform, yada yada yada. If you'd like to know how they feel, you can click a link below in the description that kind of tells you where these cards fall as compared to other decks. And so, when I measured these, they were kind of a middle of the road stock. They're not really heavy and thick like a casino deck. They're not buttery soft like maybe the newer Roadhouse decks. So it's kind of in the middle there. You can check the website and it will show you some other decks that are comparable to it. The back of the card is very simple and it does, I believe, have the best of both worlds. It has a repeating pattern that gets pushed to the edge of its frame. So it does kind of have a casino look to it, but it also has a thick white border which makes it more like a poker deck. And you'll also notice it has a thin pencil line border around that. Pretty much the main color there is purple like the other LTD decks. And so if you do have the other LTD decks, this is a great one to add to your collection. With this deck, you're going to get a couple of extras. You're going to get an illusionist ad card. And you'll get a double backer which is great for magic tricks. Pete McKinnon's Ace of Spades is pretty simple. It's a line drawing, ink drawing of a standard pip spade, but kind of done like a calligraphy pen would draw it. And then underneath that, it does say limited. With this deck, you'll also get two identical jokers. It's a marionette hand floating above a J that has a purple top, and it does say joker underneath that. The purple limited deck also has Madison courts. And so if you're familiar with some of the Madison decks, you're going to find Daniel Madison, Pete McKinnon, a lot of their best friends, a lot of their girlfriends, and some other fellow magicians. The Pips and Indice cards are going to feel and look completely standard. The red cards have a more deeper hue to them, and the black cards are a deep silver. And if you'd like to purchase the purple limited deck, you can find it right now at illusionist.com. All right, so that is my review of the purple limited deck from illusionist.com and Pete McKinnon. As always, recommend that you like this video just so other people can find it faster. We also recommend that you subscribe to this channel just to stay up to date on all of these cards and card magic. If you want to follow me on social media, you can. I'm at facebook.com. Twitter.com. Instagram.com. And if you need more content, you can always find it at magicorthodoxy.com.


Is CLS fast yet? And I'm going to give the answer right off the get go. And the answer is yes, it is fast enough. And over the past year, I've spent quite a bit of time just looking into the various performance bottlenecks that are out there. And my overall conclusion is there's actually quite a bit of work that we need to do to improve the performance CLS. But it is certainly possible to make it fast. But before we get to the nuts and bolts, let me just state the premise, which is I believe that all communication on the web should be secure by default, which is to say, HPS should be everywhere. And this is for a variety of reasons. Part of it is just protecting the privacy of the users, of the visitors that are coming to a site, but also protecting our sites and services as well, against things like men in the middle and other sorts of attacks. And I won't name any names, but I think we've seen enough news over the course of last year in a bit to motivate why that is so important. So in particular, when we talk about HPS and security and secure by default, we mean three things. Authentication, data integrity, and encryption. I think a lot of times, when you think of HPS, we particularly focus on encryption, which is just making sure that the data is obscured from passive eavesdroppers and things like that. But authentication is obviously important as well, because it protects our services from being impersonated and making sure that the client is, frankly, talking to the server that they claim to be. And data integrity is just protecting the data that's in flight, such that somebody can't modify it. So all of this is well and good, but the common questions that I get is like, great, TLS is good, but this is a performance conference after all. So what about the overhead that TLS adds? First of all, there's the computational cost, right? There's the crypto work, so doesn't that make everything slower? And second, there's all these extra round trips and all this extra stuff. And the bottom line being, this is just going to make my site slower. There's nothing that I can gain here. And my answer to that is there's only one performance problem that TLS has today, and that is that it's not deployed widely enough, and everything else can in fact be optimized. And in fact, there are cases where TLS, believe it or not, can actually yield faster loading pages. And we'll see how and why that is the case in a second. So let's start from the top. There is the CPU and memory concerns, right? The first one is the computational costs. So crypto work is obviously extra CPU cycles on top of serving the web page. And there's two parts, two important parts to establishing a secure tunnel. There is the asymmetric crypto, and there's the symmetric crypto. The asymmetric crypto is what we have when we do the certificate authentication. That's the public private key pair exchange. And that one is on modern hardware is on the order of one millisecond, right? Don't trust the numbers that you see in various blog posts from 2005, 2012. Actually boot up your machine and just run the open SSL speed, SHA and ECDH benchmarks, and you'll get the numbers for your specific hardware, for how many handshakes you can actually do on your machine. In my experience, it's for the asymmetric crypto, it's about on the order of one millisecond. And that is actually the expensive part of this handshake. The symmetric crypto is not a problem, right? Like you can saturate your full nick on a single core, and that is nice and fast. So if you look at the experience of the big sites, the Facebooks, the Googles, the Twitters of the world, you basically find that all of them nowadays run their TLS stacks purely in software. There's no longer a need for dedicated hardware or things like TLS offloading, frankly, because the CPUs have been optimized well enough by this point that the commodity CPUs are just fast enough for this sort of work. Same experience at Google when we enabled TLS, this is Adam Langley, originally this was done for Gmail, and now of course more and more of the Google services are HTTPS only. So you can see that it basically caused a negligible increase in CPU, and we'll actually talk about how we got there. But more importantly, this is something that I didn't appreciate when I first went into this space, is the memory overhead. So if you're juggling a lot of connections on your service, this is definitely something you're gonna be paying attention to, and the 10 kilobyte number is interesting, because as it turns out, once I started doing some research into this, I realized that there's actually quite a bit of overhead per connection. So for example, if you have TLS compression enabled, each connection will require up to an extra megabyte of memory, which of course is a huge amount of overhead.  It is both a security problem if you do, and it also adds a lot of overhead. So the first takeaway here is disabled TLS compression, if you have enabled, because we also have TLS or we also have compression, GZIP compression at HTTP, so really you're not gaining much. You're just doing double compression anyway. So you turn off the compression and nowadays on an optimized, let's say you're using the latest version of OpenSSL and you optimize how your server integrates it, you're gonna be incurring about 100 kilobytes of extra memory for each TLS connection, which is actually quite a bit if you think about it. It's an order of magnitude less than one megabyte, but still quite a bit. Now on Google servers, it turns out that as Adam quoted, as I had Adam's quoted before, we're actually taking about 10 kilobytes. So this was done through a lot of very careful optimization, just taking out things that we don't need. But this just shows you that there is a lot more to be gained by optimizing things like the OpenSSL libraries and all the rest. And we know it's possible because we've done it at Google. Now, I don't know if you guys seen the news, but last week we announced BoringSSL, which I think is an awesome name. Super exciting. So this is basically the OpenSSL fork that we are maintaining or will be maintaining at Google. In the past, we've always maintained our own set of patches on top of OpenSSL for things like improving security, improving performance and other things. And BoringSSL is basically that but done in the public. So this is a new project. Our goal is to actually start using it on Chrome very soon, also to incorporate it into Android. And I'm not sure if some of the memory optimizations are gonna make it into this project, but I hope they will. And hopefully this will help everybody else as well in terms of improving performance and other things. And just improving OpenSSL in general. So the other big thing is, of course, keep alive and session resumption. So part of the reason why you see negligible increase in CPU usage on the server is because you have to optimize for things like keep alive and session resumption. Once again, recall that the expensive part is the asymmetric crypto, which is that original handshake. So you want to minimize the number of handshakes. And you do that by using HCP Keep Alive, which means you use the same connection for multiple requests. And session resumption actually allows you to reuse previously negotiated parameters to avoid that handshake entirely. So let's do a quick recap of what resumption is. First, you establish a session, you verify the certificate, and then a client and server negotiate which Cypher suite they're going to be using. We can actually remember those settings. And the next time you come along, you say, hey, we've talked before and these are the parameters that we used last time. So let's just start with that. And the server can resume that. And the important part here is we skip the asymmetric crypto entirely, which allows you to actually save an entire round trip and eliminate that CPU overhead. So this is actually very important because it allows you to do a one RTT connection establishment with TLS. And there are two mechanisms by which you actually do this. There is the session identifiers and then there's session tickets. So session identifiers is the older standard, if you will. And the idea here is that the server assigns an ID to the client and then the client just sends back that ID. It's just an opaque string, right? The server then looks it up, looks up the parameters of that session and some sort of a cache and reuses that. By comparison, session tickets or by contrast, session tickets actually encodes all of the information into a ticket, encrypts it and sends it to the client, sets it to the client. So the big difference is where that data is stored. And session tickets is often preferred because session identifiers require some sort of a shared cache, right? Imagine you have a multi-server deployment and I'm sending you a session ID. Now you need to take that session ID, you look up the parameters, decode it and do all that kind of work. So session tickets are much easier to deploy in that sense. And most, or all I should say, modern browsers support both. So a quick way to test this is to just open up OpenSSL. You can use SClient and just try it on your own site. So here's an example with example.com and basically you're looking for session ID. This is that session identifier, right? So the data is actually stored on the server as to what parameters we used. And if your server supports session tickets, in this case, you can see that the session ticket is valid for 600 seconds. That data will be passed in here as well. So this is a very quick and easy way to test this sort of thing. So one thing to think about, deploying session resumption actually comes with a lot of caveats when it comes to security. You can optimize for performance, but of course security is very important here as well.  For things like perfect forward secrecy, you want to make sure that as, actually this is a quote from Adam, that the session keys that you're using are never actually persisted anywhere, right? Because the idea behind perfect forward secrecy is that once the session has gone, there's not, you can't recover the keys or you can't recover that past information. So if you're by accident are writing it to disk and doing these other things, or you're forgetting to rotate your keys, then you're not actually providing perfect forward secrecy, which unfortunately is the case for most servers out of the box today. If you just bring up, let's say Nginx and run it, it doesn't automatically rotate your keys. You actually have to set it up on your own and kind of add an extra layer of logic. So this is a good example of something that we need to improve in our servers, whether that's Apache Nginx and in all the rest, frankly. So this is a big gotcha. So if you're deploying this, please do pay attention to it. And Adam Langley actually on his blog, Imperial Violet, has great information about things you should watch out for. So you can see the link at the bottom here and I'll share the slides, the link to the slides later as well. So that's a little bit about the CPU and memory. Let's talk about latency, because after all, there's all these extra round trips. So just a quick one-on-one on the basic TLS handshake. This is the textbook version of the TLS handshake, right? We start with semi-a-certificate because I need to authenticate the server. The server returns a certificate, you do your public key crypto, you then negotiate the symmetric key and the symmetric cipher that you want to use. And once you've agreed to all that, you start sending application data. So really, this takes two RTTs on top of your TLS handshake. And after those two RTTs, you can send encrypted app data. So that's the textbook version. Turns out that we can do much, much better. First of all, the first thing you can do to improve the performance of TLS handshake is to just reduce the RTT. And that's where CDN comes in, right? I think CDNs are, they're obviously great for delivering static content, but they're very useful for improving performance of TLS as well. So the closer you can terminate your connection, the better the performance is going to be, both for TCP and the TLS handshake. So anything you can do basically to reduce that round trip time for the handshake is gonna pay off in dividends. Now, that said, before you hand over your keys to the castle, right, make sure that your CDN performance with TLS is actually good. I won't name any names, at least at this point, but not all CDNs do a good job of TLS performance. And we'll come back to that in a second. So if you recall the textbook version of the two RTT handshake, that's in theory. In practice, you can actually screw it up and make it much, much worse. So one example is the online certificate status protocol, which is great, you've given me the certificate, but is it still valid? How do I know if it's still valid? Has it been revoked? So we have this protocol called OCSP where in this example, loadingwellsfargo.com, this is done in Firefox. It gives me the certificate and then it pauses and then it actually says, well, hold on a second. I need to check with Verisign if this is still a valid certificate. So I'm gonna create a new connection. I'm gonna incur the DNS lookup, the TCP connection handshake and send the request and get the response before it can proceed. And only once I get the 200 or the success criteria is met for that specific certificate, well, I resume that connection. So that's a problem. And of course, in this particular case, Wellsfargo actually uses two CDNs. So they actually get Zing twice on Verisign and GeoTrust. So they're hurting themselves in kind of magnificent ways here. Now, here's an interesting thing. The OCSP check is actually not done over a TLS connection itself, which should raise a few warning flags, right? What happens if that gets hijacked? Well, there's a number of different problems with OCSP protocol in general and I encourage you to actually check out this post once again by Adam Langley why revocation still doesn't work and why the OCSP protocol is broken. We don't actually have necessarily better solution at this point, but we know that there's a number of problems with this process. So because of that, Chrome doesn't actually block on OCSP checks. Some other browsers like Firefox do. So they will always do the live OCSP check and they will cache it, which is the good news, but that can still slow down your site for a while. So the behavior varies by browser. And if you open up the certificate panel in Chrome or another browser, you can actually see what the endpoint is and kind of you can query it and find out what the latency of these OCSP checks are. In practice, they're actually pretty bad. They're on the order of a couple of hundred milliseconds. So the response time is not that great. So the solution to this is to actually use OCSP stapling. And the idea here is that, look, the browser needs to do the revocation check, but instead of doing a live check where I pause and I go to the server, the server is responsible for fetching the status, stapling it to the actual certificate and providing it to you when you ask for the certificate. And that stapled response is signed by the CA. So there's no way for me to fake that stapling. So this is an important optimization that you can apply today on your servers to basically eliminate that extra latency, which is gonna hurt quite a few users. So once again, you can test for this. You're just using SClient. So if you pick your favorite site, you can actually see if they're using OCSP stapling because if they are, you will see this OCSP response data field in your output here. So stapled OCSP removes that extra blocking. But there's another problem here is that we have our certificate. We've added the OCSP response. Now we've increased the size of the certificate. So next thing to think about is actually the size of your certificate. For a lot of sites that I've looked at, a lot of popular sites, the two RTT handshake is actually a great example. In reality, they have three RTT or four RTT handshakes for a couple of different reasons. One reason is their certificate chain is actually large enough. Or it's too large, rather. It turns out that an average certificate chain is about two to three certificates. You need your site certificate, you need an intermediary and you need your CA or some extra layers in there in between. Each one of those is about anywhere from one to 1.5 kilobytes on average. You add the OCSP response and oftentimes you end up over four kilobytes. Now four kilobytes doesn't seem like much, but when you just open the new TCP connection, that can actually be a problem on old servers because we had that four kilobyte threshold for the first congestion window. And oftentimes when you hear the, you need to optimize and reduce the size of your certificate chain, this is why. Because if you overflow that window, you will add an extra RTT. So if you haven't upgraded your servers to use the latest TCP congestion window, which is 10 packets, that's definitely a problem. But even once you have, I've discovered that there's another problem which is a lot of servers have buggy implementations where, well, I consider it a bug, maybe they consider it a feature, where they will actually pause unintentionally, even though your server is using the latest congestion window, they will send the first four kilobytes of the certificate and then they'll just pause and wait for an act to arrive and then it will send the rest. And there's lots of examples of popular servers doing this. So for example, Nginx up until version 1.56 was doing exactly this. HAProxy and others had this problem as well. So in this particular case, if you just eyeball this thing, it's doing a three and a half RTT handshake, that was actually the problem. So please do check your servers. The best way to do this is to just run the TCP dump or use web page test, click the TCP dump option and then look at this connect time and look at the traces. So once you've done all of that, we can actually make things even faster. So we have this feature called TLS false start. It turns out that when I showed you that two RTT handshake, we don't actually need to wait to send application data until we've finished the entire handshake. At the moment that the client has chosen a preferred Cypher suite, it can actually append data at the end of it, application data and just use that Cypher suite that it chosen before it gets the acknowledgement from the server. So this is slightly optimistic, but it turns out that it's actually allowed by the protocol. So this is not a new protocol extension, this is just working with the confines of the existing protocol. That said, there's been a couple of problems with deploying this in the real world.  So because of that, TLS false start is not enabled by default. Instead, it is used as a carrot for you to deploy new and correctly implemented servers. So to explain what I mean, different browsers have different conditions when they will enable false start. For example, Chrome and Firefox require that your server advertises NPN and ALPN extensions, which are basically just saying I support these protocols. Now, if you've been following speedy and HP2, you're probably familiar with both of these and you're thinking like, what does that mean I need to have HP2? No, you don't. You can just advertise that you're supporting HP1.1. Basically, all we look for is like, do you support ALPN? Because if you do, that's a hint to us that you're running a modern server that's probably implementing other things correctly. So that's step number one. And second step, and this is kind of the carrot for, if you want good performance, we want you to implement good security. We want you to implement forward secrecy. So you need to meet those two conditions and then Chrome and Firefox will use false start. Safari only requires forward secrecy and Internet Explorer actually has kind of an optimistic behaviour where they will try by default to use false start and then if it fails, they'll retry without it. So it's a combination of these two things. But the takeaway here is to get good support across all the browsers, you need to enable NPN or LPN and forward secrecy. So please do that because that'll eliminate an extra RTT. So the quick summary of all of this is you can actually achieve one RTT handshakes. It's not a two RTT, it's not like, if you have more than two RTTs, that is a bug, but you can actually do better than two RTTs. False start allows us to deliver one RTT handshakes to new visitors. So this means that you haven't come to our site before, we've not negotiated anything before, but you can still reliably deliver one RTT handshake. And session resumption allows us to do a one RTT handshake and also skip the expensive asymmetric crypto part. So basically the summary of this is you can reliably deliver a one RTT handshake on your servers to both returning and new visitors. And you should also implement things like OCSP stapling to avoid that extra blocking overhead that I showed you earlier. And by combining all those three things, you get much, much better performance. So one RTT handshake is where it's at. So having said all that, what's wrong with this picture? So first of all, hopefully by this point, you're looking at this graph and if you're not familiar with the webpage test colors, purple is the TLS handshake. So you should be eyeballing this and saying, look, this looks like our two RTT handshake. So right off the bat, I know that I can do better because we can do a one RTT handshake. We need to enable the things that we just discussed. But second is the green and blue. So at the top here, we have the HTTP site and at the bottom, we have the same site but loaded over HTTPS. With HTTP, we have one RTT and this is the time to first bite. That's the green part. And then this is the content download time. Here, we have the green part that's spanning two RTTs. Why is that? So it's your RTT handshake and this is a problem with TLS record size. So let's talk about that. When TLS packages up data, it actually takes a buffer of data and it emits a record, right? Which actually has a check sum at the end and that record is allowed to be up to 16 kilobytes in size. So by default, if let's say you have a well-optimized whatever engine X server and you're serving static data, it'll be more than happy to create 16 kilobytes records because that actually allows it to reduce the amount of overhead that it needs to do to create that record. But the problem with it is to deliver 16 kilobytes record, it's actually split across many different TCP packets, right? And on the new TCP connection, it will actually overflow the initial congestion window which will add yet another RTT. So that's a problem. And in this case, you're actually looking at a Wireshark trace which shows you that this particular record was 11 kilobytes and it was split across eight different TCP packets. And what happens if one of those TCP packets gets lost or is being retransmitted or it's delayed? Well, we can't decode the entire record, right? Because we need to run the check sum before we can decode the record. So that's a problem. And as far as I'm aware, Google servers are the only servers that are implementing a smart strategy to mitigate this problem. And I hope this is something we can fix in all of our open source and other servers as well. So what we do at Google is we start every connection with small record size, basically we fit our records into one packet which allows us to ensure that when the connection's fresh you're always able to decode data without buffering it. And then over time, of course, pushing these small packets, small records adds extra overhead. So we don't wanna do that. For streaming a large video, think of something like YouTube. We want to actually make use of larger records. We will do that after the connection's been established and we're streaming a large amount of data. And then we just reset it once the connection becomes idle. So very simple strategy, but it actually works really, really well. And I've been working with Willie who's working on HAProxy and we recently actually added the support in HAProxy which is I think really awesome. And I've been bugging the nginx team to do the same and they haven't implemented the dynamic record size but they've added the ability for you to specify a static record size. So you can say, I want all of my records to not exceed four kilobytes, for example, which is kind of like a nice in-between solution but I think we can definitely do better. So the takeaway here is there's no perfect record size.  But there's a mix that we need in-between. So all of this is great, right? Like lots of optimizations that we comply. So let's actually take a look at how our servers perform in practice. So I ran this test and I'm gonna pick on nginx here. nginx is being used by a lot of high profile sites. So I just took the, at the time this was the stable build of nginx 1.44 and this is the same site across different versions of nginx. So at the top here, you see just the same site delivered over regular HTTP connection. Then I enabled TLS and as you can see all of a sudden we've added like three and a half RTTs for no reason. Turns out that they actually had that buggy implementation that I told you earlier where a large record size, they would wait for the large record after four kilobytes. So just upgrading the server to 157 eliminated an entire extra round trip. So if you're running an old version of nginx, please fix this. That'll already when you back a lot of time. If you then add that extra flag for SSL buffer size, so this was introduced in 1.71, right here we're actually saying, look, I want to serve records that are no larger than four kilobytes which will allow me to avoid buffering on a new connection. This returns yet another RTT on our performance budget because we're able to start parsing the HTML much earlier in the browser. And then finally, once you enable false start, we can reduce it down to one RTT, right? So unfortunately, the bad part of the story is that if you just enable TLS without much thinking, without much optimization, this is probably the picture you're gonna get. And this is bad because it's basically, you're going from 1.5 to almost three seconds. So it's like, great, I made my site twice as slow. And, but after you do all that extra kind of work and optimization, you can get it down to one extra RTT. So I think we just need to make this much easier and we need to provide a much better experience out of the box for all of these servers.  What is the support across the different implementations? And unfortunately, there's not a single server that is completely green. Nginx is in a fairly good shape. The only thing that's missing here is this dynamic record sizing, which I was describing earlier, but at least it allows you to provide static implementation. Things like servers like Apache definitely need some help because right now they don't actually even support NPN, which means that even if you advertise a perfect forward secrecy or you enable that, you won't get false start. So depending on what you're using, this is something worth investigating and certainly worth bugging the implementers to say, hey, we need to fix this. Now, here's the real scary part. Once I did the testing on the different servers, I figured, hey, why not test all the different CDNs as well? And what scared me about this is the sea of red, right? I mean, there's some particularly bad examples that stand out here, things like CloudFront, which apparently don't support anything short of session tickets, but the good news is after I've published this, a number of CDNs have already started kind of reprioritizing things and they've actually made this grid greener since I've published it, which is great. So I think we just need more attention on this, right? So when I said earlier, don't just hand over the keys to your kingdom because frankly, some of the CDNs don't actually support the features that we're discussing here. So once again, please bug your CDNs about implementing this sort of thing. So I actually have a summary of the previous couple of tables and a lot more technical information for how to configure the different options that we've discussed on istlsfastia.com. So it's online, it's open source, you're welcome to contribute if you have any other tips in terms of performance optimizations. You want to add an extra CDN, so please send me a full request and I'll be happy to update it. But check out this resource for kind of hands-on information for how to make TLS faster. And then the other part of course is HP2 and speedy. So in my head, those two things are the same. HP2 is the evolution of speedy and I think that the part that's not appreciated enough about HP2 at this point is it may actually reduce the operational costs in some cases. So why is that? In practice, it turns out that you need TLS to deploy HP2 and speedy. There's a variety of reasons for that, intermediaries, proxies and other things, but practically speaking, Chrome and Firefox will only use or will only support speedy and HP2 over TLS. So by enabling TLS, you already get one step closer to enabling speedy and HP2. That's gonna be a requirement anyway. It's just something to think about. But the great part about both of these protocols is that they actually, one of the core premises is that they try to use fewer connections. In fact, they try to use a single connection to deliver all the resources. And that actually helps us quite a bit because it reduces the number of handshakes that we need to do, right? And fewer number of handshakes means, rather fewer number of connections means fewer handshakes, fewer memory buffers, fewer everything, right? So here's some numbers from a couple of Google services where we're comparing HTTPS performance to HTTPS with speedy, or I guess speedy in particular. And you can see that these are significant improvements in page load times for these services. But further, if you actually run some load tests, you will actually find that if you simulate the same workload with HTTPS and HTTPS speedy, you'll actually get fewer connections and you'll consume fewer resources. So operations-wise, it may actually be the case that you may see a decrease in usage on your servers when you deploy speedy with TLS, which I think is really, really awesome. And HTTP2, same thing. So as a summary, I think my conclusion here is that you can actually deliver a one RTT handshake. So your goal should be to deliver a one RTT handshake with TLS. There's basically no excuse at this point to do a two RTT or worse. And to achieve that, you need several things. You need false start, which means you need NPN and you need forward secrecy. You need TLS resumption because you want to mitigate the cost of the asymmetric crypto.  You want to make sure that you're not pausing on the OCSP checks or blocking the browser. And when you put all those things together, you have your reliable one RTT handshake, which is awesome. And then after that, you also need to optimize your data delivery. So this is tuning things like your record size. If you can make sure that you're always, you're not essentially blocking on new connections or overflowing the congestion window. That's very important. And finally, once you have TLS deployed, you're almost there for deploying speedy in HTTP2. That's probably the biggest operational hurdle for a lot of people towards deploying speedy in HTTP2. And then you can actually reduce latency and ops costs. So it'll make both the client faster and the servers faster as well. So those are all great wins. And with that, you can find the slides at Fast TLS. And once again, check out istlsfastyet.com for more and more hands-on information on how to make this stuff fast. And I'm not sure how we're doing for time, but we'll take some questions. Three minutes, all right. And you know what, I can't see because we have bright lights. So why don't you just, there we go. I encourage people to come up to the mic if they'll be faster, or you won't have to repeat. So I'll go ahead and start. At the very beginning, you mentioned TLS compression, which seemed pretty simple and straightforward. But then like in these summary tables, you didn't mention it. Is it already done a lot? Or is it, you know, not possible to do or hard to do? So TLS supports compression at the protocol level.  So that's reason number one. And two, we have compression at HTTP level but things like GZIP. So basically you end up doing double layer of compression. So you just want to disable it outright on your servers because sometimes some servers have it enabled because it seems like a right thing to do. It's like compression. Yes, of course I want compression. And then you just end up incurring all the extra memory costs without any benefits. You benchmark sort of mentioned performance at about 100 megabit per second per CPU. What if I have four times 10 gigabit NICs? Which is very realistic. That's what I do today, right? Sure, sure. So how many cores do you have on that server? Say 12, 24. And are you actually saturating those NICs? With HTTP, yes for sure. Using a fraction of the CPUs. So then you may want to look at the size of the actual, the block size, right? Because depending on the block size you can actually optimize for performance there. So do you have any ideas? So what's your list to expect out of this? Can I get 40 gigabit out of these CPUs? I don't know the number right off the top of my head. In the benchmark that I shared, I think I used was it 512 byte blocks? But you can certainly use larger blocks and that'll decrease your overhead. So I'm not sure if you can actually saturate your kind of 10 gig NIC, but I would expect that the answer is yes with enough work. Hi. So I work a lot with mobile app performance and I know that overuse of Keep Alives definitely has a detrimental effect on the handset battery life due to radio over usage. So how does this fit in with what you were saying about using Keep Alives before? So I think there's a distinction to be drawn here which is Keep Alives in the sense that the server or the client periodically pings each other to say like, yes, I'm still there. At TCP Keep Alive just means you don't close the connection, right? So for example, if you take something like Apache, I believe their default today is 15 seconds. So if your client has been idle for 15 seconds, they'll just close the connection. NGINX I think has it set to 60 seconds. And chances are you want the longer lifetime such that you don't end up closing this connection. So if I'm on the page and I'm browsing around and it takes me more than 15 seconds, when I click on the next link, you don't have to re-establish that connection. That doesn't mean it'll keep your radio active because we're not talking about actively pinging the device and saying like, please stay up. So those are two different things. Thank you. Yep. So it's pretty clear that terminating SSL at a CDN has a pretty good performance benefit, but as an advocate for TLS everywhere, what should we do on the other side of that connection? What's the ethical thing to do with CDN to origin? Do we go clear text or is that sort of a misrepresentation of the service? So, well, I think first of all, it depends on your use case, right? But I would recommend that you use HPS connection to the origin. And I think most CDNs today will use things like persistent connections to your origin. So you're not gonna incur that much overhead. And you should be encrypting the data transfer between your CDN because they could be using the public internet to route that as well. It likely is, yeah. Right. So yeah, my recommendation is you should have an HPS connection between the origin and your CDN and then a secure connection from there. And I think most CDNs will support that. If they don't, I would consider that a bug and we should get that on that chart. All right, we're good. Thank you.


this video lecture, I'm going to talk about what are the possible career options that you have in front of you once you clear the NTA UGC NET exam. We all are aware of the fact that NET exam is becoming tough day by day. And now that students have to put so much hard work in order to clear this exam, they all must be worried about the fact that what am I going to do once I clear this exam? Why am I going to put so much effort just to clear the exam and not knowing what are the possible career options after that? So in this video, I'm going to talk about all the possible career options and I'm also going to clear a lot of your myths that you have in your mind in regards to the NTA UGC NET exam. But before I move on to that, I would like to share this amazing news with you. Last week, I participated in the Jaipur Literature Festival, which is India's most biggest literature festival. They claim that it's the biggest literature festival all over the world. But I'm not sure about what are the scenes in the other parts of the country in other different continents. But as far as India is concerned, the Jaipur Literature Festival is the biggest literary show in India. And I was amazed this time to listen to all these great writers. I've been visiting this festival since past 10 years and every time when the writers talk about books and literature and give their perspective about different issues, I feel so good to be in this field of literature. English literature is something which will give you so much more about life. You get to understand so many philosophical things. You get to understand different concepts like what is love? What is religion? What are these gender issues that we're facing every day? It's beautiful. This time, I was amazed to hear Ben Okri, we had Javed Aftar, we had Gulzar, we had Jeri Pinto, we had Devta Patnaya and so many budding writers. So it was a beautiful experience and I would really request you that if you are a literature enthusiast, then book your ticket for the next JLF which is going to happen next year somewhere in the month of January.  We all are aware of the fact that if you want to become a school teacher, you need to have a BF degree. That's the minimum qualification for a school teacher. But what about college professors?  And that is where UGC Net exam comes into play. So what is important for you to understand that there are three streams. We have science, commerce and humanities. The students who want to become professors in the field of science, maybe biology, chemistry, physics, they have to give an exam called CSIR net. Whereas the students who want to become a professor in a field of humanity or in the field of commerce, they have to give UGC Net exam. So both the exams are almost the same. The only thing is that they have divided the streams. So for science, we have CSIR net. Whereas for commerce and for humanities, we have UGC net. Now what is this JRF?  Now what is this JRF? Net stands for national eligibility test. That means once you clear this test, you are qualified to become an assistant professor. Whereas JRF stands for junior research fellowship. Now fellowship means an aid which is provided by government of India for all those who wish to become research scholars who wish to do research in their field. Because it is only through research and development that new ideas come upon the surface and a nation progresses. So because research scholars add a lot to the economic and the educational belt, government of India provides them aid so that they can focus on their research and not worry about the finances. So every month you are going to get about 25,000 rupees once you enroll yourself in a PhD program after you clear JRF. If you look at the education chart of any student in India who is aspiring to become a professor, you will find that the student starts studying at the age of 3 perhaps and he enters in the kindergarten and then he starts to move forward clearing one exam by the other and then he clears his 10th board, then 12th board. After he clears his 12th board, he enters in an undergraduate course. Once he gets his bachelor's degree, he enters in a master's program that is a post-graduate course. After he clears his post-graduate course, he gives this exam net. Now once he gets his net certificate, he has got two possible career options. The first option is that he can study further and the second option is he can directly take up a job. Now we are going to talk about these two career options one by one. So let's first talk about the case in which he wants to study further. Now after he clears net, he has two things in his mind. Either he can directly dive in an MFIL program or else he can dive in a PhD program. Either you can do MFIL and then you can do PhD or you can directly take up a PhD course. Now what is MFIL? MFIL is basically your shorter version of PhD. It is going to give you a glimpse of how PhD takes place. So MFIL takes about two years to complete whereas PhD takes about three to four years to complete. So MFIL is an optional thing. If you want to add another certificate, another degree in your CV, only then go for MFIL or else I would prefer you can directly enroll yourself in a PhD program. Let's talk about PhD mode. Now in case of PhD, you have two options again. Either you can enroll yourself in a full-time PhD course or you can enroll yourself in a part-time PhD course. If you wish to pursue a job simultaneously, then you should definitely go for a part-time PhD course and if you are looking forward to become a research scholar or very dedicated and sincere one, in that case you can go for a full-time PhD. A full-time PhD completes in about three years whereas a part-time PhD takes about four years to complete. Now if you talk about PhD admissions, you need to understand that again there are two things you must know. The first is that there are certain universities in India where they take their own test for PhD admission. So there's this entrance written test that you need to clear and only then you can sit for the interview whereas in other cases if you have the next certificate in your hand you can directly proceed to the interview. So PhD admissions takes place in two steps. The first step is either having a next certificate or sitting for an interview and the second step is interview. Interview everybody has to face whether they have done cleared their next exam or not whereas in case of written exam if you already have next certificate in your hand, if you cleared this next exam then you exempt yourself from the written test that the universities take. So in IITs or if you talk about several other universities they take separate entrance test even after the fact that you have next certificate in your hand whereas there are other universities like their universities where if you have the next certificate in your hand you can directly sit for the interview. You don't need to pass the written test. So that's how the procedure takes place. I'm going to make a full-fledged video on PhD how to submit your application form, how to make a research proposal for PhD. I'm going to deal with all these topics separately for now just remember that if you clear NET with JRF and you enroll yourself in a PhD program you will be getting 25,000 per month by Government of India as a research aid. So in case you enroll yourself in a full-time PhD program and you have JRF with you then you don't need to work anywhere else because Government of India is giving you 25,000 so that you can focus all your time and energy in PhD and not worry about the finances. So now that we have looked at PhD it's time for me to throw some light on the second possible career option that you have in front of you once you clear this exam and the second career option is to take up a job as an assistant professor. If you're really passionate about teaching and you have cleared this exam you have this opportunity in front of you to apply for the post of assistant professor in any college or university across India. NET is the minimum qualification required by a candidate if you wish to sit for the interview of the post of assistant professor but you need to also understand the fact how this interview procedure takes place. When you go and sit for the interview of the post of assistant professor you'll find out that all the other candidates they do have NET certificate with them. So how is the panel going to decide which of them should they select? In that case what is important is the other additional things that you have in your CV which makes you different from the rest of the candidates. So if you have experience of attending some conferences or if you have done some research papers or if you have a job experience of about one year or two years you know teaching somewhere if you have a PhD with yourself or if you have knowledge about your subject you've done some additional things like MFIN in that case it is going to give you a leading edge in the interview. So always remember it's not just NET that is going to make you an assistant professor there are other things that you need to add in your personality if you want yourself to you know portray as an assistant professor in any university or college also you need to understand the fact that how you present yourself on the day of the interview is equally very important. I was a soft skill trainer and I still train a lot of people on how to face an interview how to face a group discussion and it is always important for you to understand that the knowledge you have in your subject that is going to pound out the day of the interview it's not what you've marked up for this exam the in-depth knowledge that you have the way you present yourself that is going to give you an edge in this leading and competitive world. So always understand the fact that just clearing this exam is not enough there's a lot more you need to do along with it and that is how the beautiful journey called life begins. So there are different things you need to explore you need to inculcate within yourself you need to keep on learning new stuff you need to keep on experiencing new things and all these things will come together and will be reflected in your CV as well as in your personality. So I wish you all the best for the next net exam and I hope that this video proved beneficial you've got clarity over what all things you can do once you clear this exam. If you have any questions any doubt you can call on the number displayed above or you can comment in the comment section below and we really really happy to assist you in the best possible manner. Apart from that please do subscribe to this channel we are about to reach one lakh subscribers and I'm really excited to reach that big milestone. You can follow me on all the social media platforms we are running this beautiful go-net quiz for all you guys apart from that we also post updates about the recent changes in NTA UGC net exam. So stay tuned to the channel that's it for this video lecture happy learning keep loving literature and stay tuned to www.arkadakarbar.com


Okay, it's 1050 Pacific where we are in Arizona. Welcome everybody and good morning to those here. I know there are people from practically across the world participating today. It's very exciting to see. We saw a lot of presentations already in these day and a half. I hope you caught a replay of Vitalik's interview with Brian. It was also fantastic. So let me jump on to what we are going to talk about today, which is the use of verifiable credential technology with our loyalty application. So in previous iterations of this, we had presented a year or two ago about the use of hyperledger fabric to build a consortium loyalty product. That was our first foray into using fabric. And I'll talk a little bit about our history and quickly where this product came about. And then we will layer in the second problem to solve, which is how do you securely store customer PII data, use it, but at the same time, don't fall into all the pitfalls of existing systems. Pretty much the biggest companies in the world have not been able to secure their customer information. We have seen that time and again. And maybe there's a new way to think about it using verifiable credentials. So that's what we will talk about today. And I have a quick two or three minute demo, which kind of illustrates the concept. I'll go through some slides and then hopefully the last 10, 15 minutes we can spend doing interactive Q&A. So please do post in the Q&A section or the chat and then happy to answer as many questions as possible. So who are we? Praveeti, which is a company that we founded in 2013. Our main focus was CRM and loyalty. And just very quickly on our history, we had worked a lot with loyalty applications with large airlines and so on and so forth. And the thing that we learned from our experience consulting with these companies and enterprises is that a loyalty program can be very profitable under certain situations if it's a consortium loyalty. Airlines are the best example that you can think of. But one problem that happens is these loyalty programs make a lot of money selling a ton of points to partner ecosystems, credit card companies, car rental companies and so on. But the problem is one of reconciliation. There's a lot of point to point integrations that we have done personally as part of our consulting assignments. And then reconciling becomes a lot more difficult with the onset of blockchain technology. We thought that one way in which we can mitigate a lot of those types of problems is to use distributed ledgers. So with that in mind, we were at that time working with a big automotive OEM trying to help them stand up a loyalty program. And then we proposed this idea and it was well received. We did an Ethereum POC just to kind of see how this concept would work. And then again, we have talked about this in other sessions here even today. We switched to fabric because of its enterprise friendly nature, the cost, gas cost and things of that nature, right? Which were barriers at that time when we were looking at this. So we chose fabric and it was a great choice. And we delivered a pilot for this particular customer. So our product has grown out of that. And so basically our core product, loyalty product was if you have a consortium and you have some large partners and small partners, the large partners will run some notes which will help us reconcile, get invoices quickly reconciled. As a matter of fact, Professor Mary talked about the invoice reconciliation problem with Walmart today morning. And similar situation arises when you have a large set of partners trying to resolve the point balances that they owe each other. So that's the core product. But today we are going to focus on another aspect. We also got the opportunity to be part of Hyperledger, talk to companies like Avernem who are pioneers in the area of fabric in Aries and Indi. And then we said, why not take these additional concepts and apply it to the area of loyalty? So as you know, one of the biggest problems that I just touched upon that is the fact that customer data today gets stored in central CRM databases. We have been working with CRM for the last 20 years and this is a constant issue, right? How do you securely keep that customer data prevented from getting hacked? So in the context of building our loyalty application, we thought why not do this, right? When a customer signs up for a loyalty program, you collect some information about them because you want to serve them better. You want to know their address, their email address, their zip code maybe, and a few other demographic information the month they were born in so that you can give them a good deal that particular month and so on and so forth. That's a typical loyalty system, right? But instead of storing that data and have the potential of losing it and being subject to all sorts of fines and not to mention the dissatisfaction of the customer, why not store it as a verifiable credential in a mobile app? Typically loyalty programs carry a mobile app, so why not store it there and then seek the permission of the customer if you ever need to get one of those attributes for you to use and this way, even when you seek the permission and use that attribute, you are going to use it fmrely and you are not storing anything, definitely not storing it to the blockchain or for that matter anywhere else besides the secure location, probably secured through a fingerprint at the customer's loyalty mobile app. So that is the core idea of what we built in here. So I'll just talk a few more things, just our relationship. So I talked about our core loyalty program and that has to why we used hyperledger fabric for that and then I'm just going to, for those most of you in this audience probably already are clear about how verifiable credentials work but not everybody might know that. So I'm going to spend a few minutes just talking about the concepts of verifiable credentials. So what is a verifiable credential? It's a W3C standard that you may all be aware and verifiable credentials have been incubated in hyperledger Indian areas under the umbrella of hyperledger and the concepts are pretty straightforward. You have an issuer who has used a typical public private key photography and digital signatures and what the issuer does is whatever information, you have a set of attributes, this could be a vaccination certificate, it could be in our particular use case that we are talking about, this is the set of PII data about yourself. In either case, what you do is an issuer issues this certificate by signing this with their private key and then publishing their public key in a data registry. That's typically the only role of blockchain in here. This is hyperledger India, for example, can be any other data registry. Ideally, it's a blockchain because then it's basically functions as a distributed key management system. Some metadata such as the formats and so on could also be stored here in this data registry. But the key issue is the PII data, medical information, whatever is the subject of this particular certificate is securely held in a wallet that is held by the customer. In our case, this is a loyalty member and they are holding their own data. So we literally take their inputs. We don't store it anywhere. We simply reissue it as a credential which is stored in their wallet. Now comes the concept of a verifier. If a verifier wants to check some attribute that is useful. In our case, in loyalty, the attributes will be, like I said, your month of birth, your email address, your physical address, in case of some cases, zip code, whatever the case may be. The verifier can ask for a set of attributes or it can even be even more sophisticated. We'll have an example of that in the video that I'm going to show you. So a presentation, a verifiable presentation is made by the holder to the verifier. All that the verifier needs now is who signed this public key and if they're able to verify that in a blockchain, then that's great. In our use case, that doesn't even apply since we are the ones issuing it and we are verifying it as needed. So basically, they can check the public key, they can check this digital signature which says, yes, this was signed by the private key behind this public key. It's not been tampered with and then they can get attributes or there is concepts such as selective disclosure and zero knowledge proves. For example, if you just needed to prove that you are above 21, you don't need to reveal your date of birth. You can just reveal the fact that you are above 21. So that's one ZKB application. There could be others, for example, in the vaccine case, like I said, you could prove that you took a vaccine within the last three months and so on and so forth. So this is the three parties, the issuer, holder and verifier that are involved in verifiable credentials and that is the kind of concept that we have applied in the context of loyalty. So basically, like I said before, what we end up doing is we extend the use of verifiable credentials to store the loyalty member PII data and again, why store this data somewhere else and increase the risk? You can now give the best of both words using this technology. Now, typically when you sign up for a loyalty program, you want to be rewarded for the actions that you take, the activities that you do with the consortium of loyalty companies. So you're willing to share your activities with them so that you can earn points. So it's a little bit different than some other verifiable credential use cases in which they even try to avoid this correlation, right? In this case, you're giving them permission to be in turn to be rewarded with points but there is no need for that company to know all your details and store it in their systems. You hold it, you reveal whatever it is that you needed to reveal for which you are comfortable with, right? And if you're not comfortable giving your zip code, you can just say no and they can give you offers which are generic, right? So I think this is a new way of thinking for companies, right? It might be a little bit shocking to try and do business this way as opposed to how it's been traditionally done. If you think about all the CRM systems that I've worked in, the main thrust has been how much extra information can be collected about somebody. They want to track you every which way and the belief was that collecting all that information, they'll be able to target you better, right? But I think we have seen the pitfalls of that type of stuff. Secondly, I think the era has come that if somebody wants to use your information, first of all, they need to seek your permission and second, they need to split the proceeds of the benefits of that with you. For example, pay you with loyalty points. They can tell, hey, if you give us, if you put your zip code in your credential, we are not going to just keep it in a database but even just adding that will give you some points for that because once in a while we might seek your permission and use that particular piece of data, right? So that's kind of where we want to support the concept of true data privacy by putting this personal information into a mobile wallet and then letting the user keep control of that, right? So that is the large kind of theory in how we built this. So let me see, before I do a demo, let me see if there are some questions that are visible. Oh, sorry, I didn't check that you wanted it in presentation mode. I will try and do that in just a second. Aren't we a centralized system conceptually? Centralized in the sense of all permissioned systems, right? Our fabric network is run by a set of coalition partners or a set of companies. So are there trusted third parties in this concept? Yes, there are. This is no different than any other permissioned network. As far as the concepts of verifiable credentials, as you know, I mean, the whole thing is, the credential is held in the wallet of the customer and therefore we are really not centralizing the storage of that information. We have a reference to the customer, typically a member ID. So what happens if a customer needs to follow the GDPR concept of, hey, forget me from the system. It deletes this mobile app. We have lost the cryptographic verification. As a matter of fact, the way a person even logs into the loyalty application through the mobile app is using a verifiable credential. The credential that was issued to you with the DITCOM exchange, you are able to prove that whoever you hold this credential, there is a credential ID or a member ID in there, and you can prove that whoever is holding this phone is having that, right? So we don't need to know any further information. When that reference goes away and that person deletes it, we only have left with us a member ID which is not really attached to, we don't know who, because the member ID is attached to a certificate or a digital certificate which the person has decided to get rid of and therefore we pretty much disappear that data. So at this point, I'm going to re-share my screen so that you can actually see the quick demo of how this is put together. So hopefully you can see my screen now and I'm going to play this. Comfortable in the fluid user experience, a lot of data is involved and storing lots of personal customer information equals a lot of liability. As a business, how can you manage empowering customers to own their data while not losing the conveniences of storing information in a dedicated database? Previtch ETLP utilizes self-sovereign identities and verifiable credentials to solve this problem. Here's an example. A customer, Kevin, has just downloaded a loyalty program app and is ready to register. Though this may look like your typical registration process, in the background, a digital credential with this information is stored in Kevin's personal mobile wallet. Kevin's information is securely stored on his personal device, not in a database. Now to log in, Kevin selects log in with verifiable credentials. With this feature, Kevin does not need to memorize a username or password. The loyalty app instead requests to check he is carrying the appropriate account credential. He simply scans his fingerprint to authorize the app access and is redirected to the loyalty app home page. Kevin wants to order a beer flight from his favorite brewery when he is ready to redeem the app asks permission to confirm he is of legal drinking age. With a quick scan of his fingerprint, the app checks Kevin as above 21 and approves the redemption request. In this way, digital credentials allow Kevin to take control over his information while maintaining the flow of a smooth customer experience Learn more at pavichi.com All right. So that is the presentation, which kind of illustrates the concepts that we just talked about and it shows how you can construct a loyalty application. Now, of course, there are some questions that you might have. For example, how did it check the age? It's a self-declared date of birth that you do when you sign up to a loyalty program. Many of them want to make sure that you are at least above 21 but you also realize with verifiable credentials that you can hold multiple credentials. People are talking about doing even driver's licenses in a digital wallet. When that happens, when you have multiple credentials in a wallet, it's possible to do what's called a composite presentation. For example, you can present your proof that you're above 21 from your driver's license and from your personal information digital credential you can pull some other data. So these possibilities are certainly there. So let us see. And I think Trevor, you said, are you thinking that because the same entity is both the issuer and verifier? Yeah, in this particular case, we just want to use the verifiable credential concept so that we don't hold that information. In a typical system, the issuers are different than verifiers. In our case, we are using it in a slightly different way. Thank you, Jim. Let us see if there are questions on this one. Is the loyalty application and the wallet application the same application or are they two different apps? They are two different apps. The wallet application is the mobile piece and the apps, too, think about it as talking to an API layer which is the rest of the loyalty application. In itself, so the way we architect is, of course, we have Hyperledger fabric in the back. On top of it is our chain code and then the API layer. And on top of the API layer, we have an administrative console for administrative purposes. We have a mobile app which can talk to it. So there is a separation of concerns about the API layer, so to speak, and the mobile app. The mobile app is a wallet. So that's an interesting question which is, you know, this whole paradigm of using wallets is going to get stronger and stronger. And what happens is, as time goes by, people would want to have both the ability to store verifiable credentials. It could be store cryptocurrencies and so on and so forth. So the wallet usage needs to get way better, right? And I think over time it will evolve because today wallets can be a little cumbersome, how to restore them, you know, if you lose stuff and so on and so forth. So I think that's an area of research that is very strong. I saw some great new advances using things like threshold signatures which will make the application of wallets much easier. Without changing traditional customer onboarding process in lending world. Akshay, could you integrate this in a traditional lender customer? You could. Again, depending on, I think in the loyalty use case, the bottom line is that information we feel is secure enough in their wallets. Like I said, the wallet process needs to get a lot more stronger because in a lending world, there may be multiple occasions for them to get your information, right? So it becomes really difficult if you have to have the person online to authorize every interaction. I think the world is going to move to a better place, Akshay, where there may be ability to have secure cloud-based wallets, agents which you can deputize that can work with those wallets. And like I said, with concepts like threshold signatures where you have multiple parties will have to agree instead of this single private key being the problem, right? You lose the private key, you lose everything type of a situation. Then those improve, I think all those applications can come before. Any other questions that you'd like to post in the Q&A chat? If nothing else, then we will close a little early, give you guys some of your time back. Enjoy the rest of the presentations. Again, I'll post here in chat where you can reach me if you have further questions. I'll be happy to be in touch or hit me up in LinkedIn and happy to answer any questions. Thank you, folks. I missed some questions. Bogdan, can you point me? Let's see. In the Q&A section? Okay. Okay. Okay. Sorry. Okay. There is this. According to our experience, our company is interested in allowing customers to exchange tokens. A blockchain could be useful for this person. Yeah. The concept of exchanging tokens for some other tokens, that is multiple point types. As a matter of fact, we have designed that within our application and there is interest. We are pursuing some opportunities right now in Asia where they not only want a coalition loyalty program, but they also want to be able to exchange points with other popular programs. For example, Grab is a very popular Uber-like network and they have their own loyalty program and there are consortium of companies which want to have their own loyalty points but be able to exchange it. That is coming for sure. But in loyalty, so far, the concepts of tokens is a little bit different than an ICO or regular crypto token. Tokens are covered. Basically what happens is when a company issues tokens, they differ the revenue. They differ the revenue for that amount. So let's say they give you a dollar worth of points for $10 worth of purchase that you made. Basically, they differ that $1 of revenue until you're reading the points. So all points are actually backed by the deferred revenue of that company. There is a concept of breakage and so on and so forth by which it's reconciled. So the accounting behind it is a little bit different but that could be a way in which crypto tokens can also be acting as loyalty points. I think that age is coming. Which wallet app are you using and where can I find the APS to connect my app to it? The wallet app that we are is custom built, right? It's just part of our, as a matter of fact, for verifiable credentials, we use Evernom as the, you know, Evernom agents and the Evernom SDK. And so we pretty much use the, if you are familiar with connect.me, that will be the app that, you know, that we kind of model ours on. So that's what we are using right now. Again, wallets are going to be standardized at some point, I think, which I believe will happen sooner than later. Are you running on a pre-existing network?  We stand up fabric. We can do it in AWS or at the cloud, you know, pretty much anywhere that the customer wants. Our pilot, we actually did it through a private network that the automotive OEM wanted. Okay, I think that answers all the questions. Jim, is that the presentation mode? Sorry, I was trying to figure out how to do that. All right, if there are no other, yeah, okay, there is one more from Paul. How did you accomplish such a smooth integration between wallet and loyalty app? Basically, like I said, you know, because we kind of know both sides, right? So we know the communication back and forth, but the most important thing to really understand is, you know, we kind of know what is in the credential simply because we defined it, but could we use just any public wallet that somebody else writes? It can be done. The only problem is, like you said, the integration between the loyalty application pieces and what needs to be retrieved from the wallet could be, you know, a little, it's just smoothed by the fact that it is in a single application. That's all. That's why we prefer to use the, like I said, they have an MSDK and then kind of stick it with our, you know, our loyalty app. Okay, folks, I think our time is up. Thank you so much for your attention. Like I said, please feel free to contact me and we will see you somewhere else. I'm sure in another presentation. Enjoy the rest of the conference. Thanks.


And the River State Governor has vowed to breach the recent agreement reached between the federal government and the strike in Judiciary and Parliamentary Workers in Nigeria. One of the conditions for calling off the strike was that the state governments would set up a state account allocation committee to oversee the distribution of available resources to each arm of government. But Governor Wiki claimed that he had already commenced the implementation of financial autonomy for the Judiciary and vowed not to set up any committee. Wiki also said he would not allow the state Judiciary to submit its budget directly to the state assembly, describing it as a breach of extant fiscal policies and regulations that regulate the state budget in process. The governor insisted that he is the elected chief executive of River State and that all Judiciary and Parliamentary Workers who fail to work would have no pay.