So welcome everybody. This is not the normal TOC called Technical Oversight Committee call for Hyperledger. This is the call that is focused on the task force. So specifically the Badging and Project Lifecycle Task Force. But two things that we have to be aware of. The first is the anti-trust policy that is currently displayed on the screen. So obviously there's competitors on the call. Make sure that we're not doing anything that will violate any of the anti-trust policy laws across the world. And then secondly, our Code of Conduct, which is linked there in our typical agendas, but not an agenda for today. So, but just basically be respectful to everybody on the call for their opinions or ideas and we'll get along just fine. So with that, I'm gonna hand it off to Ramo so that he can take us through the Badging and Project Lifecycle Task Force. So this is a working call.  Thanks, Tracy. Yeah, I just, and thanks for going over the policy. I just flashed one of the CACTIM-18 is an agenda page because I didn't have a new page for containing the policy notice. Let me get the tab. Okay, so I'll go over the wiki page that I created a while ago. And I think the last time we got to talking about this, which was the first time we discussed the Badging Lifecycle Task Force on a TLC call was, I think I got about five to 10 minutes and I just did a brief overview. So maybe we can go into this in a bit more detail and then like to drive discussion and get people's suggestions, recommendations. And then we can sort of add to this page and make the recommendations more concrete. So this is, so what we had earlier at least in Tracy's description was a bunch of links that were, that bunch of links for earlier discussions around this topic. So this is not strictly speaking an original Task Force action item, but this has been, this was discussed, I think two or three years ago. And so I looked at that discussion and some of the, and I summarized some of the discussion that took place at the time. So we need to take that into account. And also we need to look at the different project life cycles that we have as references. Of course, our Hyperledge Project Lifecycle and also the Linux Foundation Networking Project Lifecycle. So the goals can be summarized in this way. How do we accurately and comprehensively represent the stages of a Hyperledge Project Lifecycle in order to make accurate assessments about a project's health and make appropriate decisions on its future trajectory. So that's where we have to figure out what is the necessary and sufficient set of project stages as well as some kind of labels that indicate how a project is currently doing and where it is headed and how the TOC can govern the project in a manner that is fair to that particular project. So broadly, it looks like we can take two approaches. Either we augment the current project life cycle with a set of review labels each associated with a review criteria and rename or split or merge states as appropriate. So that the process and criteria for each state transition is clear and unambiguous. Or we can use a badging system whereby each project will be issued a badge that attests to a set of attributes or criteria that the project is deemed to have met. So each stage in the project can then be represented by a set of badges. So with badges, we don't get rid of a project life cycle. I think project life cycle, we have to have a project life cycle that indicates what the current stage of the project is and whether or not it's heading in the right direction. But with badges, we can have a state transition diagram where each state transition criteria will clearly state what badges are needed for a project to go from one stage to another. For example, if you want a project to go from incubation to graduated, which is I think the most important transition the project will be making, then we can identify a list of badges that the project will have to acquire while in its incubation stage before it can be considered for graduation. So is this clear enough to people think they need anything more for the staff force or any comments? Peter? I think this looks great as it is, no further comments. Okay, Bobby? Hi, thank you for acknowledging my hand. I think this is great. We're working on the task force for the documentation, task force on something similar to this just to have user guides. And we had Alfonso from the mentorship program talk about learning tokens. And I was curious as if maybe we can tokenize the badging system so that when you reach so much criteria you have like five tokens and then I'm not gonna say this correctly but you could burn that for the graduation token badge that gets on your project page. And then when you reach a certain point where you wanna go to graduated you've earned so many more tokens by meeting so much criteria that you get the graduated badge token and then that comes with a smart contract that needs to be updated. So it's like got a timer on it so that when your documentation or your project has many amendments to it you have a certain time period in which that badge expires for you to update. Like is that the kind of idea when you say badging that you're talking about or is it more of a static bed where you get it and then it's done? So this is something we should, we can discuss further. I think what you've just articulated can be a particular, can be a badging criteria. I think the discussion that happened within the Hyperiget TSC a couple of years ago involved something somewhat more static. This was a recap of that early discussion. What the TSC was thinking about at the time was that there would be a certain set of... If a project met a certain criteria then it could automatically self-certify itself for a particular badge. Example, legal refers to if the project has... If the project repository, the code in the project repository is all clearly licensed and there are no gaps, then I think the project can self-certify itself with a legal badge that is being legally compliant. If it is decentralized refers to whether or not the project has enough diversity of maintainers and so on. So testing refers to whether it's been... It has an adequate test coverage, whatever adequate may mean. And documentation, whether or not the documentation is comprehensive. Again, that discussion did not go into how the assessment for these will be made. If we go through the conversation there, people are talking about self-certification and some people had concerns about whether or not a project could be trusted to self-certify itself. But then if project cannot self-certify itself then it will be up to the TOC to constantly be reviewing or either issuing badges upon request by projects maintainers or if project demands a particular badge then the TOC will have to review it. But I think if your proposal or your suggestion, I think may streamline this if we can figure out exactly some sort of automated way by which a project can accumulate tokens. So I would like to understand that a bit more before we can figure out how that can be used to create these badges. So just to be clear, the notion of badging projects was not, I think, agreed upon during this particular this round of discussion and it was discussion happened, but then it was benched and then we have since been following the project life cycle. But yeah, so can you say more about how, Bobby? I mean, can you say more about how you think the token system can happen? I envision the hyperledger community actually engaging in tokenomics, so to speak so that every project as soon as it became a GitHub lab would I guess have its own project dashboard and have the dashboards set up so that when you are compliant with security issues you would put a check there and then the system, the dashboard would issue that I'm gonna call it an NFT token for security then you finish your testing. You check that off and then you get the token for testing and then when you have, I'm looking at the categories, one, two, three, four, five, six, seven, eight, nine, like say 10 categories in order to get into the labs that you have to have done. And once you check all those off on your dashboard it will automatically issue the badge to your Wiki page or homepage of your project on the website wherever that lives that you've got that badge and that would maybe initiate a call to the TOC that you're doing this or initiate the next steps to move into labs. And then once you're into labs the same dashboard would have a different checklist of things that you needed to accomplish and get tokens for before you would get kicked over to that conversation of moving into graduated. And if you had all your tokens and you went to the TOC and it got approved you would get that badge you'd be a graduated project and then I guess we're doing the yearly checkups at the beginning of the year but maybe there'd be something in that smart contract that said after a year you need to revisit your security, your legal, your releases, your testing and then you do that and then your dashboard gets that update badge or year two badge or whatever. So that as soon as you look into a Wiki page or a homepage for that project depending on what badge is there you know exactly where they are in the life cycle. That was kind of my idea. Thank you. Gracie, I think you've had your hand up for a while. Yeah. So I like the idea of having to look at the status on a regular basis, whatever that basis is whether it's a year or six months or whatever that timeframe is, right? I really like this idea of having to kind of recertify to ensure that you are at a particular stage in the life cycle. I think if we go with some sort of mechanism to issue badges it should probably be a verified credential but that's just my opinion because they are not transferable and then we could also revoke them or expire them to allow for kind of that recertification aspect of things. So I don't know if that's... I know why you're suggesting it Bobby I'm just not sure if it's more than we want for the perspective of this task force. Obviously there's gonna be some work that's involved there that's going to have to be some blockchain service that's running that we could be able to utilize and there's cost involved there obviously. And so I think we just need to think about the consequences of doing that. I think it's a great idea from the perspective of Hyperledger and blockchains in general and using the tools that we have written within the project or the foundation. But yeah, just let's consider everything that's gonna need to be done if we do go down that path of running a blockchain and having an issuing application and a wallet and all of those sorts of things that would be required from that perspective. Thanks Shrivi. Bobby, you have anything else on that? Before we move on. No, I think that's all. I'd love for you to join our Monday meetings just to see where we're at. It's on the public calendar nine o'clock Eastern time Mondays. Sure. Arun? Thanks Rama. And then this was a good discussion based on this discussion I have my mix of multiple statements or probably comments to be made. I really like the idea of having a dashboard which kind of shows us the progress of a project and how well the project has been doing over a period across multiple aspects that we identify that is required. I really like that idea. So if we want to achieve it via blockchain or just through some means of dashboarding, it's on us. Let's see if that's possible to do. Continuing on this discussion, I believe when we start looking into what should we label in those dashboards and what should we indicate in those dashboards? I guess it goes back to some of the metrics that we want to consider across projects. And this is the mixed set of opinions that I had, right? So going back to what are those metrics that we want to try? I guess it takes us back to the existing portal that we have through LFX to look into what additional dashboarding capabilities do we need using those metrics? I think all of this connects to the similar opinion of having a unified portal or an experience dashboard where we can see what's happening across a project and probably now we should start looking into how should we achieve it? Also as part of this task force, if possible. Okay. Thanks, so just to be clear, so we want one dashboard for all the projects so we do, we want one dashboard per project. No problem, do we want having those metrics details mentioned under the read me of each repository or if that's confusing for some of the projects because they have multiple repositories, then a dashboard where somebody can see those statuses. It could also be through our annual report cycle or maybe quarterly report cycle pages where they mention about these, where we mention about how the project did in that quarter. Right, I mean, I was, I wanted to bring up the question of, or rather link this process to the annual review process that we've already been discussing. Tracy. Sorry, I'm trying to get myself off you. So I remember, I think it was last time we kind of quickly touched on this particular task force. There was a website and I think it was for SNCF, but it could have been for something else that basically showed for all of the projects, kind of a one page website that had kind of red, green sort of responses. And I'll see if I can find that in our Discord chat from previously, but I think that, if we're talking about a dashboard, it does make sense to have a combined one so that everybody can see kind of the status of the Hyperledger Foundation projects. But I think it also does make sense to have the ability for people for projects to be able to display, you know, either on their GitHub, Readme or some place on the wiki or their project or somewhere, right? Maybe multiple places. A page that basically says, here's my badges, right, here's the project badges that we've achieved. Here's what we're working towards, right? Here's the things that are grayed out, if you will, because they haven't been achieved yet, but how do you think that being able to see both options is a good thing? So let me see if I can find that last one that we went through and put it out in the chat, the TOC chat. So thanks, that'll be great. So each project then could have a page called something like badges.md or lifecycle.md, would something like that work? Yeah, something, and it doesn't have to be like, it could be generated, right? So that we're not having the projects have to generate that, but something that could be easily displayed from the GitHub repo or from the wiki or something like that. So that if I wanted to find out what the status of CAFDAI was, I could go to the CAFDAI GitHub page and see like, oh, look at, this is the badges they've achieved already. There's still these other things that they need to achieve and just a place for somebody who is interested in a particular project versus interested in the entire foundation and the progress there. So every project, by the way, right now already displays badges for its feature testing, right?  So can we tag these badges onto that or do you think that'll be too confusing? We need to have a separate. I think if we can make use of GitHub, functionality in any way, shape, perform and then we should definitely go ahead and do that. Okay, then having GitHub action for this, I think sounds good. Thanks, Bobby? My only, getting back to the question about how to organize these dashboards, I initially had thought it would just be as soon as someone applied for a lab because you're kind of giving them a resource by letting them set up a repository and then that would be the trigger but then you're right, you're gonna have like 64 or some odd dashboards. So another way to organize it would be by maintainer whoever sets up that repository would own that dashboard that everybody could see but it would be theirs to admin. And then the only other way would be once it's in gets out of labs into incubation, that's when it gets a dashboard but then you're like leaving those lab projects behind but the one that makes the most sense is I guess once it becomes a project tool or library in incubation it would get a dashboard. Thanks, yeah, that actually brings me to something I made note of here. I think if you compare our Hyperlegia Project Lifecycle to the Living Foundation Networking Project Lifecycle this one has, it seems to incorporate a lab project within its life cycle whereas ours does not at this point. I think our Hyperlegia, the proposal stage here refers to a project being proposed as a full project and not a lab project. Whereas if you look here there's a sandbox stage for a project and I think that kind of refers to is the equivalent of our lab project and because it's considered to be a project that is not quite ready for even be a full project because that would be the incubation stage but so therefore they call it as a sandbox project. A question for the TOC is do you think we should augment our life cycle diagram to include a sandbox and that would partly address Bobby's query. I mean, it doesn't address the question of like how many the dashboard blowups that you have but at least if you want to incorporate the Hyperlegia Labs project within, we want to capture Hyperlegia Labs project as a Hyperlegia project or as something that has a potential to be a Hyperlegia project. Then should we have another stage here and just have the lab project be at that, let's say a sandbox stage or a lab stage before it goes to incubation because right now labs just aren't covered in this. If I might, I think it would be interesting to formally extend the project life cycle for Hyperlegia to include something about the labs but that's not a fully formed thought, so. Thanks Frank. Peter, I think Peter you were the first so I can't see the harder but. So good. Yeah, I was just going to kind of reiterate what Ryan was saying which is that this might be a good idea but I have not been thinking about it in the context of the passion. I would say maybe that's another decision that we should consider separately, take our time to figure it out because depending on how we do that it might have an impact on the labs or maybe not. Yeah, it's highly dependent on what does that imply if we change the life cycles to include the labs then my big question there is what does that mean exactly apart from just it being documented on a chart does that trigger any other changes that now we have to push on the labs or not? Well, one thing it will do and I think I made a note of that somewhere is it will articulate clear criteria for review of a lab project to determine whether or not meets the criteria to be an incubated, a full project and incubation. So just have it because I believe that when a project is approved for a lab that is at least a tentative expectation that it will eventually try to make a pitch for a full project, right? Because we don't necessarily expect that last project should just be a lab project and then die, right? So that was my thought and I'm hoping others who have been longer on the TSC who have served longer on the TSC can answer this question. I can't see the order in which people raise their hands. I see Arun here, I think Tracy raised her hand earlier. Can you please speak in order? The order is as it goes on the hands raised. So it should be Tracy. Okay, thanks Tracy. Okay, so my thought about labs being part of the life cycle, my initial thought was yes. And then I started thinking about the process that we have for labs versus the process that we have for becoming incubated. Our two different proposal processes for labs versus incubation. The labs proposal is obviously much simpler from the perspective of it may be fresh new code that's being started. It hasn't been, there's nothing that's happened yet. The formation of an open source practices haven't happened in the community. This might be the first time that they're doing open source. So we tried to make labs extremely easy entry. So removing as many barriers as possible from the proposal and what needs to be done. So, I think it's okay if we do include labs in kind of the overall description of kind of the life cycle aspect and what's required to be in it. But I think there are two separate proposal processes that we should maintain because of that easy entry aspect that we've tried to create with labs. So just a question on this. So if the, once it's a lab project, I mean if the project has been approved as a lab and then it continues to mature and maybe gathers more maintainers, improves in quality, could we not then have it accumulate these tokens or badges which would then allow it to be automatically, not necessarily automatically but allow it to be easily reviewable in order to judge whether it can be moved to an equation stage rather than have it to have submit a fresh proposal which I imagine will largely be the same as the original proposal, right? I mean, the goal of the project's likely to be the same unless it's maybe merging with a different project like we did with cactus because what you just articulated for lab projects sounds very similar to what the LF networking page has articulated for a sandbox stage. So just wondering. Yeah, I would say that they're probably fairly similar as far as sandbox versus labs, this general same idea. I do think that I probably can't answer the question yet about whether or not there would be enough to allow it to easily be reviewed to move to incubation. I think we should definitely take a look at what is required for incubation. We obviously have those pieces of information. I think if we do a good job with this task force then the answer would be yes, Rama. But I do think that it's going to require us to be very specific and sometimes we're a little fuzzy about what it means for these different stages. And so if we can be more specific about what is required in order to reach a particular stage, then the answer is probably going to be yes. Makes sense. Thanks, Jethi. Who was next? Was it you, Alyne? I think that's me, Rama. Oh, no. Oh, yeah. So I think it's important to remember what how labs came about. And by the way, for the record there's no lab project that's not a concept that exists. We have projects and labs. And there is a reason for this, which is the point of speaking up now is I think we must not lose sight of the whole premise of the labs was projects involve management, resources, allocation. There's a cost associated with every projects. And we wanted to create a space with very low cost that we could allow anybody to pretty much try something out. And so once we start integrating labs into project lifecycle, I think we're starting to blurry that boundary. And I don't know where we draw the line anymore. I'm a bit worried about this, but I just want you to keep that in mind. I want to take another one. Thanks. Arun, did you still want to say something? No, I think please, I'm not covered. I wanted to bring up the same point that Arun not just brought up. Okay, thank you. Okay. I think the discussions covered a lot of the points that I mentioned here. So just a question about the end-of-life stage. So this diagram has, it doesn't say end-of-life, it says archived, which means that a project that's currently been archived can potentially be a candidate for a project again, if it requires maybe another set of committed maintenance later. I'm assuming that a Hyperledge project at its end-of-life can do the same, right? Do you want to explicitly call that out, like have an arrow from end-of-life back to proposal or do folks think that's not necessary? I'm not hearing anything, so I'm guessing it's not, I mean, if you haven't, okay, Peter, you have an opinion? I was just going to say that I'm thinking that I don't have any immediate opinion in. Okay. Sorry. Okay, no problem. I mean, if you have anything, then please make a comment on the page, Arun. Yeah, I don't think it's, I don't think necessarily any arrow should be ruled out, right? I'm fine with moving projects around in unorthodox ways, if it makes sense. Yeah, yeah, that makes sense. Okay, let's keep thinking about this and if you have any observations on the diagrams, especially compare these two. So just looking at this, this seems a cleaner diagram than this. Of course, it doesn't necessarily mean we have to have such a diagram, but if having a back arrow makes sense, if it accurately reflects what a project can go through in the longer term, then maybe we should consider it. So on badges, so just on the term badges, I mean, we of course can adopt whatever meaning we want, but just to be clear, the Linux Foundation Networking Group specifies a list of badges for people actually, for maintainers and not for the project. So you have to make a distinction. I think this particular task force, when you're talking about badges, we are referring to some sort of credential that is owned by the project, whereas in the LFN, they are talking about a credential issue to a given meeting. Okay, I think we've covered this part, the LFN Lifecycle Accommodates Lab that we consider the Hyperligel Lab to be the equivalent of sandbox. And let me see. Okay, I think the, yeah, I think there's a notion in the LFN Lifecycle of a reversal, of project reversal, going back from one station to another. And I think we, in this, we can kind of incorporate that here as well. Have to go back and look at the full list of review criteria. So sorry, it's been a while since I made note of this, but I think there are some ideas from there that we could incorporate here from the criteria for whether a project should be downgraded rather than upgraded. Like here, if you see, there's an arrow from graduate to incubation. Here, we don't have that. We, instead, we go from graduate to dormant and then from dormant to incubation. I suppose that kind of covers this, but the arrow here, but yeah, we should probably discuss that aspect as well. Whether that is, I mean, in the LFN Lifecycle, they have, for each cycles, they have a forward review criteria and reverse review criteria. That is, what is the criteria that the reviewers will use to judge whether or not a project is ready to move to the next stage. And also in a review, what criteria will the reviewers, that is the, what's called the TAC in LFN, they'll use to judge whether or not a project should be downgraded to its previous stage. So that's there. Okay. Let me just go through this tentative discussion points or recommendation points. Of course, we want to be refining these a lot more and based on, I'll go through the recording of this call and note all of the points that have been made today. Let me see what else I have here that we should be discussing now. Yeah, if we do, I think maybe just inquire about this once again. If you do use badges, is that certification a good idea? Okay. Arun, you had a question? Right, that was for the previous, I don't know, I don't have a comment on this line as well. I'll just go with this for now. So over here, the way I see that is, so when projects do a self declaration, they are declaring it in their reports and then the report needs to be reviewed and approved by the TOC, right? Or at least let's not call it approved but for now reviewed by the TOC and TOC will bring up further concerns and questions to the project team. And post that, we could go back to the project and tell them their self declaration may not be as intended if at all such case arises. And do we do this? Is this going to be aligned with the quarterly reports? Like we allow such certification to be made only during quarterly report or do we allow it at any point in time? I'm just concerned about the overhead if it is any point in time because could happen like every week, every other week, for example. The biggest concern that I see is in terms of the response and then of course every aspect is important but from a securities standpoint if there has been an issue raised to the project team and the project team has not been responsive to them. Per our recent discussions related to the security ways of working I think we discussed that will give time of up to 90 days for project teams to respond back. And that 90 days hopefully covers the quarters that we spoke about, right? So I'm okay to have it during the quarterly review cycles. And of course other points are also important related to contributors experience and the PR stuff, the time that is taken for a new contributors, PR to be merged the kind of advice the project team gives them but those things can wait for the quarterly reports. We don't necessarily need to ask project teams to keep updating their badges every time. Right, I think, yeah, you're right. They don't have to update their badges every time during quarterly report but I think my question was do they only get to update their badges during quarterly report or can they do it in between? My personal opinion, I'm sorry, see Peter raised the hand. Please go ahead, I can just chime in after. Okay, so my personal view I think we are okay to start off with a process that is to include this in the quarterly report and if we see a need to change it later we could accommodate those changes. That way we are not adding extra processes to the project team plus we are trying to bring in best practices at the same time. That's it. Thanks, it makes sense. Sorry, Peter, just before I hand off to you quick question to Arun. So you mentioned the security review, right? That review process we can adopt for every kind of badge, right? Not just for security. I mean, security itself could be a badge or the fact that a project is secure or we could have potentially multiple security levels as well, security compliance levels but the same process that of a project self-certifying itself as being at a particular security compliance level and therefore it's ready to get that badge and also that the TOC has been observing that the project is not being compliant and therefore it might revoke that badge after the 90-day period. I think the sort of process can potentially be applied to all any of the criteria, right? I agree, just to note related to the security we cannot certify a project as completely secure. However, we can certify a project that they have the best practices are following and they have been following the practice. We can certify on that aspect but not on the security aspect. Thanks, Arun. Peter? I was just going to say that for me personally it wouldn't be a big burden if we allowed people to just queue up a badge evaluation on the TOC agenda at any meeting where we have the bandwidth to actually discuss it but I don't know how much of a burden would this to be to others, for example, or managing the agenda like Tracy in the room but for me personally, if you are sitting here once a week and the project just decided that they should apply for a specific badge and they need our approval, then I would be happy to discuss it regardless of whether it's a regular TOC meeting or one with a quarterly report. Right, I'm just concerned about the level of scrutiny that would require. I think our weekly reviews of the quarterly reports, they are not particularly honest. I mean, but when it comes to badging, we may have to do a deeper inspection of the quarterly reports, right? So I think that would require a bit more work. Yeah, that's fair. So I guess this decision should lie with those who will have to do more work, which is not me. Thanks, Peter. Arun? Right, so Ramay regarding the extra work or deeper analysis into these reports. I know previously, when we were going through which practices to be adopted, we came across this word, TAC, in other groups, right, under the left. And I saw the word TAC that you also mentioned earlier. So can we have a TAC process adopted under Hyperledger as well? And I see multiple benefits of it. And of course, it's not, I mean, we can further discuss what that means and how the TAC gets selected and whatnot. But I see multiple benefits. One, we will bring in additional people who are outside the TOC as well to help assist in anything that is needed. And then probably it creates greater collaboration across projects, if at all we tell the projects that they can be their own TAC as well. So this allows project teams to get involved more with the TOC and pitch and probably come back with the report and whatnot. So just a thought. Sure, makes sense. I mean, I was just highlighting what I noted from the LFN wiki, which is that in the Laying Foundation Networking has both a TAC stand for Technical Advisory Council and a board. And each review is first connected by the TAC, which then makes a recommendation to the board. So yeah, the TAC would have to be a different body. Doesn't have to be mutually exclusive on the board, I think, but it probably has somebody who has different responsibilities on the board. Tracy? Yeah, so I'm not sure specifically about LFN, but TAC is typically another name for TOC or as we used to be the TSC, right? Basically the same thing that this group is currently doing, the Hyperledger TOC. So I know like in the open wallet foundation instead of a TOC or TSC, we have a TAC as the Technical Advisory Council basically serves the same role, right? Projects and guiding the technical community and that sort of thing. So we need to make sure that as we look at these names from other organizations, we understand exactly what these bodies do so that we're not like adding something that already exists within the Hyperledger Foundation just because it looks like it's a different name and now it's the same function. Makes sense. Thanks, Tracy. Okay, I think I've, yeah, I think we kind of covered everything I had noted here. I have, I just had some questions about logistics, but before that, anybody else have any other thoughts, any of the points they'd like to raise about this topic that occurs to you? Or you can always make comments on this page, but yeah, if you want to speak, go ahead. Okay, I guess not. Or maybe let me just take a quick look at the chat. What's this? Okay, so logistically, like the other task forces, I think have a regular meeting schedule to discuss these topics. I think it'd be good to have something similar for this task as well until we get to a stage where we can finalize the recommendations and then present it to the TOC. How do I go about scheduling those meetings? I think, Rai, would you do that? Or is it something I can do myself? Yeah, if Rai fell off the call or is not able to unmute, yeah, absolutely. We can help you with that. If you want to reach out to us on Discord or email, that's fine. Okay, thanks. So who, okay, who else? I think when I look at the task force, I think at this point, the only two people are listed here, that's me and Bobby. And Bobby, I will try to join the documentation group meetings as much as possible. That's great, thanks. For our meetings, for the meetings of this task force, who else would like to volunteer to review the material and make recommendations? Tracy? Yeah, I would like to be involved if possible. Okay, who else? Peter, Tracy, Arun. Okay, all right. Peter, Tracy and Arun, thank you so much. So I apologize. You were asking a question. I couldn't get to the meeting. What were you asking of me? Oh, I just wanted to figure out how to schedule like the regular group meetings for this task force, just like we have with other task forces. Okay, reach out to me on Discord. I'll show you how to do it. Sure, and I think once every two weeks, I think should be good for now, all right? Anybody have any thoughts on that? Otherwise, I think that's how, that's the frequency which I'll schedule it for now. Okay, once every two weeks. Thanks, right? I'll reach out to you on Discord. Yeah, nothing else. So I guess we can close today. Thanks, Rama. Thanks, Tracy. Thanks, everybody else. And, okay, sorry, before we break, Arun, what are you saying? Morning, morning. I just think to understand when would those meetings be scheduled. So the mornings are tight. So Monday's and Friday's work best for me. Morning US time rate. All right. Yeah, I think Monday, I think Monday, there are already a few meetings, right? I think there's a documentation meeting on Monday, the onboarding meeting as well. Maybe we should do this on Friday. I'll, okay, since you know, objections, let's go with Friday for now. If anybody has any objections, please let me know. And Rama, I was thinking we should set up a chat in Discord as well for the group. So I'll get a chat created for the channel, create it for the task force so that we can make sure if there's anything in between times that we want to discuss, we can do that. Thank you. All right, thanks, everyone. And yeah, look forward to continuing the discussion. All right, thank you.


