All right, welcome, everyone, to another Webmaster Central Office Hour Hangouts. My name is John Mueller. I am a Webmaster Trends Analyst here at Google in Switzerland. And part of what we do are these Office Hour Hangouts, where people can join in and ask any question related to their website and related to web search, I guess.  But if any of you want to get started with the first question, jump on in now. John? Sure, hi. Hi, you may remember last German Hangout, where I mentioned the content change of my small website, also having added article markup on about 14 pages. But neither new keywords nor structured data have been noticed by Google until today, neither in search nor in search console. Indexation of the pages is now more than 10 or 11 weeks ago. And I gave you two URLs to check the home page and an article page. Did you check them? Could you find anything? I don't remember. I need to double check. I can double check later on if you want to stick around afterwards when we have a little bit more time. Yes. OK, I will stay. OK, thank you. Sure. All right, any other questions before we jump into the submitted ones? So you maybe can begin with mine. It's there in the comments. OK, let's see. I think yours is the second one on the list. So I'll just start with the first one so that I don't lose track where I was. OK, so the first one is a multilingual international website targeting a specific country with URL patterns for the home page, like ksa.mywebsite.com slash ar, which has the hreflang value of ar-sa. So I guess that would be Arabic for Arabia? I guess. I don't know. I don't know my country codes. OK, and another one, slash en, which has hreflang value of en-sa. Knowing that Arabic is the default language for my website, does it help my website to rank higher if I implement URL patterns without ar prefix in the URL? So just ksa.mywebsite.com without the slash ar. No, it doesn't change anything. For hreflang, we look at the specific URLs and we essentially rank them as they are. So that's something where I try to keep it as clear as possible in your URL. So if you have different country or language versions and make it so that people can recognize that right away, and in general, I don't see any problem with just keeping it with slash ar and slash en for the different language versions. The country version, I think you already have set up as a subdomain, which is good, because for geo-targeting, the country level patterns, we try to look at clear either domain level or subdomain level or clear sub-directory level folders there. So that's something where you're using your subdomain, at least from the example URL there. And that would be perfect. So from that point of view, I don't think you need to remove the slash ar you can if you want, but it wouldn't change anything for search. Should we provide a list of domains that have been removed in our reconsideration request for the remaining ones? We received a manual penalty for thin content for many of our domains, and we killed a big portion of them. We improved quality on our high-value sites, and we believe they meet Google's guidelines. Yes, I think that generally makes sense. So in particular, if you have a lot of websites that are under manual action and you delete a lot of those and the process of deletion is kind of your way of cleaning things up, then that's something I would mention. I don't think you need to list them all out individually, but you can say something like, oh, we had, I don't know, 100 domains with a manual action for thin content, and we removed 90 of them. Kind of the rough order of magnitude so that the people who are looking at this to see if it was resolved, they recognize, oh, OK. You significantly took steps to clean that up. And does it matter how we kill the sites, no index, server error, or DNS error, or removal request? I would just do it in a way that is clear as possible. So a server error, a DNS error is something that's like, well, nobody knows if this is a temporary thing or not, but if you really take down the site, if people, when they check the URL, they clearly notice, oh, this website is gone. That could be a 404 page, something like that. Just make it as clear as possible that this is not a temporary thing, that you're just like, switch it off and see if it goes through. But actually, this is what you decided to do. OK, thanks. OK, the past three days, we're facing big latency in the indexing API, and a lot of 503 errors with the services currently unavailable. Is the service down? I don't know. So I just saw this question earlier before they hang out, and I'm not sure what the current status is. I'm not aware of any bigger issues there. So sometimes what happens is that things just get stuck for a little bit, but I'll double check with the team. And if there is an issue there, then we'll obviously try to get it resolved as quickly as possible. There are lots of schema.org types of structured data, but only a few of them are listed in the Google Developers Help. Should we spend time implementing something like image object? So I think image object is actually one of those that is mentioned in the documentation. In particular, we use images as kind of a sub-element of different other structured data elements. So I think it's, in particular, things like recipes, where you have images that you specify for that. My understanding is we use image object. I need to double check the documentation, but that's kind of my understanding there. But going back to the more general question, should we use types of structured data that are not in the developer documentation? So in practice, what happens here is we would not use them to do anything visible with your pages. So if you're using a type of structured data that we don't support, then you would not see any visible effect there. If it's, I don't know, maybe you have a car on your page, and there's a structured data type for a car, then just using that won't automatically transform your search result into something that looks like a car. Because if we don't have that type of rich result, then we wouldn't be looking at that markup. And if we did have that type of rich result, we would have that documented appropriately in a developer's guide. That said, all types of structured data help us to better understand the entities on a page. So in particular, going back to the car example, if you have something that uses a lot of words that could be interpreted as maybe an animal or a type of car, then that's something where if you tell us this is actually about a car, then that would give us a little bit more information and would allow us to try to rank your pages more appropriately. So it's not that you would rank higher, but rather we would try to show you in the queries a little bit more where we better understand your page and where we better understand that your page matches the user's intent. So with that in mind, if you're limited or severely limited by time, then I would focus on the types of structured data that are really visible. And if you do have a bit more time or if you have a CMS that's flexible that allows you to expand on things that maybe you're talking about, then that's something there's definitely no downside to adding more types of structured data. The one thing I would watch out for here is that you can easily get lost in the weeds with all of the different structured data types. So it's very possible that you mark up every other word on a page and say, well, this is this element and this entity related to this entity. And at some point, you spend more time on the structured data than you actually spend actually on the content, and that's not going to be useful for your website. So trying to find a balance there is something that I'd recommend. And if you're really limited by time and you really need to focus on things that have a clear result, then I would focus on the types that are documented in the developers guide. A few of my new websites and competitive niches have started to rank without building even a single link just with pure content. It took a while, though, more than two years. So I guess maybe those aren't new websites, but kind of older ones. Could I have saved precious time by building links from high-end websites to reduce this time period? Or it wouldn't have mattered at all. It would have taken the same amount of time regardless. So we use a ton of different factors when it comes to crawling, indexing, and ranking. So it's really hard to say, if I did this, how would my site rank compared to when I do this? So those kind of comparisons are kind of futile in general. In practice, though, when you're building a website and you want to get it out there and you want to have people kind of go to the website and recognize what wonderful work that you've put in there, then promoting that appropriately definitely makes sense. And that's something you don't have to do that by dropping links in different places, but you can get the word out in different ways. And by getting the word out, you're kind of bringing people to your website. And if they like what they see, then maybe they'll link to your website. And all of these things can add up as signals, and it can help us to better understand where your website fits in with the rest of the web. So from that point of view, I would not just create a website and put it up and don't tell anyone about it and hope that Google finds it and starts ranking it in competitive areas, but really kind of like a normal business, spend time to build that up and to build an audience and to understand what people like, respond to things, feedback that they give you, and really kind of build things up as you would with a normal business, essentially. How important is speakable and keyword rich? Speakable and keyword rich URLs for AMP pages. Our tech guys would like to switch to ID-only pages. For example, amp.example.com slash article slash 12345. And the canonical would still refer to kind of the speakable and keyword rich URL. As far as I know, this wouldn't change anything at all. So that's something where if you want to switch to more of an ID-based URL system, that's totally up to you. We do use words in URLs as a really, really small factor when it comes to understanding a page. But as soon as we kind of are able to process the content on the page, then those words in URLs are not going to play a significant role anyway. So from that point of view, it's not something where I'd say you're losing out on a lot of things by not having keywords in your URL, regardless if that's kind of your canonical web page or the AMP version of the page. In general, people see URLs less and less frequently, especially if you're on a mobile phone. It's really rare that you actually see a URL. So I think that shift has been taking place over time anyway in that it used to be people would focus on the URL and try to understand what this URL is before they click on it. But nowadays, you can't really do that. So I kind of see the importance of including a long URL with a description of the article as something that's kind of fading away a little bit, I guess. And that's really regardless of AMP page or web page in general. Is the last mod necessary for a new sitemap, or is this only for normal web sitemaps? So last mod is one of those things that we do take into account from a sitemap file. We don't use any of the other attributes. Well, obviously the URL. But any of the other attributes like priority or change frequency, we don't use those. We do use last mod, however, to recognize when pages have significantly changed and when pages are essentially new. But for that to work out, we really need to have a sitemap file that uses the last mod date in a reasonable way. So don't use kind of like today's date for all of your pages last modification date, because if everything changed today, then nothing is really that important for us to pick up first. So what you really want to do is to give us a clear hierarchy of the changes that you've made so that if we know that we last crawled maybe yesterday and we see these five pages are new, then we can focus on those five pages a little bit more. So that's kind of the direction I would head there. Use a proper last modification date and specify that for all of your URLs and really use this for the sitemap file regardless of the type of sitemap file. So if that's a new sitemap file, then you kind of have that limitation with 1,000 URLs for the normal sitemap file. It's essentially the same thing. Does a way searchers use branded terms in conjunction with non-branded terms affect ranking for non-branded terms? For example, if Google noticed a lot of surfers using the query xcompany plus widgets, would Google be more likely to rank xcompany for non-branded queries for widgets? I don't think it would work that way, essentially just because people are searching in a particular way for your website doesn't mean that we can say, well, if they're searching like this, then we should rank them for other things as well. However, if people are explicitly looking for your company, then that's a really clear sign that they really want to go to your company. So that's something which, from my point of view, always makes sense to try to find subtle ways to encourage people to do that. Because if people know your business, they understand your brand, and they explicitly search for your brand, then suddenly there's no competition in the search results because it's really clear they want to go to your website. And that's essentially, we call that more of a navigational query. And that kind of that shift from people are searching for widgets and going to, well, xcompany widgets, that's kind of a way of making sure that people go to your website. So it's not so much that kind of branded queries drive more traffic to non-branded queries, but rather if people are searching for your brand, suddenly you have a lot less competition because Google understands fairly quickly that this is your brand and this is your website. The caveat here is, of course, if your brand is a generic keyword, then that's not really going to work that easily. So if, for example, you named your brand Best Widgets, then if people search for Best Widgets, that's really unclear to us that they actually want to go to your website. Whereas if you have a clear company name, like, I don't know, xcompany, and you also sell widgets, and if they search for xcompany, then suddenly we would understand this query matches your website. And it is more of a navigational query than kind of an informational query. So that's something always kind of worth to keep in mind, especially when you're building up a new website, a new brand, that you pick something that people can remember, and that's kind of unique in the sense that when people search for it, it's easy to recognize that they really want to go to your website. It's not that they want to kind of get general information for these keywords that they enter. How important is internal linking in general? My client's current HTML site map takes five clicks before you reach a page with content. Outside of using the search bar, the only other way Google can reach these pages is with an XML site map. So my guess is with the current HTML site map, you mean kind of the current website in general, not a site map page that you would have. So in general, internal linking is really important. And it is almost the best way to understand the context of individual pages within your website. So it's a lot easier for us to understand this is the hierarchy of your pages. These are kind of the higher level pages, the more important pages, the less important pages. All of that is something that's really important for us to be able to pick up on. And it's something that is reflected in a lot of places in search. So just for example, something that I saw recently, if you have a really flat hierarchy in that you have all of your pages linked from all of your other pages, then we can't really tell which of these pages are more important than others, which can lead to situations like you have a site link on one of your pages that is shown right below the search result that points to a completely unrelated page. And from our point of view, we think, well, all of these pages are equally important, and they're all very related because they're all linking to each other. So taking any random page and using that as a site link is something that could be reasonable. Whereas if you have a clear hierarchy, then it's a lot easier for us to understand, well, this is the part of the website that belongs together. And this other part belongs together here. And kind of like this is the higher level part, all of this is a lot clearer to understand. So with that said, the number of clicks to reach a page from your home page, for example, is something that helps us to kind of understand how that page fits in. But it's not necessarily something that we'd say is bad if it's above three or four or five. So the important part is really that you have a clear hierarchy. And when you have that hierarchy, the absolute number of clicks is less critical. That said, if there is something that you really want to highlight on your website, and you kind of say, well, this is my favorite product, my best selling product, the product I make the most profit from, or this is something completely new that I really want to promote, then having that linked more prominently within your website definitely makes sense. Because then we can understand that you really care about this new thing or this unique thing here. And we can show it appropriately a little bit more visibly in search as well. So if this is some random product on your website, and it takes five, six clicks to get there, perfectly fine. If this is something that is really your best, most important product, and it's a very competitive niche, then link to that maybe. And with regards to linking from the XML sitemap, that's something that's almost kind of separate. Because from the XML sitemap, we can pick up which pages are new and changed. But it doesn't give us a lot of context about those pages. OK, after a DMCA notice, my client removed the content and also removed those URLs from Google Index. Still, we're receiving DMCA removal notification. How do I inform the complainant that my client has removed all of the content? My client had the rights to publish the content, but now their license has expired. I think someone is accidentally muting me. No problem. So with regards to DMCA complaints, the thing you would need to do is to respond to that DMCA complaint and to kind of say, well, I cleaned this up. I resolved this issue so that that DMCA complaint kind of goes back to the person who sent the complaint, and they can take that and say, oh, OK, it's resolved. I will cancel this. So that's kind of the direction that you need to take there. In general, if this is a single URL and you've removed it from your website and it's no longer shown in search, then having that DMCA complaint kind of pending or open isn't something that would affect the rest of your website. However, if this is something that happens on a larger scale in that you have a lot of DMCA complaints on your website and you kind of remove them individually and it's like, you're kind of taking them on step by step, then by having all of those DMCA complaints pending and still active, that's something that we might pick up in our algorithms and say, well, we don't really know how well we can trust this website. So if you get these kind of DMCA complaints on a larger scale, then I would respond to them and make it clear that this is resolved or make it clear that this is kind of an incorrect DMCA complaint so that our systems understand that there are no pending DMCA complaints there. Thank you for a moment. If you're reaching too many ads on your articles, the rankings of your website will get affected. Is that true? It's not so much the number of ads on your pages as kind of the general experience on the pages themselves. So that's something where we look at things like the above-the-fold content. And if the above-the-fold content is reasonable for your website, if there's information about those pages, then that's kind of fine. If you have ads that are loaded below the fold, or if you have small parts of the above-the-fold content with ads, then that's generally OK. And that's not so much based on the number of ads, but more based on how prominent are these ads.  That's something that's very different from one very large ad that takes up the whole, above-the-fold content. So, John, I have a related question. We have partner links with affiliates. And we're wondering if we need to add, or if we need to prioritize high, adding real sponsors to our links, or no follow is good enough. In general, no follow is good enough. If you can add the real sponsor to that as well, that helps us to better understand it a little bit. But it's not something that would be critical. So in particular, if you have existing links like that, I would just leave them like that. If you're setting up a new website, then I would just use maybe either real sponsored or real no follow sponsored together, just to make sure that it's a little bit clearer going forward. OK, thanks. Is it problematic to develop with React and implement dynamic rendering on a large site that is essentially static content, which doesn't update regular rapidly? Our IT department is advocating for this route in our upcoming redesign. We're concerned going the single page application route is going to over complicate a lot of things, including SEO. So it will get more complicated. I think that's generally almost always a case when you move from a static HTML setup to a kind of dynamic JavaScript-based framework. So that's something kind of to keep in mind. It will get more complicated. It's not that it's going to become impossible, but it will definitely become a little bit harder to kind of manage. It will become a little bit harder to set up properly. It will become a little bit harder to monitor your setup, to monitor your website that everything is working well, because it's a lot harder to use simple command line tools to just fetch the content of your pages and check that the meta tags are the same, all of these things. So that's something worth definitely worth keeping in mind in that you might save a lot of time on the development side or be able to create something really fancy on the development side. But you will almost certainly have to invest a little bit more on the SEO side to make sure that you're doing everything right. So that's kind of the, I think, the baseline situation. It's not that it's going to become impossible to do. And there are different ways of dealing with that, which could be as simple as, well, maybe you just pre-render all of the content and you serve the static HTML version either to crawlers or even to all users, depending on how you have that setup. But it is something where you'll have to look a little bit further than just like, oh, I will just switch it on or switch it over and everything will continue to work the same as before. So that's kind of, I think, definitely worth keeping in mind. I think it's getting a lot easier. It has gotten a lot easier, because there's a lot more information out there on what you need to do. There's a ton of documentation on our developer's guide on how to deal with JavaScript sites. A lot of the SEO tools nowadays, they can deal with JavaScript sites. But it is something where you have to spend a little bit more time, especially in the beginning, to make sure that you're picking a setup that is actually going to work well for your business, for search in general. Let's see. And one question about Discover, my website is in Swedish. However, my articles are not appearing for me and the rest of the Swedish people when you're connected to a Swedish Wi-Fi. However, when I connect with Wi-Fi outside of Sweden, my website articles are appearing as normal. The problem is that my target group lives in Sweden. So it started on a specific date, and it seems more Swedish websites have the same problem. I'm not aware of anything specific related to Sweden, but I'll double check with the team to see what might be happening there. I notice you have a .NET domain name, which is a generic top level domain from our point of view. One thing I would make sure is that you also have the geo-targeting settings set to Sweden if that's really your target audience. So that's something you can set in Search Console. It's a little bit hidden at the moment because it's a part of the old Search Console, but that's definitely something I would try to set up. But I'll also check in with the Discover team to see if they're aware of anything kind of happening there. Does a broad core algorithm update also affect Google Discover? A couple of weeks after the January 2020 update, we noticed a drop in traffic coming from that source, and Search Console also shows a dropping impressions overall. Yes, I believe we included that in one of the core update tweet series that these kind of core updates can affect Google Discover visibility as well. Should we have our sites automatically append our company names to the end of the meta-titles or leave it off and let Google do it? Right now, our company page automatically appends a company name to the title, and it's annoying because often the titles get too long and end up with ellipses. Yeah, essentially, that's up to you. So what happens on our side is we try to understand what the website name is in general. And if that's not included in the title of your pages, we may append that to the end as well. So probably what happens here is we would show them in more or less the same way anyway. In general, though, having the website name attached to your titles makes it a lot easier for us to understand which title to actually use. So that's something where if you give us this information, we'll probably end up using it correctly. If you don't give us the website name at all in the title, then it'll be a lot harder for us to figure out what you would like to have shown there as kind of a website name, company name in general. To handle our pagination, these are category pages actually, and they may contain over 100 plus pages. Do you think this is a good practice if we create page one, which lists our most important 30 products in page two and a very lightweight view all page, which might contain up to 5,000 unique product URLs? And page two would be canonicalized to, I guess, a view all page. So in general, this kind of goes back to what I mentioned before in that having a clear hierarchy on your website makes it a lot easier for us to understand your website in general. So if you have a category page with page one, which is linked here, and then page two, which is actually a view all page with links to all other pages, then we can still understand things from page one are probably more important. And something higher up in the hierarchy than kind of like everything else. But within this bucket of everything else, everything is kind of equivalent. And from our point of view, that makes it really hard to understand which of these are more critical to you. And it makes it a little bit harder to understand how things are related. So which of these products end up being similar to each other? It's really hard for us to tell. It kind of depends on your website, though. If this is within a set of different categories, and the first page in this category is already kind of really a good sample of the important products that you kind of care about in that category, then we have a lot of hierarchy just from those different categories already. And then the view all page, which links to everything else, is something that essentially is kind of connected further down in the hierarchy of the website. So that's something where maybe it doesn't matter that much. But on the other hand, it might also just be that if those view all pages aren't that important in general, then you might as well just use a normal pagination setup, rather than kind of this complicated one that has the normal pagination and then the view all pagination. You might as well just have like linking between the individual pages of pagination directly. Yeah. Go ahead. Regarding site hierarchies and overall architecture, so we're working with a fairly big retailer in the sense that they have like a few hundred thousand products. And there's about 1,000 categories or something like that. And one of the main issues I think they have is that most of those 1,000 categories are in the SiteWide menu, like in the header menu. So that's quite a lot of links on every single page. So from my point of view, on one side, that kind of makes all of the categories equal in the sense that there is no hierarchy for Googlebot because everything is SiteWide. Everything is linked SiteWide. And on the other hand, having 1,000 links on every single page might make it difficult for Googlebot to crawl everything maybe or assess where the page rank should flow more exactly. So what are your thoughts? I mean, I know what is the best practice, but what are the reasons why you shouldn't go with such a flat kind of architecture? Now, so I think purely from a technical point of view, we'd be able to deal with 1,000 links on a page. I don't see a problem there. So that's something where it used to be that we would just use, I think, the first 1,000 links on a page. But I think we dropped that 10 years ago or something like that pretty long time ago. So just from purely a technical point of view, that's not going to cause a lot of issues. But I could imagine from understanding the context of individual categories, it is something that we might have trouble with. So in particular, you might notice this with SiteLinks. That's kind of the place where I ended up noticing it because people flagged it to me, where if you search for one category and you have different SiteLinks below that category page in the search results page, and if those other categories that are linked there are totally unrelated and don't make a lot of sense, then that's kind of a sign that we don't really understand how these pages should be connected and which of these categories are kind of belong together. So that doesn't necessarily mean that you have to go from 1,000 categories to, I don't know, 100 categories, and you link to subcategories or something like that. But maybe there are other ways to make it a little bit clear that these things belong together, these things belong together, these other things belong together. So that's kind of the direction I would go there first to figure out, is it really a problem or not? And if it is a problem, then think about ways that you can split that up a little bit clearer. Well, one thing they do, they already show subcategories in the sidebar. Once you go to a parent's category, they show the subcategories in the sidebar. The only thing is that all of these categories are also in the main menu. So the main menus, again, something like 900,000 categories, obviously, that's not very useful for users as well. We're guessing, because we notice a lot of them are just using the search bar, the internal search, simply probably because the menu is so big. I was wondering whether I know that Google kind of splits main content from supplemental content and the menu kind of falls in that supplemental content. Does that mean that it's less of a problem to have all of the category links in the menu or doesn't really play a role there? I don't think you'd see a big difference there, because essentially what would happen is we would recognize the link from one category to another category. We'd see that in the top menu. And we'd also see it in the sidebar and maybe within the body of content as well. But it's not that we would add up the value of those individual links. It's just like, well, that link is already there. And you're not giving us a little bit, not giving us more information by also including it multiple times. So that's something where just piling on more versions of that link to create a category structure doesn't really work. It's really like, we already see it. And we know that link is there, even if it's in the header somewhere kind of with the main navigation. So because you see those links everywhere, that doesn't mean you can't really, as you mentioned earlier with the site links, you might not be able to kind of figure out, OK, so this is like a parent category that targets a topic. And these are subcategories that target specific parts of that topic and things like that. Would that create a problem? As far as I understand it, yes. So if we already know that link is there, then it's not that we're going to try to figure out, like, well, it's also here and also here to try to kind of guess at a hierarchy a little bit more clear. It's really like, give us a clear hierarchy, and we'll try to work with that. OK, cool. Thanks. Another one that sounds kind of similar, let's see. If page A1 has 20 outbound links, other than a sitemap, these are links through which Google can discover those 20 pages. If we put a canonical tag on A1 pointing to page A, would Google still be able to discover those 20 outlinks on page A1? So with the rel canonical, you're essentially telling us that these pages are equivalent. And from our point of view, if you tell us that these pages are equivalent, then we can just pick one of those and use that for indexing. And it might be that we pick page A1 as a canonical, even though you have a rel canonical point at somewhere else. Because for canonicalization, we use a lot of different factors. That includes the rel canonical. It also includes redirects, internal linking, sitemap files, all of these things kind of come together when we pick a canonical. So if we pick page A1 as a canonical, we'll know about those 20 links. If we pick page A as a canonical and it doesn't link to those 20 other pages, then we will not use those 20 links on page A1 as a part of A. So with the choice of the canonical, if we understand that these pages belong into kind of a set of pages that could be a canonical, we will only focus on the content and the links of the canonical page. Everything that's kind of on the non-canonical versions that we end up essentially skipping over for indexing, we would not take into account. So if these are supposed to be equivalent, then make sure that they're really equivalent. If they're supposed to be different, then let them be indexed individually. Googlebot now uses the latest version of Chrome to crawl, render, and index content. When there are discrepancies between the source and the rendered JavaScript, what factors does it use to determine the authoritative version? So if we render a page, we will use the rendered content only as a basis for indexing. So if during rendering, the content of the page is essentially deleted and replaced with a placeholder text, then we will only use that placeholder text if we index that page after rendering. So anything that was on the page before will be gone. Usually, that's less of an issue, because if you have a JavaScript framework, you're adding content to the page. So we would have kind of the existing content plus the JavaScript content. And that's what we use for indexing. That kind of makes sense. The part where this becomes problematic is if there's a conflict between the content that is on the page before and the content that is on the page afterwards. And one situation that we have seen, for example, is if the content on the page before it gets indexed has a no-index meta tag on, then regardless of what we place there with JavaScript afterwards, that no-index is always going to be there. So that's something where if you have a severe conflict between the static version and the JavaScript version, it becomes a lot trickier for us. Another common case is if you have a rel canonical on the static page before and you have a different rel canonical with JavaScript afterwards, then it's kind of tricky for us to understand, well, which of these ones is actually useful. And that kind of comes from us on the one hand looking at the static version before and then rendering the version based on that. So that's something where as much as possible, you want to make sure that those pages align. And if you add additional information with JavaScript, that's fantastic. If you add information that clashes with the existing information, then that's something where it gets a lot trickier. When does Googlebot take the rendered DOM snapshot used for indexing? We don't have a specific time. So it's not that there's a specific time out that happens for us to pick up the index version. We try to recognize when a page is ready. Um, whoops. Wait. Manasha, I think you're presenting. Let's see. Maybe I can turn that off. Now, so we don't have a specific time with regards to understanding when a page is ready. The main reason we don't have a specific time is that when it comes to rendering, we do a lot of caching. And we do a lot of steps to try to understand when a page is generally ready. And that can result in things like the timers on the pages being processed quite differently than when you process a page manually. So that's something where it's really hard to specify a specific time just because of the way that we render pages. So for example, if you have different JavaScript APIs that you're pulling content in and calling those APIs takes a second each when you run it in the browser, it might be that we already have those individual elements cached on our side. And when we render the page, we can render this page in a fraction of a second. So we might get the full version in a fraction of a second, whereas you might need to wait maybe 10 seconds to actually render the full page in your browser. And similarly, it can be the other way around in that when you access a page, you're able to get all of those requests in right away. And you can get that page essentially right at that time. Whereas when we try to render the page, it might be that we're limited by the amount of crawling that we can do for individual pages. And then suddenly it takes us maybe an hour to actually render that page. So those differences are things that kind of come out just because of the kind of different approaches that we take for rendering content for indexing versus what you would do if you were accessing a page with a browser. Hey, John, may I interrupt you with a question? Sure, go for it. So we have a client that is a retail client. They had some pages for summer collections 2016, 17, 18. And last year, they decided to make a non-year URL for the summer collection. They added redirect on all of these. But the problem is Google is still seeing these URLs. It's indexing them. If you try to access, the 301 works. Every tool I tested with sees the 301. In Search Console, when I inspect the URLs, it says that they are indexable. They have a self canonical. If I test the live URL, it still says they're indexable. But the canonical changes to the new URL that was added last year. Could you help in any way like pointing in what might be the issue here? So when do you see the old URLs? Is that something you see in Search, or is it showing in Search? So if I search for the brand and summer collection, I see those old URLs besides the new one. OK, in addition to the new one. Yeah, yeah, yeah. So you see like three for URLs for the same. OK. Usually that kind of cleans itself up over time. So that's something where if we see that there's a redirect, if we see that the rel canonical is pointing to the right version, then that's something where over time we will recognize more and more signals point to this version. So we'll only index that version. The thing I would watch out for is to make sure that your internal links don't refer to the old URLs. That's something that people often forget. Sitemap file, if you have hreflang annotations, all of those should also point to the new URLs. Sometimes you can use third party crawlers to just recrawl your whole website and make sure that there's no reference to the old URLs. And if you're sure that that's the case, then that's something that'll just settle down over time. So for individual pages, it's really hard to kind of force that to happen. It just happens naturally over time. And the thing to also keep in mind is if you explicitly look for the old URLs. So if you do a site query or if you do a search which includes maybe words from the old URL, then it might be that we would still show that in search even when we switched over to the new one as a canonical. So that's really common. For example, if you do a site move from one domain to another, if you search explicitly for the old domain, we'll show it to you because we're trying to be helpful by saying, well, this is the thing that you're looking for. But in general, if you've made sure that everything aligns, that everything matches the new version, then I would just let it run. OK, thanks. Sure. So, John, I have a question. I made a mistake shared my screen, but so for that. So we have a new site. And the site have something that appear like a technical bug. So maybe if it's fine, I will present my screen, but you try to explain it. So we basically, give me a second. We basically have a page that looks like appearing in Google. But while you're checking it, it's a new site. While you're checking it, even if the inspector you are showing that the site is indexed and looks like have the chance to get a rank, the results comes empty. So while technically it looks like you're inside and it's fine, in any way that we're checking, the pages actually doesn't appear indexed. You have, by chance, any idea why this kind of stuff can happen. We also try to escalate it to the community forum. And we don't really solve it. So one place where this could happen is if there is either a manual action or if you have a URL removal in place. That's something where both of these kind of could be similar in that the inspector else would say it's indexed, but it wouldn't show in search. Because from our point of view, these are basically just filters that happen on top of the search results. The page can still be indexed. It's just not showing in search. And both of them doesn't happen. OK. The other thing is that sometimes the site query, because it's a restrict rather than a comprehensive list of URLs that match from an indexing point of view, it can happen that something is just not shown in the site query. So it might be indexed, but maybe indexed in a way that from a site query itself, it wouldn't be shown. And depending on how you search for that page, it might be the same. So what you could do is double check in Search Console in the Search Performance section and filter for that specific URL. And then you can see, is it occasionally shown in search or not at all? No, it doesn't show in search. It's kind of, well, the indexed, but it's technically appearing. And it's a new site that suddenly got it dropped without any many election appeal in Search Console. It might just be that our algorithms are trying to figure out how to show the site properly. That's something that sometimes it takes a bit of time to settle down. It really depends on the website itself. It's also something where if the topic is something that is often used for spam, then it might be a bit trickier for our algorithms to figure out, oh, well, actually, it uses similar keywords to maybe other kinds of spammy content. But actually, this one is a good website that we should show in Search. And that's something that can take a bit of time to kind of settle down properly. OK, thanks. Sure. All right, any other questions from any of you? Hello, John. I have a question if you hear me. Sure. I assume that you will remember Ikea case, which is related to indexing issues with wrong reflank attributes. And Turkish Airlines is one of our main customers. And they complain from the same thing. They wonder that one Google can fix this problem. Which website? What's that? I remember that Ikea has having some problems with wrong reflank indexing status. You remember that? Google was indexing wrong pages about Ikea from different geographies and from different queries. And we have the same problem with Turkish Airlines. And our customer wonders that when can this problem fix? That sounds like something different. So because I think the issue that we saw with the Ikea website was unique there. So it would be really useful to have more specific information on what kind of problem you're seeing. So if you want to look around afterwards, maybe we can get to that side a little bit more. Or if you want to drop a link in the chat of some sample, I can get that. Give me an example. And we see that our pages are getting indexed in Turkish queries with maybe English pages. But we are using reflank correctly. There is nothing wrong about the code. And we assume that this will be related to the Ikea case. But then you have Turkish content and English content. Is that correct? Yes. We have different contents. And we are using reflank correctly. But Google is indexing them different. OK. Maybe you can drop some sample URLs in the chat. And I can pick that up afterwards. OK. OK. Thank you. Because these tend to be kind of unique issues. So the ones that we see more often are cases where it's the same content for different countries. So for example, if you have German-language content for Germany and Switzerland, it's exactly the same content. It not makes it hard for us, right? Of course, yes. Turkish and English content. And we should be able to see that it's different. But maybe you can give me some sample URLs. And I can check. OK. I will stop. Thank you for coming out. Sure. All right. Looks like we're kind of out of time. I still have a bit of time left. So if any of you want to stick around and chat off the record after the recording stops, feel free to do so. But otherwise, I'll pause the recording here. Thank you all for joining in. Thanks for all of the questions that were submitted. If there's anything else on your mind that we weren't able to solve here, or if any of the answers were confusing, feel free to drop us a note on Twitter or post in the product forums. Or I have a question for one of the future Hangouts. All right. Thanks, everyone, and wishing you all a great weekend in the meantime. Bye-bye. Bye. Bye.