Gadaftwnun, maineis Nick Johnson. I am the Team Lead of Ethereum Nameservice. Since we received very generous grant funding from Ethereum about six months ago, ENS has turned from a one-person's spare-time project into a fully funded team of nine people and we have been spending the last six months building out the ENS features and functionality that we think will make ENS integral to the future of Ethereum and Web 3. So today we're going to go over the new look, what we're doing about ecosystem support, how we've been integrating with DNS, our new ENS management tools, and some R&D on the new registrar that will replace the current auction system. So first of all, as you've probably noticed already, we have a new look, a shiny new logo and so forth. This represents the fact that ENS sort of takes the sharp edges off Ethereum, and we've been rolling this out across all of our applications. So one of the main efforts that we've been engaging in in the last six months is integrating with existing DNS services. ENS, when it was launched, had only the .ETH top-level domain, and .ETH is exclusive to Ethereum and to ENS. It works only to resolve services inside ENS and so on, but we consider it to be a part of the global route, the sort of shared namespace that all DNS names exist in, and we're conscious that we want to be a good player, that we want to integrate well with them, we don't want to pollute the namespace, and we also want to integrate with existing systems wherever possible. So although ENS initially launched with .ETH, we're pleased to say that we've already launched two new top-level domains inside ENS, .XYZ and .LUX, and these both correspond to those same top-level domains in the DNS system. So let's have a quick look at how we've achieved this integration. First of all, for .XYZ, what we're doing is we're using DNSSEC. DNSSEC is the internet's system for securing domain name look-ups, and it permits us to actually prove the ownership of DNS names and the content of DNS names. So using that, a user is able to register their domain using the regular internet registrar, whatever your favourite registrar is. They enable DNSSEC, which, depending on your registrar, may just be a one-click operation, and then they add a text record under their name, saying, this is the Ethereum address I want to be responsible for this name. And then finally, they go into our tool and they submit the proof of it that's gathered from DNS that proves that they own that name, and that is the address they want it to be assigned to. And that tool then sends it to a smart contract which verifies all the cryptographic proofs and submits it into DNS. And from then, they can manage that name inside DNS. So if I own myname.xyz, I can go through this process and I can end up owning myname.xyz inside DNS. And if I go to my favourite wallet, I can type myname.xyz to send myself funds and so on and so forth. So this is a permissionless integration. It doesn't require any cooperation or involvement from registrars or registries or ICANN because it relies entirely on public infrastructure, the DNSSEC system. You can claim your own name now for.xyz via dnssec.ans.domains. And some registrars such as EasyDNS are already working to make this easier by doing most of the work on the back end for you. If you're a developer, there are a couple of client libraries there available. These automate the process of gathering proofs off DNS, compiling them together into the data that our smart contract recognises and submitting it to it. This isn't restricted just to use with DNS either. If you have an app that needs insight into DNS, you can use this. You can use it to fetch any data from DNS that is DNSSEC enabled and trustlessly prove its existence inside Ethereum. Unfortunately, of course, the trustless nature of this and the sort of crypto heavy nature of it means that it can be a little less user friendly than it might otherwise be. So the other integration we've been pursuing is with .lux. And what we've been doing here is actually working directly with the .lux registry and registrars. And they've been cooperating to integrate directly with Ethereum. So rather than sort of doing it through the open route via DNSSEC and having to do everything ourselves, this involves the registrars and the registry actually working directly with us in order to support the DNS. What this means is that if you register a .lux domain with a supporting registrar, you can simply go to that registrar's interface. You can go to the control panel and you can paste in the address that you want to be responsible for it inside Ethereum and hit go and that's it. It's just one step. So this, we think, demonstrates the sort of usability that you can get and the sort of improvements in usability by integrating existing systems with Web3. This is, .lux is available now for pre-registration and officially launches on November the 6th. And before I continue, I should actually say the integration with DNSSEC that we've shown with .xyz, we will be rolling out to a number of other top-level domains. Basically, our goal is to support any top-level domain that has the necessary DNSSEC tooling set up for it. And we'll be doing this after we've finished the new manager and we're confident with the infrastructure and the sort of beta period that we're doing now. So another avenue of research and development has been the new .eath registrar. And this is probably what a lot of you have been waiting to hear about for the last year and a half. The initial registrar when we launched it in May 2017 was auction-based, still is. And it uses what's called a vickery auction. The idea is that everyone bids on a name and then you have a reveal period. People reveal their bids and the winner is the person who bid the most. This system works very well for allocating new names initially when you have many people competing to buy the same name. But we've found it's less effective at ongoing registration. What we find is most people, most names only get bought by one person. The chances of two people wanting a name within a few days of each other are quite low. So we end up with quite a lot of auction overhead for a relatively low return. So our goal here is that we want to migrate to a new system. The new system will be instant buy. So instead of being an auction, you just buy the main for a fixed price and it will be rent-based. So similar to existing systems with DNS, you register a name and you pay a yearly fee to rent it. Before we launch this, we will have a one-off auction for shorter names. So presently, all DNS names are at least seven characters. We'll be auctioning names shorter than that on a one-off basis for a year's registration before launch and then we'll launch the new registrar and everything will transition to this yearly rent. The yearly rent will be the same price for every domain and our goal is to set it at a price that discourages sort of mass squatting but makes it cheap and affordable for people to use DNS. So our target price is more or less the same as you see with DNS names in the region of about $10 a year. At present, that will be set by us. We've been researching mechanisms to set the rent price effectively autonomously but we've been unable to come up with one that we're confident isn't gamable by people who with sufficient resources to influence the price in one way or another. Counterbalancing that, you can register and renew anytime you want and for as long as you want. So if you're happy with the rent price of $10 a year and you want your domain to be stable for a long time, you can register for a century and then you can say the blockchain ensures that this name will be owned by this contract for at least 100 years, which we think is pretty close to an ironclad guarantee for things like package management systems. It will also be built for common infrastructure like package management systems in that it will allow people to renew other domains. You can always delete your domain if you don't want it but if a domain is common infrastructure, anyone should be able to sort of re-upload to ensure it continues operating. So anyone who owns a domain in the existing model will have two options in the new registrar. The first option is that they can transfer their existing domain to the new registrar. They have a full year to do that and when they do the domain registration gets extended to a year after the launch of the new registrar.  That costs 0.01 ether and the remainder of your deposit that you paid in the initial auction to register the name gets returned to you. If you don't do that within a year the name becomes available again and people can purchase the name. However, your deposit will always be returnable. The other option is that at any time after the launch of the new registrar you can release the name and get back the entire deposit you paid in the original auction. So one of the biggest things in building ENS into a universal platform is making sure that ecosystem support is really good. ENS is not much used to us if it's just a way to register names and then a way to look at names and none of the apps support it. So one of our biggest drives in the last six months has been pushing out more support for the ecosystem for libraries and tooling with ENS. And we're pleased to say that ethers.js, web3js, web3pi and web3j all now have integrated ENS support meaning that if you use any of these client libraries in your DAP you no longer need to have a separate ENS library to do name resolution. So if you are using one of these libraries it's possible your app supports ENS without you even knowing it. And in the case of web3js, sorry ethers.js for instance it actually does automatic name resolution anytime there is an address field. In the case of some of these other libraries you still need to use a separate ENS module but it's integrated with the library for you. We've also of course been pushing it out to more wallets and apps and we're very grateful for the cooperation of people such as Argent, Portal Network, Gitcoin especially have been doing a lot of integration with us and Malinport. And this is going to be one of our main efforts going forward is more developer relations, more reaching out to folks like you to make sure that integrating ENS is the obvious choice. Finally, outreach such as events like this. We held a second ENS workshop in August at which we gather a lot of feedback and ideas that have helped us improve the permanent registrar and other efforts. We had onboarding workshops here at DevCon. There's one today at 5pm if you just want to sign up for a name. And Thursday at 10am there is a workshop for anyone building a DAP or a wallet who wants to know how to integrate ENS better and would love to see you there. And we've done talks at a wide variety of events with ENS staff members. And if any of you have an event that you'd like to see us at please come talk to us afterwards. We'd love to be there. So next up, we have been redesigning the interface for managing ENS names and registrations. And to demo that, I'd like to invite Jeff Lau, the lead of the ENS project manager project up. I'm Jeff Lau and I'm the lead developer of the ENS DAP. I've been working with ENS since June of 2017 building the original manager DAP which following the launch of ENS last year. This was built as a proof of concept for this new DAP that I'm going to show you right now and it was concentrated on functionality. But with the new funding we got from the Ethereum Foundation earlier this year, we've managed to hire a UX designer and a UI designer to help us revamp the interface. So we're focusing on it to be more user-friendly and this is what the revamp I'm going to show you today is based on. So today I'm going to show you a demo of the new app. I'm going to show you how to set up your ENS name if you have one from start to finish and I'm also going to show you how to add sub-domains. So this is the new app right now. So you're greeted by a large search bar similar that you'd see on GoDaddy or any of your other registrars. And here you can be nosy and search any ENS name in the registry. So however the most useful thing you can do is search for names that you own and you can set them up for your own use. So I'm going to do that right now and I'm going to search for truenames.eath which is the ENS name for the company that develops ENS. So as you can see here I'm going to show you there are two stages for setting up your ENS name. So first we need to set up an ENS resolver for our name and secondly we need to set up the address record for that resolver. So what is a resolver and how do we set it up? A resolver is a smart contract that allows you to map your ENS name to a record. The most important record that you can set up is the address so you can resolve from truenames.eath to your unreadable Ethereum address. So how do we set up a resolver? Well the easiest way is to use the public resolver. The ENS has deployed a public resolver contract which is available for everyone to use and it will handle most of the record types that 99.9% of users will need. If you have some advanced usage you can also deploy your own resolver and point to that instead but we're just going to use the public resolver. So if I click on the pencil tool it will come up with a nice input box to type any resolver you like but we're just going to click on use public resolver which will prepopulate this with the public resolver. I'm going to click save and run Metamask and we've cheated a little bit here. We're on a private network so this is going to confirm immediately and it's going to, yeah, I really wish Ethereum was that fast but just for the demo today we're going to use a private network. So that's the resolver set up. That means we are able to add our own record types.  Taking the plus we can see a drop-down menu that will allow us to choose a record. Currently we only have address and content but in the future we'd like to add the rest of the record types that the public resolver supports. So we're just going to click address here and we're just going to copy the owner address which is our own address. So we want to point true names or ETH to our own ETH address. So I'm going to click save again and confirm and that's going to confirm instantly again and now we've set up our name. So that's actually it. That's how you would set up your ENS name once you've bought it. You set up the resolver, you set up the address and now any ENS-enabled DAP will be able to resolve true names or ETH to 0x90f, et cetera. So that's the basics. Now I'm going to show you how to set up subdomains. So subdomains are an advanced feature that allow you to set up more ENS names under your root name. So if I click on the subdomains tab on this side it's going to show us what subdomains we have available. We don't have any subdomains in this right now so I'm going to set one up. So if I click on the button here you can add any kind of label for your subdomain. So we're just going to create a tip jar for true names or ETHs. So any of you kind folks who want to donate so our foundation can do so. So I'm going to save that, metamask again, superfast ethereum we're in, subdomain created and I'm going to click on this now to go into our tip jar.truenames.eth. So as you can see here the tip jar subdomain is just like any other ENS name. It has all the functionality of truenames.eth and has the owner, it has the resolver and it also has all the record fields available to it. So I could do the same thing as we did before. I could set up the public resolver, save that, confirm it, et cetera. And that's all set up nice and quickly. The other thing we can do is change the owner. So your subdomains don't have to be the same owner as the root domain. So we can actually transfer this to say a family member or maybe for us maybe like a multi-sig wallet for the truenames.eth foundation. So I'm going to show you that now I'm just going to copy a address I saved earlier. Might be my own address and paste that in there. Click transfer, confirm that transaction as you can see and that changes the owner address to the one I just pasted. So that's pretty much it for the basics of the ENS manager. We also have added in some new functionality for favoriting. So if I click on this heart button that will fill it up and I can go to the favorites panel and that shows you we've got favoriting abilities to save to local storage your domain. So this makes it easier for you if you've owned quite a few domains to manage them all separately and I can get rid of that heart and it will get rid of my favorite. So that's all the functionality for the new ENS app. There's a lot of things that we want to add to this. Let me go back to the presentation. So present. So in the future we want to add things like reverse record support which will bring up to feature parity with the old manager. We want to be able to, like Nick said, claim DNS names via DNS sec have that integrated into the DAP. Auctions for short names, three to six characters, permanent registrar support, so the instant buy, ENS now which is already hosted at now.es.domains but we want to integrate it with the original app and also advanced features like name and resolver history. And I'm just going to hand it back to Nick to finish off the rest of the presentation. So finally to wrap up, what's next for ENS? Obviously we need our top priority. We want to finish permanent registrar design and implementation. Our goal is still to get this rolled out in May next year so that everyone can transition to a more permanent model for registration and so that we can ease the registration process for new users. We want to, of course, deploy this and migrate everyone over. We're completing work on the new management interface that Jeff just showed us and of course there's the ongoing outreach. Our biggest ongoing task is always going to be making sure that ENS is as widely deployed as possible, it's as useful as possible and convincing as many of you fine folks as possible to integrate it into your apps. So that's it for today. Thank you very much.


Let us look now at the strategy organizing data. Sometimes simply by neatly and cleverly organizing the data, you gain valuable insight to lead you in the right direction to solve a problem. Consider the sequence 1, 2, 2, 3, 3, 3, 4, 4, 4, and so on, how many terms are needed in order for the sum of the reciprocals of this sequence to equal 100. Let us begin by writing out the sum that we want. We are organizing the data in the way that the problem suggests. Now we see that the sum of these 2 terms is 1, the sum of these 3 terms is 1, the sum of these 3 is 1, so the last term in this sequence, since we are adding many ones, the last term must be 1 over 100, 100 times, this is the last set of terms. Now notice that this is as 1 term, 2 terms, 3 terms, 4 terms, we are concerned with the number of terms needed for the sum of the reciprocals to be equal to 100. And then this one is 100. This problem then boils down to simply adding the integers 1 through 100, which we can easily do, 51 plus 98 plus 99 plus 100. We notice that 1 plus 100 is equal to 101 and 2 and 99, the sum of them is also 101, the sum of 98 and 3 is also 101, and the sum of 50 and 51 is also 101. So we have 50 such pairs, so the answer must be 50 times 101, which is 5050, that is the number of terms needed for this sequence to be equal to 100. Certainly we could have used the formula for adding integers 1 through n, which was known to the Pythagorean more than 500 years before the Christian era. If we would have used the formula, we would have put 100 times 101 divided by 2, which is equal to 50 times 101, which is exactly our answer. Thank you.