So, welcome everyone. This is your Hyperledger in depth, an hour or so with this time, the Ethereum community. It's not really just with consensus or just with Accenture, it's actually a joint effort that I'm really excited to bring to you. Hyperledger in depth is a series that we launched with the beginning of this year to fight the Zoom fatigue. We really want you to participate, ask questions and really be active. We don't want to just broadcast information to you. If you wanted it broadcast, you always can listen to the recording. There's no need for actually live conversation. So today we will hear on how can the two communities Ethereum and Hyperledger community jointly work together for a greater good. And some of the speakers will be Peter, Dano and Rai. And a couple of housekeeping rules. First and foremost, as always, Hyperledger and Linux Foundation meetings always happen under the antitrust policy. You can scan the QR code in your top right and look at it. In general, it tells you not to share anything that could be considered an intellectual property while being on this call. If you're sharing something, assume that your competitors are listening in. This meeting is being recorded and actually also live streamed. So this is really exciting to me because I'm doing it the first time. The recording will be uploaded to the YouTube channel and to our website as soon as we finish this conversation. And slides will also be available for downloading. As I mentioned, this is not your regular webinar. We want you to participate. We want you to jump in. All of you should be able to unmute yourselves and join the conversation. If you feel like there is some kind of a very big discussion and you don't really want to jump in and break the conversation, raise your hand.  Also, if you are shy or your mic is off or anything else, you can always use the Q&A. I will be observing the Q&A box to bring up the questions. And finally, if you want to talk and comment and kind of have a side chat, use the chat window. That will be the most helpful thing to do. And with that, I'm handing over to my amazing team of professionals and looking forward to this webinar. Amazing. Thank you, Marta. You introduced that beautifully. Lots of hype. If you're okay with it, I'll go ahead and share my screen. And we can dive in. So Marta did a great job introducing this session. As she said, this is supposed to be highly collaborative, lots of polls, lots of conversations. We did not prepare a ton of content. So really, this should be all about you all answering questions and asking us questions and providing feedback and answering the polls. And that's going to kind of take the direction of the session. We don't have really prepared too many prepared slides, as I said. So again, talking with us, chatting with us, feedback, polls, it should be a lot of fun. Before we dive into anything, we'll introduce ourselves. So I'm Grace Hartley. I work at Consensus. I'm a Senior Business Operations Manager, particularly for the Consensus Quorum Group. I work a lot in our internal ops and partnerships, particularly within the Consensus Quorum team. The Consensus Quorum team is the one that originally submitted Hyperledger Basu to Hyperledger back in 2020, wow, 2019. Goodness. That's crazy. Before Consensus, I worked at KPMG. Also worth mentioning is that I do sit on the Technical Steering Committee within Hyperledger and do that with Dano. Dano, you want to go next? Sure. My name is Dano Farron. I am a Lead Protocol Engineer at Consensus. And I've been working on Hyperledger best basis the whole time I've been at Consensus back when it was called Pantheon. So I've been working at it for quite a while. And I also sit on the Technical Steering Committee for the Hyperledger project. Before I worked at Consensus, I spent some time in Google, some time in Oracle, during those times is when I got interested in blockchain and Bitcoin. And a simple interest in graphing the way new CXO flow eventually found its path all the way down to working on the core protocol of one of the clients. So it's kind of an interesting tale that one little thing I used to be a desktop developer using desktop movies. And now I know more about virtual trees than I care to admit. So that's, that's my strength here. Rai, you're up. Sure. I'm Rai, and I'm a Senior Protocol Engineer at Consensus Core. I'm working primarily like Dano on Hyperledger Basu. And before Consensus, I worked at Azure Machine Learning on a library that allowed you to do distributed machine learning evaluation and training on clusters. Perfect. And then we have Peter here, who is our lovely guest from Accenture and is going to round out our group. Peter, you want to introduce yourself? Yeah, sure. I actually started out. I was just muted. So I'm Peter from Accenture as a product architect. And my thing is that I'm one of the maintainers for Hyperledger Cactus. So I'm all about blockchain integration and interoperability. That's just my thing. Good. So now we've introduced ourselves. We'll go over our very light or kind of wherever this you the audience take us agenda. As Marta mentioned, this is a webinar on Ethereum. We have some of the leading Ethereum developers and experts here on this panel to kind of answer your questions, have, you know, provide their experience and also particularly put it in the Hyperledger context. Historically, when you talk about Hyperledger and you talk about Ethereum, you're talking about different things. But now we know that's not the case. And we're wanting to talk to you today about that and how, you know, actually Ethereum fits really well into the Hyperledger story and does a lot of it. And, you know, is already a major player in the community there. And hopefully we can answer your questions when it comes to that. So starting kind of from the top, we'll talk about what is Ethereum? We'll talk about what are Hyperledger's Ethereum based projects. And then we'll also talk about how to get involved in the projects at the end. And as I mentioned, questions, questions, questions are encouraged. But we will start with a poll to kind of get a sense of our audience and who we have here.  So you should see a poll pop up on your Zoom here. And please go ahead and answer it. I wish I had jeopardy music to like play in the background or we wait for everyone to answer. Is anyone a singer here? No, Tano just cringe. We'll get everyone just one more second. If you have an answer to it, please go ahead. All right. Martin, do we want to show the results if we think we have a group? I actually managed to be speaking on mute. We are almost down to everyone, four more people. So come on, guys. You have started off strong. Three more, three more seconds to do it. And hi, hi, Angel. Everyone, please feel free to introduce yourself. This is really informal. We will not kind of create any kind of restrictions here. Okay, we have almost everyone in. So I'm ending the poll and we'll be sharing. There is, it's interesting. Quite the mix, I guess. So that's good to know. So it seems like the majority or over half know some but aren't experts. And then the other half are either just getting started or either an expert. What do you guys think, Tano, Peter, Rai? Surprised there's so many people that said that they work in a theorem every day. I agree. That's exciting. Yeah, that is exciting. That is exciting. Yeah, we'll have to answer. You guys can ask definitely the more advanced questions. Cool. So maybe team us up with that kind of frame in mind. We'll start with a few kind of introductory questions. Getting the lay of the land. If you're new to Ethereum, you know some about Ethereum, hopefully we'll be able to kind of, yeah, give you a lay of the land is probably the best way to put it. And we'll ask each of you, panelists, these questions. So maybe starting at the top. For those of the group who don't know what Ethereum is, what is Ethereum? How does it work with other distributed ledgers or compare against them? We love kind of a high level intro. Rai, I think you're on point. Yeah. So first and foremost, Ethereum is a permissionless public smart contract platform with a Turing complete programming language. And what's interesting about it is that if you change a few bits and pieces, the consensus adds some permissioning and privacy, you can have a really cool enterprise private solution that uses the same Ethereum virtual machine for execution of these contracts. And you can read state from the public Ethereum mainnet. So that's the kind of shape of what Ethereum is in the public space and also what Ethereum is in the private enterprise space. And so Rai, would you say typically you hear DLTs are only in permission settings, but Ethereum is kind of different where you can do both. That's kind of the differentiator maybe? Yeah. Daniel, Peter, anything else to add there? Any other color to provide? Nothing for me. Yeah, nothing too much. I mean, you can add and change a consensus algorithm so you can make it as permissionless or as permissioned as you want. That's what we have with Bezu. But yeah, Ethereum started out principally as permissionless as its main underlying value. Cool. So then the second question we have here, hopefully starting to get into that Hyperledger lens, what are the Ethereum projects currently in Hyperledger? Peter, do you want to start? Maybe talk about Cactus? Technically, you could classify Cactus as an Ethereum project as well since we are aiming to support vanilla Ethereum and also the other types of clients such as Bezu. So I'll put down Cactus as one of those projects. So what is Cactus? Just giving everyone an overview of having some ground with each other. Cactus is about integrating blockchains, different distributed electric technologies, and we are aiming for it to be an enterprise-grade framework that hopefully simplifies a lot of the common tasks so that you don't have to read that every time you're building an application that has to deal with multiple different lectures sort of like an SDK or SDKs. So one big conversation and correct me if I'm wrong and others chime in is interoperability, of course, and how not just Ethereum projects but other DLTs can interoperate together. Cactus is kind of trying to solve one of those problems exactly which is pretty cool. And one of the key things that Hyperledger I think talks about quite a bit. Is that a fair assessment? That is 100% fair, yes. Okay, great. Okay, then let's maybe talk about Bezu and that project in particular. Dana, you want to take the lead there? Sure. So like there's different parts of the Ethereum ecosystem, Cactus is an integration tool that integrates the different blockchains. Bezu itself is what's called an Ethereum client. It's the actual node software that you run to connect to other nodes to form an Ethereum network. In Mainnet right now there's four major nodes, node programs that run and synchronize on the Ethereum Mainnet, having Bezu, Gath, NetherMind, and Open Ethereum. And Open Ethereum is what parity evolved into over the past about a year.  And when it comes to private, those are required that, you know, you just today only want specific network and want specific configuration or a small set of test nets. Bezu has some custom extensions in addition to Mainnet compatibility that allow it to work on private networks from simple things like, you know, you can change that to a consensus algorithm called CLIC that does not rely on a group of work but still has issues with things like probabilistic finality to other consensus algorithms such as our version of IVFP that provides finality for your consensus. And some other very advanced permissioning where you can restrict which nodes can connect as an option you can turn on, which nodes can do smart contracts, which nodes can do calls, which nodes can validate. So Hyperledger Bezu enables you to run your network as free and as open or as tight and locked down as you would need to for your particular use case. You can start up your own private networks. You can join other people's networks. It's it's it's it can do what you need it to do. And then I think maybe I'll jump ahead just for a second because I think this might be helpful for the group. So when you're thinking about Hyperledger or asking talking about hyperledger projects, this is the greenhouse that we see in a lot of marketing materials. If you're a part of the community, what I like to do is call out the Hyperledger Ethereum based projects or projects that work in Ethereum. We've talked about cactus down at the bottom that's working interoperability with the other Hyperledger projects and Ethereum talked about Bezu, which is the Ethereum client, which sits in the distributed ledger bucket. We haven't talked about Borough yet. Dana, do you want to take a stab at just giving a quick overview of Borough? Sure. Borough is it's a go based Ethereum virtual machine. They don't have main net compatibility because they don't talk to main net proof of work protocols. They have their own system that's approved the state system kind of derived off of Tendermint. Borough came from the Tendermint project and the other half of the Tendermint project became the Cosmos team. And I think that's the library that fabric and saw tooth use when they provide EVM as their chain code support. So a quick question on Bezu then. When it says it's an Ethereum client, when I hear the word client, I think of something connecting to Ethereum, but not necessarily being an Ethereum node itself. Is that the right way to think about it? It is an Ethereum node. It is a node, okay. Yeah, it is a node. So that's maybe we should you put the word node in there, but yeah. Okay. No, thanks for clarifying. Yeah, client can be kind of confusing because it came out of client server architectures right in a peer to peer system. There are no servers this, but they just kept the client work. So yeah, everything is a client and they're all kind of equivalent in their responsibilities. Yeah. All right. Good. All right. Thanks. Yeah, that's a good question too because when we say client, yeah, we always, you know, mean something a little different than and I think that's very much an Ethereum lingo word, but really it's not, it doesn't really translate in other DLT conversations. So great question. Because in fabric, we would just call it a node. Right. Yeah. Okay. Right. Right. Okay. Got it. So a couple of other bits on this greenhouse that do work with Ethereum, but aren't like Ethereum focused. I've pointed out are also hyperledger caliper. We can test Ethereum nodes and basic nodes. There is a project in hyperledger labs, beef cluster that provides kind of like an application gateway type thing for the Ethereum nodes that clusters up. And I'm not too familiar with Adlon, but I thought I saw them do some demos where they would interact with Ethereum nodes like a geth node to do some of their secure chip, SEM, the particulars of the, of the secure chipping that is the point of their project. I can't, the names gets my tongue what they're using it for, but the hardware based integrations with some of it with the secure module like the SGX instruction set. Yeah. So hyperledger Avalon is an implementation of the Ethereum Enterprise Alliance standard on trusted execution environments or trusted elements as they call it. Yeah. Yeah. That's the word. I should update this. So I didn't circle that Avalon because that definitely fits within our bucket here. I think what's interesting is, and then my next question on the slide, which I think I remember is, you know, it's kind of interesting that, you know, a lot of the conversations are hyperledger versus Ethereum and you can see kind of Ethereum's definitely already in hyperledger and has kind of a very interesting perspective to bring. But I guess I'd love to hear maybe, Dan, if you can maybe start with answering the question, how does Ethereum fit into the hyperledger story? What would you say to someone who might be confused or just new, you know? Right. So first I would say, perhaps to back in say that this is kind of an interesting union between the old cypherpunk mentality that Bitcoin emerged from and the enterprise mentality that stuff like CRM comes from. Enterprise has a need for these control databases and cypherpunks have a need to be away from these control. And it'll seem like contradictory requirements on the surface. But when you get something like Ethereum together, both purposes can be served. You know, Ethereum has its decentralized, permissionless. At the same time, it provides a lot of the control and the security that you would need from a CRM type solution. Now by default, Ethereum doesn't have really good privacy solutions. So it's another thing to put on, like, you know, you can do a ZK smart, there's one thing you can do straight on mainnet today, or you could create your own private version of an Ethereum blockchain with some of the private consensus mechanisms. So to step back to the original question, the role of Ethereum in the hyperledger community is to sort of merge what sometimes appear to be contradictory needs of different members of the community and show that they can work together. So at the same time, we have, you know, all of these ledgers in the ledger category can be used all in private network, and they work really great in private network. That's there. They're primary, what they were built on a lot of these, but basically also shows that you can work in public networks and public openings. I hear Fabric has one that's open to the public as well. So it shows that, you know, what you might think about these DLTs being only locked behind corporate firewalls and only accessible with millions of dollars of, you know, support contracts and everything else. And, you know, as far as, you know, permission to get into these networks and members of consortiums, you can do that. You can also do it in the permissionless form. So the role of the Ethereum, the project in hyperledger is to provide these bridges and to let people go where they need to go with their business and to bring people in who ordinarily would not be in hyperledger all the same time helping everyone across the board. Yeah, I completely agree that I just want to add that on top of all that, you know, if we end up with silos, then mainstream adoption will likely not happen or will not happen as well as it should. So I feel like everyone in blockchain should somehow aim to work together and have some sort of interoperability because, you know, silos, financial or otherwise, you only have that's the traditional systems that were there before as well. And that's what some people who have invented newer technologies are trying to get away from. And also just in general, you know, it is written down in many places that hyperledger tries to be an inclusive community and therefore it should be really, really good to have Ethereum included in there as well, Ethereum based projects. For sure. And with, I mean, you know, all these different projects have been contributed and worked on now by so many different companies, you know, some of the leading companies in the world in the blockchain space, if not all of them, maybe arguably, you know, although that mind share I think only votes well, I think someone's going to come up mute sorry and ask a question. No, I just wanted to point out that Mark was asking or making a comment about the computational cost of Ethereum that is included by design. And I kind of got interested in how do all of those hyperledger projects deal with the gas and the cost of running Ethereum nodes? So I think only the EVM languages have the built in gas restriction of it. One of the novel features of putting the gas in is it puts a bound on uncontrolled execution. The sophomore year of computer science, everyone learns about the halting problem. You can't look at a program and figure out if it's going to terminate or not without actually running it. So Ethereum put into EVM a gas restriction and a gas limit when you run out of gas it terminates. And the big advantage we get there for hyperledger, not for hyperledger for Ethereum, is that you can run every single execution at all the times and be sure that it terminates in the same way, the same situation and a reasonable amount of time. So what other blockchains have done to get around this issue, particularly fabric, is they run kind of a form type situation with their chain code. They'll ask multiple nodes to try and run their chain codes. And you get the same result from enough of the nodes, then they accept that as the answer. And I don't know in particular as to how they deal with runaway chain codes and other sorts of ways where it fails, but you get three out of five, four out of five, nine out of 10 different nodes saying this is what the chain code results and they accept it as basically a quorum vote. So that's one way to get consensus is everyone agrees on the results. And I think that's the big way a lot of people go when they don't use gas, as they go to the enough people agree on the result and it's the truth. Hey, so related to that a little bit, but can you clarify here if Ethereum, clarify the difference with quorum versus Ethereum and are we talking about quorum here or are we talking about public Ethereum, just trying to understand how that comes together here. So go quorum. Go ahead, Grace. Yeah. No, it's a good question. So there's kind of different layers of Ethereum that's worth talking about. So there's Ethereum public chain that Rai was talking about where there are main clients that run there. One is Beisu, one is GeF for example. And then there's also the permission layer. So there's permission clients. So go quorum or quorum is only runs as a fork of GeF and only runs in permission settings rather than running on main net. So it's kind of a, I think the best way to say is yeah, the fork of GeF. What am I missing here? Probably the work that's going on with some of the stuff like QIBFT is going in in the future. That's Enterprise Ethereum Alliance is another group that's not Hyperledger that is getting some standards to work between these private Ethereum clients and also some have their own software and some work entirely on public networks with additional microservices put on beside it. But one of the exciting things coming out of there is working on a standardized BFT algorithm. So you can get Beisu nodes and quorum nodes working on the same. I mean, you can really do that with a click consensus algorithm, but a consensus algorithm with finality that you can have a plurality of clients on a private network. And when it comes to systemic risk, getting multiple client implementing a spec reduces one of the risks. I mean, that's the legendary theory of what they do on a space shuttle. They have brief control systems. Two are made by one vendor and one is made by another vendor from spec. And when they disagree, the humans have to intervene. This is probably worth taking a step back there. That was a good way to end it. I shouldn't jump in, but no, I think they're all Ethereum, right? So it's like when we say Ethereum, but and Beisu and go quorum are Ethereum clients, it just can do different things, right? So Beisu can run on main end permission chains, go quorum can only run on permission chains. Just to kind of clarify that, because I don't think I did a good job at the beginning. Does that help? Yeah, I think that helps. It's, you know, there's a lot of different pieces going on here.  So there's all these different types of ways to do it. And probably eventually a lot of stuff is going to go away and get absorbed into other big, bigger projects that'll be kind of the umbrella of the whole thing. For sure. We'll see how that all goes. Let's do, I think next we have a poll, maybe to kind of pivot away, or at least dive into more kind of the project experience, what other questions people have. Marta, do you mind team up the poll for the group? This should be visible now. Yeah, it looks like two questions came up. Yeah, because, yeah, I kind of assumed that you wanted the two questions together. Sorry. Yeah, no, that's fine. So two questions. Yeah, have you tested or used the Ethereum projects in Hyperledger before? Two, what is maybe an objection for using Hyperledger as a Ethereum based projects? Or just using Ethereum generally? Probably a better way to phrase that question. And it'd be really awesome if you got the same participation that we had on that first poll. Yeah, well, let's see how it goes. We still have some people, come on. Marta, you didn't do the Jeopardy music this time. What happened? Oh, gosh, I'll pull it up for the last one. We still have participants. Yeah, waiting. I really love the conversation and I thank you so much, guys, for also running the conversation and chat. I think it's really productive and interesting. So great, great job in making this meeting really interesting and attractive. Oh, Todd, why are you not seeing the poll? So you can, you can vote in the chat or you can tell us. Have you tested or used Ethereum projects in Hyperledger like Besseboro or Cactus? And the answers are yes all the time. Nope. Or I've tested at least once before, but I'm going to start testing them more. I'm going to have to go with no. Okay. And question number two, what is an objective for you using Hyperledger's Ethereum based projects? Is it worrying about using a public blockchain, for instance, with the privacy and security issues? Is it a crypto, because it's a cryptocurrency, so you're worried about loss of funds, regulatory and tax concerns, or maybe lack of knowledge about them? Or there's no real blocker for you, just didn't get a chance or nothing, use it anyway. I work in the regulatory compliance space, so I would have to be the one about taxes. Right. So how do you see Ethereum from regulatory and compliance kind of a perspective? Well, I think there's going, there already has been a lot of efforts where regulatory bodies are forming sandboxes, and they actually want to talk to people in the blockchain world. I think that more of that has to kind of go mainstream. I'm a little dismayed by some of Janet Yellen's comments last week about cryptocurrency, and very concerned that it's primarily used for criminal activity. And I don't see it that way. And I'm hoping that we can make more efforts to comply with regulators, so people feel more comfortable using, especially, and again, in the risk and compliance space, because there's so many wonderful applications for it. Yeah, that makes total sense. I'm based out of the UK and actually over the change of the years, the year. So moving to 2021, the regulations changed completely, so now you can't trade on cryptocurrency derivatives, and it's so complicated. And I just don't understand it. Why would people do that? Like, there are so many opportunities. Well, when I bring it up, people's minds go right to the Silk Road, they go right to Mount Don, so we're trying to get past that. Oh, yeah. Oh, yeah. And we only use Bitcoin to, I don't know, pay ransoms or something. And while we're talking about it, Grace or Dano, there is a question from Shoaib about how does Ethereum or Gath integrate with the Hyperledger Aries or other self-sovereign identity networks? I wouldn't dare. I guess the short answer is that it doesn't integrate with it at this point. Yeah. So yeah, if there's integrations that work through this standard Ethereum, based on RPCs, it would integrate. But there's nothing specifically built into Bezu, and I'm not familiar enough with the Aries project to know if they're running it as a layer two and committing their dits to Ethereum or what that would look like. I know it's an outgrowth of the Indie project, so and I don't think there is too much integration between Indie and Ethereum. So, I mean, it's a great opportunity to do some integrations to get some Aries stuff working on there. I just, I've got so much random stuff going on with things like Ethereum too and working on my Bonsai tree project that I just haven't had time to look into that particular project. Yeah, I think it's a good, great point of how the integration happens and has to happen on both sides, right? It's both on the Bezu or Borosite and the Aries side. So I think we need to build some bridges and if any of you attendees or participants would like to join those efforts, absolutely, please, please help us building the bridges. I did share the results. Very interestingly, 63% says that they've never used Ethereum. Oh, I guess the question was a little... That's not the way I read the question. Yeah, that's not, I don't know, that's not really the question. The question is if they've used the Ethereum projects in Hyperledger before. So, Bezu, Borough, Cactus, I should add Avalon to it. I apologize for that poor Avalon. And I think this is perfect because we're going to tee up ourselves in a few minutes here on how to you can get started and hopefully set up your own private network or run your own node, all those things and test cactus, all those things. So hopefully maybe a few of you on the line after this conversation will maybe take that up and try them out yourselves. The second question is interesting. So similarly, what is an objection for using Hyperledger's Ethereum-based projects? Nobody really has a blocker at 38%, which is again very exciting, which means that you all have lots of free time and we can show you how to contribute in your good first issues in a few minutes. What would you say? So we kind of talked about cryptocurrency and maybe like the regulatory concerns around Ethereum. We haven't addressed the first part about, you know, I worry about using a public blockchain for my solution, privacy security. What would you say to that? Maybe Ry, do you want to start? Yeah, I actually was going to say something. Yeah. Well, the first thing that came to mind is interestingly with advances in cryptography, you can do private things in public. You can encrypt things so that only the parties that you want to, you know, be privy to them can see that. You can offload computations to someone to do that you can prove that we're done correctly so that the computations aren't done out in the open. So increasingly this is becoming kind of a false dichotomy. The results just disappear. Yeah, it looks like they were taken down. Does anyone want to jump? Let me relaunch them, sorry. No, it's okay. So I maybe ask someone, you know, if you've used the project before or any of these projects are used Ethereum before, what has your experience been? You know, I'd love to hear kind of good, bad, otherwise, and that would be interesting for the group to hear. Especially the bad. Hopefully all good. No, definitely the bad is always helpful too. I can speak to one that we actually had worked on within Ethereum. And one thing about public blockchains is, you know, what they do, they do extremely well. And that's primarily the transparency that anything on there can is perceived as being discoverable by every other person that's on the network. And that has generated a lot of concern with CIOs and CTOs and CISOs because I don't want really to reveal anything about what I'm doing that's going to be visible to anybody that could be a competitor or a rival or anyone that just, you know, probably wants to come in and just really disrupt everything. And that's really been, they want at least that ability to kind of, you know, sit back and, you know, kind of cloak what they're actually doing, but still have all the other benefits of a public blockchain.  And, you know, some people would say that keeps everyone honest and that keeps everyone working together, but it also generates that awareness. And that's the awareness of everyone else knowing what you're doing makes a lot of people nervous. And it's been my experience that once that mind closes, you're not going to get it back open again. So generally, with a lot of the advances of cryptography, and now that we have a lot more of the enhancements that Ethereum is capable of, you're starting to, you know, get some more people interested to say, hey, you know what, maybe we'll take a look at this again. Because they're running into, you know, problems with scalability and last mile when it comes to their private permissioned blockchain projects. Yeah. Mark, thanks for sharing that. That's like, that's great feedback. I think that's definitely been something I think me, all of us panelists have heard one or two times before, and it's a theme, but I think you're right that it'll be interesting kind of to see as performance improvements are made, maybe ETH2. You know, I think that story might change with Ethereum. And I can share with you a practical thing that we actually worked on back in 2017 was within healthcare provider credentialing. Credentialing is, it's a persistent problem. It's very costly and it very frictioned and it takes a long time. And the idea starting off is that we were going to take these credentials and we were going to tokenize them and put them on the Ethereum mainnet. And so that they could be exchanged between, you know, payers and providers so that they could, you know, onboard onto their networks. But at the same time, the payers then had up-to-date information so that they could maintain complete and current provider directories. And these are problems that have existed for a long time. But the idea of actually putting a digitized credential, you know, with all of the identifying information directly on a public blockchain really created a lot of concern. And the project went nowhere.  The project went nowhere. So it's, you know, really a lot of the latest, latest advancements within Ethereum as far as, you know, with off-chain and with Merkle trees were born out of really that need that you have to have some type of masking or at least some type of, you know, they don't want that much awareness that's generated by the transparency. That's what I got. Right. Right. And I think you're right. There's a lot of the new things coming out that are going to be able to put like a hash commitment and you'll be able to bring a proof out and prove it against the Ethereum chain. That's what a lot of the layer two stuff is doing like baseline. And it's even getting deep into the protocol. There's something in Ethereum called witnesses where you don't have to have the entire blockchain to prove a particular block to the thing. You get a cryptographic proof of it. And in theory, there's a database, but you don't have to have the database to prove that it worked. So I think there's a great bright future for a lot of that credentialing going on through these layer two technologies. Another thing that I commonly ran into is, all right, if I'm going to basically, you know, put forth a Ethereum based solution, do I have to set up and maintain or set up download and maintain a node? And I'm like, yeah. And that's another when it's going to outstrip so much of the resources within a lot of CIOs have within the current IT architecture. For sure. No, I think that's great feedback. I think it's interesting. Yeah, I think Dano made a great point about kind of the layer two options and different performance or privacy improvements. If it's privacy groups, private channels, side chains, I think that's kind of definitely resonates with a lot of work that we do at least. I want to take a step back, if that's okay. And then I'm going to open it up for lots of questions. I've seen a couple of questions come in from the Q&A box and to the panelists directly through the chat, basically trying to clarify, you know, I haven't, one person is saying, you know, I haven't used Hyperledger with Ethereum, but I've worked with Ethereum on a public network and I've experienced a great deal of latency. Is anyone concerned about that? And then the other question, so before we get to the latency question, I'm going to pause on that because we do have a good answer for that. The other question is going to be, is around Basu being an Ethereum client or does it work with other Hyperledger networks or is it distributed ledger? Maybe taking just like one step back then I'll answer the question about latency. I think, so when you're thinking about Hyperledger, I think there's some confusion around, for when we say Hyperledger, are we only talking about Hyperledger Fabric? Are we talking about Hyperledger Sawtooth? And in fact, Hyperledger is a greenhouse of many projects. So you can see kind of, this is the greenhouse we showed a little earlier, we didn't really explain it, just said, you know, here are the Ethereum projects. So to clarify, so in the top layer here, there are a bunch of different distributed ledger technology projects within Hyperledger. One is Hyperledger Basu, which is an Ethereum client. So it's just a type of distributed ledger. Another type of DLT is Fabric, another one is Sawtooth, and the other ones listed here. So when we're talking about Hyperledger, we're actually talking about kind of this greenhouse of all these different blockchain projects, which is pretty cool. It's not just one or the other. So just wanted to take a step back because that wasn't clear from what we were talking about earlier. The second question is around latency when using the Ethereum public network. And is anyone concerned with that, is how the person worded it, but also how do we address that in different solutions? Who would like to lead that? Dan O'Ribe, what do you think? Yes, so just clarification, latency is kind of the time to when you make a transaction. So who has this question? Ron Johnson, I think? Yeah, so Ron, what you mean by latency is it, you know, the time between you make a transaction and it's included in the blockchain. And you can, yes. Yes, so right now the reason for that latency is because you want some time for a block to propagate through the network. And so there's a parameter in the protocol that kind of sets how much time this block is intended to take and kind of adjusts parameters so that it continues to take that long so that you don't have all of these splintering forks in the blockchain. And so as far as I can tell, maybe Dan O'Ribe, you can correct me, but even for the future of Ethereum, ETH2 proof of stake, there's going to be some parameter which is going to have to introduce some latency in order to deal with like the network latency of propagating information around the world and two nodes that will participate in the consensus process. Yeah, so yeah, the latency is kind of just, it just kind of comes bundled in with this kind of distributed consensus forming. And that's part of the question of whether you're going to do a public network or a private network. In a private, what makes it so crowded in the public network is everyone's using it for their own purposes and you need to compete for space and you pay with that for Ether. So that's how they incentivize people to run public nodes is there is an act of createable token that has value in only one chain, which is the Ether. People created it in exchanges and miners mine it and that's how the economics there in a consortium network, whoever is participating in it is going to agree on who runs the nodes and make sure that they run up themselves. So the incentives there are different in a private versus a public network. So on a private network, you can get much better latency times. You can take your block time down a few seconds. You can put a hundred million gas in each block if you want. You can get hundreds of TPS per second on an Ethereum network with Ethereum transactions if that's what your requirements are. And if you added layer two technologies, you can get some particularly well architect solutions can get up to 10,000 of TPS per second on layer two if you do the layer two architecture correctly. So the latency is all about the design. You can have everything affordable latency to awesome latency, depending upon what incentives you want to provide. And they all come with tradeoffs of each level. Also, there'll be, you know, types of interactions when they're within institutions that will be, you know, centralized like they are now and very fast. Like if I send a transaction on Venmo to someone else on Venmo, right, that will be instantaneous because they can do that centralized. Even in this kind of blockchain label world, you'll still have, you know, some of these silos, but then they use that settlement layer for, you know, cross institutional interactions and, you know, across trust boundaries. And just to pile on the latency topic, my personal opinion is that they are technologists and they usually work on improving stuff. So I fully expect that to get better over time. So if you really want to develop something that is forward-looking and then you kind of have to make assumptions about the future and make some bets. And one bet I would make is that latency is going to go down. I like that, but Peter, I'm going to take it too. So we only have a few minutes left. So any questions you have, drop them in the chat. We'll probably take a few and then if we need to stay on, we'll answer them at the end. The first question that we have here is, is Burrow actively developed? There are commits in its GitHub page, but its Wikipedia says that it's an incubation status with the roadmap from 2019. I do know it's currently being actively developed and the team working on it, but I don't know the latest updates at this point. Yeah, it's my hobby horse. Incubating active is about community size and project size. It doesn't mean whether or not it's production ready. And every time they have that discussion, there are people with government say, well, I have Burrow in production. It's used in fabric nodes to run their paint code. So yeah, there's not much fancy stuff going in. It's pretty functional in it. So I think that's why it's a little slower in the commit speed than some of the other projects. Yep. I know, yes. We like to clarify that because yeah, just because it's an incubation status does not mean it can't be in production. There's one thing you take away from that. We'll be very excited if that's it. There are two more questions around contributing, which is really teaming up just beautifully. So it talks about how, how do you get started? One person asked about Basu specifically. So we'll jump, we're not going to skip the use cases slide. Sorry. And we're going to start, we're going to jump ahead to the contribution section. And then after this, we'll have one final poll for everyone. And then we'll take any final questions at the end. So, Dano, how can you get started with Basu? So if you go to the Hyperledger Basu GitHub, we have some good first issues. We still have some of them. They come and go. Contributing to a blockchain client can be intimidating. You're not going to be creating new data storage formats on your first commit. So we recognize that. So we picked up some things that we could fix, stuff that I could fix in an hour and afternoon. And we leave those aside as good first issues. One's that touch various parts of it and offer it up to the community for them to take their hand in contributing there. But also, we'll take contributions at all levels of experience. If you're a deeply experienced Ethereum developer, we want to hear from you as well. There's a couple of community places you can go on. We have a chat room at chat.hyperledger.org. We actually had two. One for Basu is for general discussion. And the one of Basu-contributors, we tend to limit to things about things going on with the source code. When we're cutting a release, we'll say, hey, please don't commit stuff. When I need to have a review on a PR, sometimes I'll put a request out there. If there's questions about what we're going to do with, are we going to switch the tabs into the spaces? We're not. But that's a discussion we would have there. So that's also on chat. We also have an email list which has about the same level of email engagement as other Ethereum projects. Actually, we're doing a bit better. We get about one email a month. The Ethereum community just doesn't like email. It's weird. But another thing is you can run and execute Basu. There's a quick start to get you up and running. If you're going to sync to a public network, I would recommend one of the smaller ones, like Gorely, that you can accomplish in a reasonable amount of time. Mainnet is very heavily used. It takes a while and good, decent hardware to synchronize. But a network like Gorely synchronizes in less than an hour. And there's one called Ethereum Classic. We support one of their tests that's called Mortar. That one will sync really quick. There's also hardly anything going on because of why it syncs so quick. But if you just want to play with that, it's pretty easy to get Tet and an Ether on some of those smaller ones. It's not too hard to get the Ether to do your stuff. And you can always start up your own private network to just test run your own contracts. You can, you will click node was as few as one validator. So I'm here to send you a direct message. No.  And with external contributions, we try to have a quick turn around time so that the experience is good for you as a contributor. You get to see where we're valuing the contribution and helping you along. Yeah. And so definitely chat at hyperledger.org is a great place to start for all hyperledger projects. And specific questions on mentoring or volunteering opportunities or internships and all that, that's a good place to get started.  Yeah, Dan, you're raising your one thing I forgot to mention about hyperledger. All the projects are Apache to license. So that's a big opening for a lot of corporate development. There's a lot of corporations that won't allow customization of code. And of the theorem clients that we mentioned today, go quorum, get another mind and open Ethereum, those are all GPL. So basically unique in being Apache licensed along with cactus. Yeah, that's a good point. Peter, how can you get started with cactus? Yeah, so I won't bore everyone with repeating everything we're bringing that Dan, who just said about basically, I'll just say take all that and replace the good basic with cactus because it's all true for us as well. And then the one thing that I wanted to highlight is that cactus is not yet production ready. So just wanted to make sure that everybody's aware of that. But at the same time, yes, really, we are trying to be as welcoming as possible as well. So also happy to have direct messages about any questions anyone has. Amazing. With that, I know we're just out of time. We have one final poll that we're going to ask you all to respond. So this is just a first session on Ethereum in the hyperledger community. We'd love to hear more about what you want to see next time. Maybe if you liked the session, if you didn't, all feedback is welcome. We just want to make sure this is interesting for you all. So if you don't mind answering this final poll, that'll help us kind of plan it for, you know, if a next Ethereum session would interest you all. And as you're answering your questions, you're welcome to speak up and ask any final questions as well. I wish I could select at least two of them. I know, yeah, it's two, but I should, yeah, I kind of made everyone decide, you know, I didn't have an option of no Ethereum session. So, if anyone has better ideas, and we would welcome any other ideas, please do email me, Grace, I'll pop my email into the chat. Please feel free to communicate with us. We really want to make this as useful to you as possible. If it's, you know, hardcore hands-on coding, if it's high-level business, it doesn't matter. We just want to make sure that we are bringing value to you. And again, thank you, Grace, and the whole team for an amazing session. I really appreciate it. I thought that was really interesting. Currently, we actually, it seems like we'll have to do all four sessions because it's literally 25% each. So we might need more than one, which is great. And we hope that you can just share the news with your friends and colleagues, and hopefully other people will join as well. Yeah, so I'm just popping in my email into the chat box. Otherwise, you will find us on LinkedIn and Signals and Chats and everything else. So please feel free to reach out. Yeah, we have almost, almost even results. Yep. I wasn't expecting that, but yeah, this is the first of five. This is the first of five. Well, thank you, everyone. Just a quick recap of what we will be offering. This is part of a series that we do, and we do have more coming up. Two sessions that are definitely happening are on February 3rd with Intellect EU on deployment Hyperlegio Fabric Networks. And then everyone will be talking about their SSI and COVID. Again, it was a dialogue session. It is not a broadcast session. And definitely as soon as we talk or get back together and talk about the Ethereum sessions, we will plan some and you can find everything on hyperlegio.org slash events. And please do get involved. Here are some links, some QR codes, you can scan them, you can publish them. And thank you for watching. Thank you for dialing in and I'll talk to you soon. Stay safe. Thank you. Thank you. Thank you so much.