Good morning, thanks to Dr. Erdos for inviting me and for organising this conference and it's a real pleasure to be back at Cambridge for the day. I've been asked this morning to talk about the jurisprudence of the Court of Justice in the lead-up to or as a background to the Google Spain case. There's been remarkably little case law in front of the Court of Justice dealing with data protection issues despite the fact that we've had the data protection director for almost two decades. But rather than kind of going case by case through the jurisprudence, which might be a little dry for the morning slot, what I've instead tried to do is to demonstrate that the case law prior to Google Spain is entirely consistent with the Court's findings in the Google Spain judgment. And I say this for three reasons. So I guess the subtext here is the reasons why we should have seen Google Spain coming and I think that's for three reasons. So first of all, the Court has continuously insisted upon the broad scope of application of the data protection rules. And that's something that is reflected in the Google Spain judgment and you see that through for instance, the broad scope of territorial application, which the Court gives to the data protection directive in that case, where it says that Google search engine processing is in the context of the advertising activities of its Spanish subsidiary. So broad scope of territorial application there, something which the Advocate General was in agreement with. But then also you see that this broad scope of application is reflected in other ways, which I'll go on to talk about. The second point, which I think is quite evident is that despite a slow start, the Court is now placing increasing emphasis on the EU Charter and in particular on the EU Charter's rights to data protection and to privacy. So unlike other international instruments, the EU Charter includes both a right to privacy in Article 7 and a right to data protection in Article 8. And the Court has been quite forthcoming now in emphasizing the effectiveness of those rights. And then the third point I think we could adduce in order to support the Google Spain finding for good or for bad is that the Court at present seems to be quite emboldened. It has taken several judgments, which illustrate that it is not, in my opinion, entirely concerned about the political fallout that will follow from its decisions. So I'll elaborate on these three points now. So first of all, if we take the broad scope of application of the data protection rules, here, I think you can see that the directive has a broad personal scope in terms of how we define who is a data subject. And also, as we saw in Google Spain, who is a data controller? So in that case, the Advocate General had argued that in order to be viewed as a data controller, so an entity, a company which would be responsible or have obligations pursuant to the data protection rules, there should be a knowledge that the company concerned is processing. I say company could also be a local authority, the entity concerned. There should be a knowledge that there is processing of personal data. Now, a literal interpretation of the directive doesn't include that knowledge criterion, and actually the Court rejected the idea that a data controller has to have knowledge that they are processing personal data in order to have obligations pursuant to the directive. Now, Google here might have been quite a particular case, but I think if you look to the kind of broader issue of the application of data protection rules, that's actually quite a sensible finding, because in the absence of that finding, companies could plead ignorance, so ignorance of the fact that they are processing personal data in order to escape obligations pursuant to the data protection rules. But you see there that the Court is defensive of the broad personal application of the data protection rules. You also have broad material scope of the rules. So here, data processing is pretty much anything that you could do with personal data, and personal data is any information relating to an identified or identifiable person. Now, Jeff has just spoken about identifiability and the issue of public and private in the context of things like anonymization. But I think it's important to highlight here that that definition of personal data goes beyond the type of data that might be covered by the article 80 CIGR, Right to Privacy. It's a very broad definition. So we have this very broad scope of application of the data protection rules. And as I've just said, unlike the Right to Privacy in certain contexts, this will always apply to material in the public domain. This is irrespective of whether or not the information is publicly available or not. And this broad scope of application has been defended by the court in its case law. So it's very protective of the directive scope of application. So I've just indicated a couple of cases here, but in a case like Schwartz, what was concerned was the fingerprinting data of a German national. He was obliged to provide this fingerprint data in order to obtain a passport from his local authority in, well, through the German government at home. And he objected to this on the grounds that it was unnecessary data processing. And the court recognized without hesitation that this type of data, which would also benefit from the Right to Privacy, constitutes personal data from or in the context of the directive. A more complicated case, you might say, is Bavarian Lager. And there you had a query about access to minutes of a meeting between industry representative and European Commission officials. And the commission was refusing to grant access to the minutes of this meeting on the grounds that the names of the industry representatives constituted personal data. And here before the court, so between the Court of First Instance at the time and the Advocate General and the Court of Justice, there was a dispute about whether or not those industry representative names could benefit from the Right to Privacy, because although there's a Right to Privacy in the workplace, here it doesn't seem to sit very well with the reasonable expectation of privacy, given that the access was sought under transparency regulations at EU level and equally with the kind of rationale for privacy in the workplace, which is to allow individuals to develop relations. And clearly the whole aim of transparency legislation is to prevent cozy relationships between Commission officials and industry representatives. So this might not have been covered by the Right to Privacy, but it clearly fell within the scope of the Right to Data Protection and of Data Protection legislation. So you can see again a broad scope. And then I think the most recent notable case on this is a case from last December, where the court was asked to consider whether or not the exception to the scope of the Data Protection rules, which is an exception for personal data, which are processed for purely personal or household purposes, could be applied to the case of Mr. Mr. Renus. And Mr. Renus was an individual who had installed a form of close circuit TV outside of his front door, because his family home had been subject to numerous attacks in the past. And so this camera was installed for personal security purposes. And it captured the pathway up to his front door, but it also captured part of the public path outside of his front door. And this camera happened to capture some footage relating to an attack on his house. And the footage was brought forward to be used in the proceedings against the perpetrators. And the question was raised as to whether or not that footage could be used, because Mr. Renus hadn't kind of received prior authorization for the processing and hadn't complied with his obligations as a data controller. So was the capture of this footage compatible with data protection law? And he argued that the processing in this instance was for purely personal or household reasons. He wasn't the footage wasn't automatically recorded over itself. It wasn't retained. He didn't have a way to live to examine the footage remotely on a phone or anything else. And yet the court found that in this instance, the footage was not purely personal because it captured a public pavement. So you see there that that's a remarkably broad interpretation of the purely, sorry, remarkably narrow even interpretation of the purely household and personal processing exception in order to preserve the broad scope of application of the rules. But in that case, the court was kind of at pains to emphasize that just because you fall within the scope of the data protection rules doesn't mean that the processing is unlawful, rather at that point, once you're within the fold of the rules, and there's a system of checks and balances, which determines whether or not the processing can be lawful in any particular circumstance. So you have a very strong indication from the court there that Mr. Renus would have been able to justify this processing and that it would have been adequate. So we have the broad scope of application, which is reflected in Google Spain. We also have an increased emphasis on the effectiveness of the EU Charter Rights. So I would argue that in the in the early years, prior to the Charter and acquiring binding force or becoming a judicial, just this instrument in 2009, there was an initial reluctance on the court to point to the Charter Right to Privacy in order to in order to justify its actions in any given case. I think this is particularly the kind of narrow interpretation of privacy of the directive is particularly visible in a case like SATA Media. So in that case, you had an issue about whether or not data on high earners, so those who are earning over 100,000 euro a year could be disseminated via text message by a private private company. And there, the private company had pleaded that this this dissemination could benefit from the directive's exemption for processing for journalistic purposes. So the argument was the text message dissemination is journalistic and therefore can fall outside the scope of the data protection rules. And there the court gave the court interpreted that exception, the journalistic purposes exception really broadly. So it said that it applies to the disclosure of information, ideas or opinions to the public. Fast forward to last year and you can see that clearly the definition of journalistic purposes has changed significantly when it comes to the Google Spain case. So we have seen, I believe, a change in a change in tack when it comes to what could benefit from this exemption for journalistic purposes. Finally, I think in addition to that change in tack, there's perhaps in the court's case law an indifference to the disconnect between law, it's maybe a bit harsh to call it reality, but certainly technological developments. And that, you know, is one of the big criticisms of the Google Spain case. That's also a criticism of the Lindquist case, where the court seemed to have kind of mixed feelings about how the directive should apply to the internet. So on the one hand, it held that the act of a pensioner who was uploading data about to a charitable website for personal purposes as part of her data processing course could be criminally prosecuted for that action, because it was personal data processing because she uploaded information on her colleagues to the internet. But on the other hand, it can stop short of saying that she should have been responsible for international data transfers. So you can see that the court has clearly kind of struggled to apply this old directive to new circumstances. And then finally, I think you see at the moment a stronger court, particularly when it comes to fundamental rights. So this is perhaps because of, as I said, the introduction of the Charter, the Charter's acquisition of Binding Force in 2009. But that was very visible in last year's judgment in Digital Rights Ireland. The court for the first time struck down an entire piece of legislation on the basis that it was not compatible with the EU Charter rights. And in so doing, it ignored the Advocate General's request that that judgment have a temporal limitation, which would allow Member States to put in place safeguards for, well, safeguards, maybe the wrong word, arrangements for data retention while a new directive would be enacted. So it ignored that. But equally, I think if you look at something like Opinion 2 of 2013, which was where the court was asked to assess the legality of the European Union's accession agreement to the ECHR with EU law, and it argued or it found that that accession agreement to the ECHR was incompatible with EU law. And an incredibly complicated judgment, which I think could be kind of narrowly read, but it effectively it said that by signing up to the ECHR as the agreement stands, it would be circumventing things like the preliminary reference procedure before the court. So again, clearly a case where it wasn't too concerned about the political implications of its findings. And then finally, this week before the court of justice, we had the hearing in the Shrems case, which was a preliminary reference from the Irish High Court, where the compatibility of the safe harbour principles, so allowing data transfers between the EU and the US, was challenged on the basis that those principles, which were adopted in the year 2000, no longer reflected a situation where adequate protection was being offered to EU citizens when their data are transferred to the US as a result of the Snowden revelations. And there, I believe, from anything I've read or heard about the proceedings, they were quite lively and that the commission was more or less left on the back, I think I can say this, left on the back foot in arguing that in order to effectively protect fundamental rights individuals should possibly not sign up to Facebook. And so it remains to be seen what will happen with that judgment. The opinion of the Advocate General is due on the 24th of June, but I would say based on what we've seen so far, the ingredients would indicate that Shrems has a good chance of succeeding in that case. I'll leave it there, but I hope to discuss further during questions.