Rydyn ni'n meddwl'n chi'n gweld, mae'n 12. Rydyn ni'n meddwl y Workflow Initiative Core Conversation. Felly yn fawr o'n mynd i'n meddwl eich conversaion yw'r bydd. Felly, i wnaeth ymdweithio, rydyn ni'n Myllwyr Tim Millwood. Rydyn ni'n meddwl i'r newid, a rydyn ni'n meddwl drwpl i'r mynd i'r gwirionedd. A rydyn ni'n meddwl i'r Workflow Initiative. Rydyn ni'n meddwl i'r meddwl i'r wath, roedden i wneud. We had a UX sprint in Amsterdam in June and there we looked at a lot of the different concepts that we're bringing from contrived modules into core and the UX issues with them and things that we should look at. The main areas that we looked at were the content moderation, the undo or the trash functionality and workspaces and how workspaces are going to work and what they do and what they are.  So at the top there we've got a live workspace. This is the one that all your users see when they visit your site and you can branch off that. You can create an upcoming event and behind that is the live workspace. You can create a new product and behind that is the live workspace. So you are branching off this live workspace adding new content to that sort of branch of the workspace. And then down the bottom here we've got a last minute fix. So you can branch off a branch and create fixes and push those up as well. So the two lines here represent a push and a pull. So the push will push all of your changes. So it will just push the white part, just the changes. And then the pull will pull any upstream changes down. So on the last minute fix we'll get all the changes from an upcoming event. On an upcoming event we'll get all the changes down from live. So we've got this full push and pull process on workspaces. So we also looked at a scenario on how workspaces actually work in a real life. So here we've got quite a detailed process. We set up the workspace at the start so the bottom, the yellow one is the live workspace and we create a branch of that above the white one. And then we can create content. So the black and white boxes within the white workspace represent creations, changes and deletions of content within your workspace. So these can be done many times throughout the process and you can do another update then from live which is done at the third step here. And then if this is okay we carry on. If not we look back and we keep doing changes and keep updating the workspace. And workspaces can go through the full sort of moderation process so you can mark them as needs review, you can mark them as published, and you can add moderation states to them and take them through this process. And then when we're finally all okay and we pass that okay mark we do a final pull because we want to make sure that everything we've got is the same as live. Before we do our push and make sure that everything on our workspaces is up on live. So when we do this pull and then push right at the end we would also look for conflicts and make sure there are no conflicts in the content. And we'll eventually need a way for resolving these conflicts. So also as part of the UX sprint we looked at different roles, different personas, different users. So we came up with this diagram here to try and explain the different roles that we have in play here. So we've got the create role there at the top, these are the type of people who would create the actual content on your workspace. And then we've got the review and approve so these are the type of people who approve the workspace, approve the content on the workspace and move it to the next moderation state. And then we have a final role of the publisher, the person who actually pushes it live. We're hoping for different permissions and different roles so you can differentiate between these different steps and only allow certain people within an organisation to do these. And then branching over all of this, at the bottom we have the configure role.  And they would configure all the different moderation states and the whole flow. And then we've also got this managed role, these are the managing editors and these have access to all the different steps and they can override anything and have access to the whole thing. So what we're thinking would be our roles and the different permissions that we'd need. So that was pretty much all that we looked at in this UX print and all the kind of concepts we came at around workspaces and the flows. From a code point of view in phase A we looked at a number of different issues. This was the phase where we were trying to get more revisions everywhere and there was a number of issues that were underlying to getting revisions everywhere. So these are some of the ones that we addressed. Revisions are now enabled by default and content entities inherit the base fields. So things like the revision ideas inherited from the content entity base. We've now got revision log interface being used on node and block content. A revision overview has got a pager now. Contextual links are now different for revisions compared with the default revision, the live version of the entity and non-revisionable translatable fields. It's quite a complex one where if you had a field that was translatable but not revisionable on a revisionable entity it caused a whole heap of issues. So that was another one that we looked at. So phase C is probably our only phase that is done. It's content moderation. It's in now as an experimental module. There's still a whole ton of stuff we need to do to make content moderation a stable module. But sort of as a phase I'd like to think it's pretty much done and we put workbench moderation into core, renaming it as content moderation. We made it uninstallable because with bench moderation you can't uninstall and experimental modules need to be uninstallable. And then we fixed a few bugs and cleaned up a few bits and it's all looking nice. So phase D enable archive and purge storage. So I spent weeks and maybe months looking at how we can archive entities, how we can mark things as deleted but not actually delete them. And in contrib we add an archive field to all entity types and that will allow us to mark things as archived. But in core that didn't really seem like the best approach. So we looked at changing the status field and making that a field that we can mark as deleted or mark as archived but that blew up a whole load of other things. Things like views that assumes a status field is boolean and we'd have to update every view ever on any onsite. That didn't sound very fun. We also looked at SQL views. So putting all this in the database and having a different SQL view for every different sort of status but nowhere in core has SQL views at the moment so adding that didn't really seem that fun either. So this whole phase has been postponed really because we didn't find a good solution. So what we've ended up doing is for the trash module which depended on that archive flag we're actually using content moderation. Content moderation already has an archive flag so we thought why don't we just use that. So trash will depend on content moderation and use the archived moderation state. So in contrib we've created a 2.x branch of the contrib module. The contrib module originally depended on multiversion which is the module that had the archive flag in before. So the 2.x branch depends on content moderation. It uses the archive moderation state. So we've been working quite a lot with our UX team as well to try and work out some of the issues with trash. Trash was originally written for this session in Barcelona so the 1.x branch was written in like 2 weeks. So there's a lot of issues with it. It didn't have any tests and it didn't work 100% of the time but now it's getting better. Things like the delete tab on the top of your entities now says move to trash and you click it and it moves things straight to the trash. There's no confirmation page so everything just goes to your trash and then you can go there and restore it. One thing I'm currently working on is when you tick all the different nodes on your admin content page and you do a bulk action to move things to delete it and now move the ones that can be moved to the trash to the trash and the ones that can't be moved to the trash it gives you the confirmation page because it's based on content moderation and content moderation is per bundle, so per content type. We have to do different things for different bundles. So there's a lot of checks in trash to see if a bundle is moderated. So yeah, that's pretty much the state on trash and I'm hoping that pretty soon we can get that in as an experimental module in A3. I'm hoping it will be there. So these are some of the UIs that we've been looking at for trash. So this would be the trash. So you see we've got a number of different entity types. So they're all mixed together. It's just your overall list of trash. What we were thinking was on your desktop machine if you put an image in the trash and if you put a text file in the trash and a word document in the trash, they're all led together. You don't have a separate trash for every type of file. So we're putting all entity types in together and from there you'll be able to restore or actually delete entities. So restoring them will take them back to the moderation state that they had before. One thing we're still trying to work out is what is before. So we've got to kind of work out from the revisions what would be the revision before, the revision that you put it in the trash and what if you were doing forward revisions. So if you had a published revision and then you created a draft revision and then you send a published revision to the trash, what happens to the draft revision? And when you send something to the trash it creates a new revision, it creates a trash revision. So that then bunny hops your draft revision, your forward revision. So when it goes back, does it go back to your draft revision or does it go back to your published revision and how do we know which one is which? So we've got a whole load of complex issues. So if anyone's got any ideas, I'm happy to take those. We're also adding an undo link to the trash. So when you add something to the trash, you'll be able to undo it. And that doesn't have a confirmation for me there. You just click undo and it undoes. Again, we've got the same issue. What do we go back to? What revision does it go back to? Because we don't know. Once you move something to the trash, we've added a new revision. We've added the trash date.  So the published note is the published one that was there. The draft is the draft. If there was a forward draft. Right. So the question was, why don't we just go back as we were? It's not simple to do technically, but logically it seems the most sensible thing you'd do. That's actually what we decided. So we are looking to go back. I'm wondering whether it is so easy to know how it was before. Because after you create a new revision, it's not 100% clear what the revision before was and what the state was before. But we can probably try and work it out. We do need to give that some thought. Has any schools been given to how that would interact with workflows? So like if you pull in changes and then someone actually to eat something from the live site and sort of the restore process behind that and getting it back across any necessary workflows. So the question was how would it work with workflows. It's something we need to think about. Because we don't really store much information at the moment about workflows and the process or the states that things have been through. And we are storing in content moderation all the different states that an entity has. And they all have an order because they have a sequential revision ID. But if someone's creating a draft when you've got something published and that's got a forward revision, a higher revision ID, but then when you delete the published revision then that's got a higher revision than the draft one. So as I was saying earlier you don't really know what you're going back to. It feels like it should have the awareness of who's my parent. Right. So yeah, the question was the revision needs to know who's its parent. And that's something I will get to in a bit because in the contrary modules we have got revision parents. So yeah, we can definitely look at using that. So on to what's next. And the UX stuff, still a lot of work there to do mainly around workspaces. So we need to get the name incorrect when we say workspaces. No one knows what we're on about. So is workspace the best name? Should it be site version, site revision, something else? Definitely open for suggestions there. We need to come up with some prototypes around the whole workflow to use it or interface and do some user testing around that just to make sure that it all kind of makes sense and works. One thing that we've got already in Contrib is moderation states on workspaces. So you can move a workspace between draft, needs review and published and trashed. And so when you publish a workspace it automatically moves all the content from that workspace to its parent workspace. So much like in a Git workflow every branch has got an upstream branch. So we'd have that similar sort of thing with workspaces where everything would have an upstream and it would just automatically merge up to its upstream. But does that make sense? It makes sense to me, but does it make sense to the people who are actually using it? So then in phase A, I said earlier we've done a load of stuff in phase A but we've still got a really big issue outstanding and that's to make things revisionable. And it's very easy to make things revisionable but the upgrade path is incredibly hard and moving all of your content from a non-revisionable entity schema to a revisionable entity schema is pretty complex. So we've got a lot of work done already on there but we just need to try and get it past the line and get it done. So in phase B we're looking to extend a revision API with revision hashes, revision parents and an upgrade path that generates all of these. So the revision hash is a hash of the revision so if user A creates a change to an entity and user B creates exactly the same change they will generate the same revision hash so we can just look at the hash and we know that they're both pretty much the same revision. And then revision parents will allow us to see this full sort of path of where our visions come from and this will definitely help the trash issues but it also allows us to resolve replication issues when we're replicating content between workspaces and between sites we know exactly where the revisions have come from. And then the upgrade path, as I said we need to generate all these so we're going to have to go through every entity on your site and generate a hash and work out the parents so we've still got the problem of what is the parent revision. I guess we could just assume that it's the sequential revision ID but again we're up to suggestions. So phase F is when we hope to add in a lot of workspace stuff and it's debatable on whether this depends on the revision hash and revision parents. So we can definitely add workspaces into core very soon and they don't need the revision hashes or the revision parents but they will need them when we start doing replication between workspaces. Is there any point adding workspaces before we can replicate content between the workspaces? Do we add workspaces to core now and leave the replication in contrib? That allows you to get workspaces as a basis into core and get something that probably will already be useful for a number of people and for a number of people to start using it without having all the complexity of solving the hash and a replication issue because if you only have two workspaces the replication logic becomes a lot more manageable. I guess the comment was about having limited workspaces so basically only two workspaces is a stage and a live and it makes it a lot simpler but I don't want to get into the situation where we add stuff into core that we then have a problem when we try and add more stuff in that we've actually got to take out what we first started with and we've already got all this working in contrib but I did write a blog post a few weeks ago where I said that it's really not that easy to just move it into core so I'm not saying because we've got it in contrib but we've got all this stuff working we just need to try and sort of port it over and a lot of the logic that we've got for replicating between workspaces we've taken from CouchDB and how that does the replication so it's a pretty solid process so I think that's I'm not going to say an easy bit but it's relatively straightforward sort of we know what we're doing because there's tried and tested ways to do this replication but it's definitely caught a bit of work to get it done but currently in contrib we add workspaces in the multi-version module which is like the base module and you can't actually do anything with those workspaces until you add the subsequent contrib modules so that's what we could look at doing in core initially is the experimental workspace module does a little more than just adding the workspaces and then we just have the contrib modules to do the replication until we get to subsequent core releases or we could go down the Drupal 7 root and you have your stage workspace and you can just copy and paste everything over to your live workspace and that will do your replication so yeah, still a lot to think about on workspaces we've also been looking at what CPS did as a module in Drupal 7 it's a very similar concept to workspaces and development seemed to start on both CPS and workspaces at about the same sort of time and they went in slightly different directions but the end product is very similar so we need to try and look at the best ideas from both and try and work out what we can do to get the best end product so on the bottom there I've also got sequence entity indexes so this is one thing that we use quite a lot in the contrib modules this we've got an index for UUID for revision hash and then also a sequence index so this allows us to do fast lookups by UUID of an entity by hash of revision and the sequence is we store a log of every entity change on the whole site so much like a Git log we can look at the sequence log and know exactly what's happened between the sequence item A and sequence item B so that's going to be pretty important when we start looking at replication so also in this phase we've got a couple of services these are the services that we use in contrib at the moment to do our application so the changes service will allow us to get the changes from a workspace and then the revisions diff service will allow us to diff those changes between a workspace so we're only replicating the entities that have changed the revisions that have changed so the replication that happens is often very small because we're only taking the changes so these are some of the services that we need to get in place to get the replication working and we've got the whole sort of replication API at the moment we're using tag services in contrib that seems to work pretty well in that more modules can define a different way to do replication and it will just loop through each way to do replication until it finds someone that applies so in contrib we've got a single site replication where it replicates from one workspace to another on a single site and then we've got site to site replication and it goes over HTTP to a completely different site and these are just two different tag services and it just looks to see which one it's going to use and then there's also the conflict API and this is something that we had a Google Summer of Codes student work on over the summer and they've come up with a great way to do three-way merges between entities so we can get two revisions of an entity and do a three-way merge between those and hopefully we can get this into sort of auto resolve any conflicts that there are So the question was is there a module for that and there is the conflict module which is where the work is going on it doesn't really do a lot at the moment all the underlying code is in separate PHP services so we've made it very decoupled from Drupal itself and then we're going to pull that into the Drupal module so it'll be able to resolve conflicts with entities but at the moment it's resolving conflicts with just random data with like arrays so we would take an entity and put it down to an array and then resolve the conflict at that level and that's what the PHP service is doing So then phase G is kind of the the final phase really but polishing all of the UIs and making sure there's a really nice way to replicate your content between workspaces to create workspaces to manage all of the moderation states on them full sort of conflict UIs so maybe you want to just pick which revision do you want from the conflicting revisions or maybe you do want to carry out a full merge yourself and get the traditional four pains and do all the merging yourself so we're thinking of trying to build a very flexible conflict UI with different plugins maybe so there's different ways to do conflicts so that's pretty much it on what we've done and what we've still got coming up so if anyone wants to up to the mic I'm happy to sort of take questions but more sort of open up discussions on what you think and what you want to work on what views do you have yeah it's an open floor really so the my name is Jess I'm XJM on www.dripple.org the trash module UI that you had up there I'm assuming that was not of you because it had multiple entity types in it is that correct? so it definitely wasn't of you it definitely wasn't of you but we are hoping to do reviews because it's a list of content moderation states it's not a list of entities oh okay so the base table is the content moderation states exactly okay thanks I'm Daniel Villan I also have some views so I was wondering about the work spaces bit you were talking about exponential modules if for that kind of stuff and I was wondering about that that's really the right approach work spaces or the life stuff would have to be taken on account everywhere so I was wondering like well that's the right approach there just yeah it's an open discussion still but I think experimental modules are definitely the way interpolate to add new features to core but we do get into a whole load of issues then that it's got to be something that's turned on and offable and we've already seen in putting workbench moderation in that we had to rewrite a whole chunk of it to make it uninstallable so it's still to see whether that's the right approach or not but it seems possible that we can do it as an experimental module and and store all the information in some sort of meta table or entity type I'm a little bit worried because like work spaces are like a new dimension of problems so if you want to test a new dimension of problems you would have to add this dimension to any test theoretically to really test it but if you had an experiment you would you need to know you don't know what you want to test for right so I was well one option the same is with translations right we have translations baked into the core because it's a fundamental part of what we have to think about no that's just that's just a UI well yeah so we could look at just that and putting the API into core itself and then the UI is an experimental module that's definitely an option but then we've got to look at if someone only has one workspace if they use Drupal 8 as it currently is we've still got to send them through the whole API of workspaces and the whole lookup of does this content belong in this workspace or does it not so we're going to have to manage the whole performance around that and I know CPS in Drupal 7 did it in pretty clever ways so we'll probably call on them to help but it's definitely something that we need to think about I'm Tobias I'm CPS this is not really a question just something kind of to throw at you to see if you have thoughts on that because we have the changed field on a bunch of entities so basically whenever you whenever you press save on an entity it updates the timestamp and I'm wondering how that fits into the whole entity hash thing because whenever you save it you have a different changed timestamp so there's definitely going to be like a change and does that really count or not or like so so in the contrib modules where we're generating the hash now we exclude a number of fields like revision ID and changed that are different between revisions and we generate the hash not including those and because the way we generate the hash is consistent it will always be the same if you generate it on site one or site two so yeah that's pretty much how we do it but we will have to take into account if some random contrib module is adding another field in that does similar stuff how do we manage it do we generate the hash of just known fields I don't know again it's something that we need to look at so the comment is it should be hookable or pluggable and yeah it probably should be especially when it comes to translations the change field is translatable so we have a change timestamp across translations or in general like how do the the hashes work when it comes to translations not sure to be honest but yeah again we're going to have to definitely take that into account thanks Tim Doug Green I also did some work on the CPS and just a bunch of random thoughts you mentioned archiving were you talking about archiving of versions or archiving of entities or both because we ran into lots of problems with CPS that keeping track of all of our revisions the tables got huge and we ended up archiving in files instead of right so we're looking at archiving and entity as a whole but the archive is denoted by the latest or the default revision being archived with the moderation state we're probably going to allow a setting to choose what is your sort of trash state or your archived state so each bundle potentially could have a different trash state but if the default revision has that state then it will be archived so essentially it's the same as any other revision in the entity API it's just got a different moderation state and a moderation state in content moderation is just a config entity so it's no different to needs review or any other moderation state really it's just sort of a special state so yes we probably will get into the problem of having big tables with lots of revisions but it's potential when you start looking at the workspaces that you had basically every copy of every revision and every workspace and it just balloons it's definitely something we need to the other thing that I saw that a few others in your workflow states we found that language translation was a workflow state that needed to be in there so it wasn't just content editors reviewers, approvers in addition to that okay it's interesting you mentioned trash and I was wondering isn't trash done in a workspace or are you trashing the live version potentially you could trash a live version and we are looking at replicating trashed states so if you trash something in stage and you replicate stage to live it will become trashed in live as well but potentially if you had the right permissions you could go on to live and trash it trash an entity that is so I think we need to leave it flexible enough from a permissions point of view that if someone does have the use case that they want to trash something in live that they can the last thought I had this has made a different design decisions and we did the replication wasn't really necessary we weren't replicating from one site to another site the revision control was all controlled within a single site are you complicating this model right now thinking about replication I'm throwing that out there yeah coming from the contrib background of all this the main goal was for site to site replication and for that we looked at the catchdb way of working because the replication there is very solid there's a very good protocol very good API so we copied the same principles when we looked at single site replication so maybe we are over complicating it but I think it currently in contrib anyway works pretty well and does what we need but for core I definitely think we need to look at it and whether whether it is creating too many revisions or many entities when we do replication so actually on that point having the axes of revision translation and workspace for every entity type I thought that you said something about a diffing API maybe this isn't related but wouldn't it be so if a workspace has a parent workspace that is by default just the live workspace wouldn't it be that you only need to store entities that are different like you only need to store the things that are different in whatever workspace than the parent workspace and so that greatly reduces the number of duplicated records that you need to have for everything and then also simplifies the total space which was like I think four dimensional at that point but now it's only like three and part of some in theory I think the problem there might be that if changes happen in the parent that create a difference in the the other one that's not going to be tracked so when you go to push it back it's potentially harder to if you make a change in the parent then you do an update and it pull the change down but then you'd get a conflict and you'd have to resolve your conflict I'm like yes it's based very much on getting so yeah I do really only need to store the changes we went through a lot of iterations in the contra modules on how we store things and got into a lot of complications and currently in contra we store everything multiple times and that can be pretty hard I think in CPS it does just store changes so yeah it needs a lot more discussion and there's sprints this week so so Kevin O'Leary TK O'Leary I'm totally applaud the I mean everything's awesome this is really really great stuff and it's very badly needed and I'm totally for the idea of it being on multiple sites and being able to replicate across multiple sites because I think that if we look broadly at what's happening in the world of large organizations using Drupal this is what they want to do they want to have a metasite that crosses their entire organization and leaks all their content together we've seen this at Acwia this is why we have content hub and why other people have done other things similar to that but I think looking at your whole plan from beginning to end I think every step is really important I feel like the step of let's clean up these UIs and make a good sort of mental model or way that the user can understand how to resolve conflicts and do merges and things like that being the last step is a mistake because the way that the users understand the mental model and the way that we construct the actual data model are inextricably linked and we need to map things to the way that the users are going to want to understand the data model that people mentioned get is a really good example of a tool which is incredibly powerful for which ever since it was created app developers have started creating all kinds of different ways of visualizing the tree and creating different kinds of applications to visualize diffing or mapping the tree or doing different kinds of things where they can create a visual model where the user can understand the mental model of how things get replicated and how I move back up the chain and where, what branch am I on and where am I in this whole structure and I think that if we work on the visual model of the UI for that much, much earlier in the process that it's also going to tease out and help us to resolve issues around what's important about the data model Does that make sense? Yeah, it makes sense and we have already been thinking a little bit about moving some of the UI stuff a bit earlier because I know there's some interest in getting bigger UI pieces into each release of Triple 8 but it's sometimes hard to get in these UI changes if you don't have the API behind them so we need to definitely think about some of this stuff also we'd like to try and keep the UI as simple as possible and maybe even pluggable so that with core you get a nice simple UI where you just sort of change a moderation state on a workspace and it's published and then we sort of need to look at what published means does it push up to the upstream space after it's published all these kind of questions but try and keep it as simple as possible and then we can have these add-on modules that do different ways of replication that do the cross site replication that allow you to do other, I don't know, crazy not just to replicate to the upstream but replicate to some other workspace or to multiple workspaces at once so we could have a content hub type thing where you can replicate out to 10 sites at once so it would be nice to keep it flexible but have a nice a nice basic UI so we do need to think about it early and we have got UX people trying to sort of solve these problems fairly early on like the trash stuff the UI so that were done quite a while ago and it's only the last few weeks that we've actually started working on building it so hopefully if the UX people can start getting a perfect world ideal UI early on and then we can try and work how we can fit the API to make that happen and what the MVP kind of steps would be together I think what I heard and maybe this was maybe I was mishearing was that you would have the API and much the same way that Git is what it is and provides no UI and then people could create their own UIs that visualize the revision stack in different kinds of ways and that's where I think we run into problems from a usability perspective and a consistency perspective across Drupal and here is a place where I feel like we need to be opinionated in our design if not necessarily in our code more opinionated in the design in the underlying code because if we have a cohesive and logical visual model of what the tree looks like to a user that can be extended and added on to I mean you can add on icons that represent replicate across sites or replicate within sites things like that that everyone uses this sort of single model to describe the tree that it becomes a kind of a touchstone that we can all kind of latch on to oh well this is how we all understand it even becomes easier for us to describe things to one another because we can just throw it up on the board and say oh well it's here you're on this note and then it goes much the same way that you created the diagram in your presentation it gives you something that you can hold on to so I think initially when we started looking at the initiative back in New Orleans it was very much the plan to build all the API first build the UI afterwards and we quickly came to found that we need more UI in earlier on so I think that's changing more and more and as we keep going I'm sure we'll get more UI in earlier and I think we do need the UI in earlier but I'm still concerned about the API and the data model and how we even do a simple entity query now we've got workspaces and entities that can live in multiple places and more revisions in one workspace and another and all this crazy data yeah it's coming along great though I think the place where we are at now is good and I'll definitely become more involved in the design part as well so to Kevin's comment I think it's important to distinguish when we do work from when work lands in core so while I agree that it's very important to have design very early in the process so that we know what it is that we're building in a way that's available to everyone at the same time that doesn't mean that Adam user interface itself can still be phase F that doesn't land for several years that the work space initiative has already demonstrated that it can put user-facing changes in core it's already demonstrated progress and success as an initiative so I want to roll back the pressure a little bit to have user-facing changes in every release of every minor release because that's it's also a very complicated problem that we need to get right and so there will be other great user-facing features that land in 8.3 and make 8.3 a release of Drupal so I want to install this pressure doesn't need to be only on your initiative but I do agree that having the design work done early so that we know what we're building and then can actually build that which involves not only having the design for the user interface but actually the APIs that makes the functionality that it exposes work can be something like that. I think the concern I have that even though we can add all this experimental modules sort of rip it out and start again and change things and it can be API breaking the data still needs to be all intact and working so we need to get that working and perfect really to start with so I think that's going to be the tricky first step with workspaces specifically any other questions? No, I think we're good so the only final thing I've got is that there's a boff at 2.15 so right after lunch so if anyone wants to start discussing some of this stuff or if you've got any other ideas then I'll be there in the boff and happy to hear any ideas and suggestions and then we're sprinting on Friday so I'll be there on Friday trying to get Trash ready to go into call and then there are sprints on Sunday at Sunday even though I'm not there there will be people sprinting on this stuff Thank you


Welcome to the original gangsters podcast. I'm your host Scott Bernstein quick hitter edition going out to the city of brotherly love. Welcome home, Sonny Mazzone, first major hitter from that 2020 racketeering case that took out a underboss, a capo and some soldiers out of the Philly Bruno Scarfield crime family Sonny Mazzone, the little brother of underboss handsome Stevie Mazzone, did about a year, a couple months just came out last week is in a halfway house. His brother's doing five Dom Grande, the capo that was that was nailed that a lot of people are calling the heir apparent to Joey Merlino will be the next boss of the Philadelphia mafia possibly he's doing about six or seven but Sonny did a year and now he's home it was his first major jail time, first major prison time so it was good to see that he could do a year and come out looking better than ever. He's a guy that a little bit more Stevie's known as a people person. I know Stevie can can get animated and and I know he can lose his temper there's that famous video from Fox 29 of him kind of losing his shit on a street corner but a little bit more mild manner than Sonny Sonny I think has a little bit from what I hear a little more hair trigger temper but is a guy that's been a loyal soldier it's been around the Merlino camp you know from the beginning I was I was surprised that according to this case that that came down in 20 everybody caught pleased to besides learning that there was a making ceremony that was caught on tape we still haven't seen the transcript but a making ceremony in in the fall of 2015 was recorded Stevie Mazzone was one of the people that was conducting the making ceremony and we found out that Sonny got his button I was surprised that Sonny it took him until you know he was in his early 50s I guess or late 40s that to get his button I thought he was a guy that probably got made earlier but it doesn't look like that case I think he's 58 right now that was nine years ago so he would have been 49 or 50 but Sonny Mazzone is out of prison Stevie still got a couple more years Don's got a couple more years but Sonny is out back in Philadelphia I'm not sure if he got to catch that uh Philadelphia Eagles loss or not but I know he's a big Eagles fan so he'll be keeping tabs on what the what the birds are doing in the off season but Sonny Mazzone again a guy that is um in very good standing somebody that has a lot of respect and someone who speaks for his his brother so over the next three or four years with with Stevie behind bars you should expect Sonny to take a more active role I would guess um that's my report right now from Philadelphia Sonny Mazzone home after a year scot-brunching OG pod out


Yeah, ready? Hi, I'm Kamran Yusuf from Storage Made Easy. And here, I'll show you that you have got your Swift storage and how for end users, you can turn into and give functionality, just like Dropbox, where the users, they can share files, they can access the files in a business user-friendly manner using the browser, mount it as a drive on a Mac, Windows with full audit control and security control for the admins. We are a UK-based company. We started about five years ago and started sporting OpenStack Swift in 2011. We are part of the community and sport OpenStack Swift storage. We provide a storage Made Easy as an appliance where you can deploy it either in OpenStack, Glance, on EC2, using VMware, vSphere, KVM, Zen, Microsoft Hyper-V. So you have full control over the data and how it is accessed. Our basic market is service providers and large enterprises who have deployed OpenStack, who have deployed Swift, and now want to sell the storage to their business users. So what essentially do we do? So before the cloud came along or mobile clients bring their own devices, they came along. Life was pretty easy for sys admins. They would have their window shares, users if they were remote, they would VPN or the users. They would just have shared drives. And they could access the files. And then Dropbox came around, Box.net came around. It made collaboration much easier. They could access the data anywhere. And frankly, for the consumer technology, that was much better than what the enterprise was providing. And that was the basic idea for a storage made easy that can we combine the legacy systems and also the new cloud technologies and give the end users a seamless experience. So our gateway, you can deploy it in your own data center. It can access the storage on the cloud. You can encrypt the data that's going outside, using AES 256-bit encryption. And you can also add your existing shared file system of SIFS or NAS or SAN and access it internally, just like the users they are used to using window shares and also on their mobile devices and using different protocols. For example, WebDav, FTP, no matter what storage you are using. So if you have Swift, you can access it using FTP WebDav as a drive explorer, as a finder, as an attached drive on Linux mounted. So who is using our software Lush? They are a large cosmetic company. They run on Memset. They use their storage and they have deployed storage made easy and provide all their marketing material to all their employees in about 70 different countries. Scale-up, a service provider, they have Swift and they provide private drawbacks to their customers. Cloud and heat, Nimbus, data-centered, SohoNet, a major retail U.S. bank, a U.K. bank, a major U.S. retailer, they all have Swift deployments and they use SME to provide store, to give access to their business users. We are certified with Swiftstack, Mirantis, HP Helium, Softler, Rackspace, Cloud VPS, Memstack, and of course, OpenStack. So we deploy the appliance and run our test suite on the storage. So what does a storage made easy give you out of the box? It turns into, I wanna give you a demo, you will see that it turns it into an enterprise dropbox with full auditing and governance. You can tell that okay, what users, what IP addresses can access, what shared folders can user access. You can integrate with Active Directory and LDAP, import the users and do single sign-on. If you're using a public cloud or if Swift, you don't have your own deployment, it's on the public, like for example, Rackspace, you can put a key in and all the data at rest that will be encrypted using 256-bit encryption. We provide protocol adapters and you can access it using WebDev, FTP, SFTP. If you want to, you can also reintegrate with the solar and all the data, the content that can be in text. And if you want to do a search, you can do content search on the data. You can deploy it on bare metal or Hyper-V. Most of our users, they're using some Hypervisor, be it vSphere, be it OpenStack, be it Microsoft Hyper-V. We provide native apps for all the major desktops and all the mobile platforms. What is our architecture? There is no magic. We have OpenStack Swift provider, but we also support Amazon S3, we support Google Storage, we support Azure, and across all those storages, you will get a unified view. At the bottom, you have the encryption engine. If you have configured encryption, the data that will be encrypted using your own key that never leaves the appliance. So no one can access your data unless they have the key. On the side, you have the audit manager, everything, every operation that's audited. So for compliance, you can access those. You can create shared folders, you can set permissions or read, write, downloads. You can do versioning, optimistic versioning, pessimistic versioning, set policies on how many versions do you want to keep. And then we do not store the data in any proprietary format. So if you want to access your storage through a different channel, you upload data directly to it, the sync engine that will discover the data and make it available to you. Sometimes when people are using storages, they're worried that, okay, they are being reliant on just one storage. So what you can do is, you can add Swift as your primary storage, and let's say add S3 as a backup. So any operation performed on the Swift storage, that will be replicated to Amazon S3. If Swift is not available, it's for business continuity. It will go back, it will get the data from Amazon S3 in read-only mode. And at the top, we provide full API. All our clients use that. If you want to integrate your own clients, you can integrate it. And then the pervasive protocols, WebDav, FTP, SFTP, they are supported. If you want to integrate with your own out-of-the-box, we integrate with Active Directory and LDAP. But if you want to integrate with your own, if you have some other technology, for user management, you can integrate with that also. The appliance, you can deploy multiple appliances and you can support hundreds of thousands of users and you can scale out. So all you need to do is deploy multiple servers, separate the database that we keep for, to keep the permissions and some metadata, and off you go. So there is no magic there. All right, so now I'll give you a demo. So once you have configured the appliance, you can add multiple storages. That's the web browser view. So you just go to the dashboard and that's the admin who is doing that. You can allow your users to do this also, but it's very easy. These are all the different providers that we support. But here we are for OpenStack Swift. And you just give the user name a set up the endpoint and the providers are added. In the file manager, the show, so here, in the file manager, you can see all the files. You can upload, download. If you want to edit the files online, we do integration with Zoho. So just like Google Docs, you can edit the files just via the web browser. You can generate shared links. You can set the policies that, okay, for how long is it available? How many downloads do you want to allow? Do you need to set up a password? And all those things, they are fully, the admin, he can set up the policies, the end users. What capabilities do they have and what can they do? It's fully customizable. You can turn versioning. You can set up metadata. You can change the user interface. And if you are an ISP, you can also do full branding. You can apply your own style sheets. You can change the logos. You can change the colors and do all that. Fully and branding, that's also available for all the desktop clients and mobile devices. So they will know that, okay, SME is being used. You can do your, fully your own branding. Once you have added your users, so if I go here, I've added LDAP and Active Directory and you can import the users and set the permissions and the groups from Active Directory. So here, I can just get the users and import them into SME from Active Directory with the roles in real time. Now, I'll show you that, okay, once you have configured your system, how you can access it. So the first thing is that if you have users that are used to using window shares, you just, in Explorer, we provide a drive and exactly the same data, you can access it in Explorer. You can do exactly the same in Mac and also on Linux. You can upload files, open the documents in Word and the user, he will know that, okay, you have an object storage at the back that's doing where the data is stored. The drive is useful if you have a large amount of data, you don't want it offline access and you have to be online to access the data. We also provide sync and you can select the folders and once you have selected the folders, what's the local folder, what is the folder on the cloud and then multiple devices, that data that will be stored locally, so you have offline access and between multiple devices, it will be automatically be synced. We provide full packaging, so we provide a default client, but if you want to do branding, we provide a packaging. You set up what you want to call it, what the endpoint is once you have done your deployment of SME, what components do you want to use and you just press the hit button, the build button and it will generate an installer for you and you can distribute it to your end users or customers. We also have a done integration with Microsoft Office, so if you're using Microsoft Office, you want to create a new email, you just click on new email and rather than doing an attachment, you can just select the file and set the expiry, whatever the policy is and you can just send them a link. So you get rid of sending the attachments, you can just generate shared links and send to your colleagues.  Same data, that's an Android simulator, so I'm just gonna, again, exactly the same files on your Android device, you can access, download, sync. I believe we got an error. All right, yeah. So you can download, open in on your Android device and access the files. This is my Windows phone, native desktop client, native client for iOS, again and same data, you can access it, download it, open it in other apps. Okay, so any questions from anyone? No? All right. All right, thanks guys.


Today I have to speak on the imaging of rotator cuff what to report. So it's basically a very day-to-day topic for everyone So I tried to make it as simplified as possible Everybody has different ways to look at the rotator cuff So MR basically provides explicit details of all the cartilaginous elements, ligaments, tendons and muscles It provides information about marrow edema and bone contusions, which no other modality can. It's multi-planar No contrast is required. It gives information about an ossified cartilage as well Neurovascular bundles and it's however expensive and not readily available So my protocol for rotator cuff tears is coronal sagittal and axial PDFF images. I use the coroner T2 To identify a tear versus tendinosis a sag T1 I use basically for these muscles whether there is any fatty atrophy or Fatty replacement and axial. I do not take a gradient image PDFF I feel is more than enough to see the Articular cartilage and the labrum. The optional images are gradient images 3d PDFF adsat images Which are currently available on some machines, which are good some vendors don't have a good 3d PDFF Some have a good one. So if you have if your machine is giving a good one That is a good idea to use because you can have multiple reformations to see us see small tears So basically supraspinatus tendon is the most important one. It has to be imaged very well The technicians have to be really well trained to be able to give good images of the shoulder So you have to understand that there's a supraspinatus muscle and a supraspinatus tendon This is the myotendinous junction, which is giving rise to the tendon And that tendon inserts over the brator tuberosity. So your angulation of these sections oblique coronal images of the shoulder have to be angulated parallel to this tendon and not the muscle and Definitely not according to the anatomy leg. We don't have a straight sag or a straight coronal It has to be parallel to this tendon and perpendicular to that tendon The field of view has to be in such a way that the Glenohumeral joint is in the center and you are covering adequate portion of the supraspinatus Rotator cuff muscle and also going just beyond the Insertions of the tendons. You shouldn't have a too large FOV Otherwise, you will end up seeing the lung, lung parenchyma and breathing artifacts These should not extend in the air So your FOV has to be perfect around 15 to 16 centimeters FOV The hand has to be placed in neutral position That is the thumb has to be pointing upwards and there should be a Air gap between the arm and the chest If there is an air gap, then there is no transmission of the breathing artifacts to the shoulder You get better images without any movement artifacts One more thing that we remember is the first section has to go through the achromyclavicular joint If it does not go to the achromyclavicular joint You are going to miss or sacromyal and it's different types We are going from top to bottom. This is the supraspinatus muscle and this is the tendon As you go down, you start seeing the long rid of bisects coming out Then you start seeing the subscapularis and the infraspinatus tendons The infraspinatus tendon goes right up to this point and inserts over here does not insert here as it's most commonly thought The subscapularis goes to lesser tuberosity does not go beyond the lesser tuberosity This is one more important thing to remember And this is the small tendon of the teres minor which is much lower down as compared to the infraspinatus tendon Similarly, when you're going from anterior to posterior, these are the multi-pinate appearance of the subscapularis tendon as it inserts over the lesser tuberosity Then you have the long rid of bisects crossing and then you start seeing the supraspinatus tendon So your long rid of bisects is the landmark to tell you on the coronal images whether the subscapularis is finished and The supraspinatus has begun. So this is a supraspinatus muscle and the supraspinatus tendon inserting over the greater tuberosity Lastly as you go more behind you have the infraspinatus tendon on the top and the teres minor tendon at the bottom in the sagittal sections as you go from In the end to outside or from medial to lateral you start seeing the muscle belly and you start seeing a small tendon inside So this is the myotendinous junction of the supraspinatus the subscapularis Infraspinatus and more lower down you start the teres minor So these tendons come together and form the subscapularis tendon. This is the long rid of bisects that is coming out So this is a rotator cuff interval this one on the top you are starting to see the supraspinatus tendon This is the infraspinatus and this is the teres minor. So you should trace them right up to their insertions So as I said when you start seeing the long rid of bisects tendon You have to know that the subscapularis tendon is already over So anything beyond that you it is not going to be a subscapularis. It has to be supraspinatus So you still see the entire insertion of the supraspinatus from here to here This is what you call as a conjoined tendon where you really can't differentiate between the supraspinatus and the infraspinatus This is the infraspinatus and much lower down you see the teres minor This is a societal T1 weighted sequence which shows you a normal muscle belly appearance When you start seeing this bright fat within the muscle belly, you start to identify what is called as a fatty replacement This is further graded as grade 1 2 3 and 4 as we'll see later on So next we start seeing what is called as the rotator cuff The first and the most important tendon that you evaluate is the supraspinatus So this is graded according to the different types of degeneration right up to the tail So what really starts is the degenerative signal, which is called as a supraspinatus tendonosis This appears as a slight swelling of the supraspinatus tendon with bright signal on pdfats at images You may or may not find inflammatory fluid in the subacromial bursa But definitely you start seeing a signal change Now this signal change is because of a mild tendonosis This further progresses into moderate and severe tendonosis And later on when the tendon acquires a signal which is as bright as the joint fluid or the bursal fluid Then you start calling it as a tail The earlier textbooks you may find the term tendonitis But nowadays we don't use the word tendonitis because there is no inflammation in the supraspinatus or any tendon Basically so you start calling it as mild moderate and severe tendonosis and then followed by a tail This is an articular surface tail One more thing that we need to understand is this is the insertion of the foot plate of the supraspinatus That is inserting more of the greater tuberosity There is no articular cartilage over the greater tuberosity The articular cartilage starts in the humeral head and ends at the humeral head, neck, junction So this is the articular surface From here to here is the insertion And from the top is your bursal surface So this in the illustration that I am showing you is a partial thickness tail Involving the articular surface So because of the partial thickness tail involving the articular surface and there is slight retraction of the tendon This is called as a pasta lesion or partial articular surface Tendon avelgen So when you mean to say tendon avelgen means the tendon has come off and it has avelgen traveled a little bit of distance from the insertion Then you start calling it as a pasta tail. This is how you see it diagrammatically This is an example of a bursal surface tail Now you are seeing that this is the articular cartilage. This black line is your supraspinatus tendon, articular surface This is the insertion But here you see that there is discontinuity of the bursal surface and this is a bursal surface tail Whenever there is a bursal surface tail There is what is called as a puddle sign or fluid collection along the lateral aspect of the greater tuberosity going down there That is because there is a rupture of a wall of the cervical means of deltoid bursa And that fluid leaks into this space and forms what is called as the puddle sign So whenever you have a suspicion of whether you should give a bursal surface tail or not Identify this fluid if there is fluid you can definitely give it as a bursal surface tail The third variety is an interstitial tail. In this patient you see this black line Which is an intact articular surface a black line on top Which is the intact bursal surface and in the center of this bright signal which is as bright as fluid is Intra substance tail or interstitial tail This is how you see it in this sagittal image and this is a diagrammatic representation Now there is something called as a rim rent or an insertional tail Now insertional tails which can be full thickness or like this which can be small and partial thickness You need to identify sometimes by enlarging the image and seeing that there is a very very small tail there This is an insertional tail not involving the bursal or articular surface and there is no retraction So this is not pasta. This is not any averse tail But there is a very very small focal tail at the insertion and that is what you call as a rim rent or a focal Partial thickness insertional tail Sometimes they may be complete. Sometimes they are partial Then when you start seeing the tails whether they are partial or full thickness tails You start seeing or something called as retraction So whenever the retraction is less than 10 millimeters, it is called as grade 1 retraction Whenever it goes up to the mid-humeral head or about 1.5 centimeters to 2.5 centimeters It becomes a grade 2 retraction when it goes up to the glenohumeral joint or more than 3.5 centimeters It becomes a grade 3 retraction You don't see a tendon at all when you're imaging the mid portion of the humeral head And sometimes when it goes beyond the glenohumeral joint, it becomes a grade 4 Retraction next we move on to what is fatty replacement fatty replacement is the replacement of the supraspinus fossa or any muscle belly by bright signal on T1 weighted images, which is called as fatty replacement They are further graded into less than 25 25 to 50 50 to 75 and more than 75 as grade 1 2 3 and 4 In this you see that the teres minor muscle is completely replaced. So this is grade 4 fatty replacement This is around grade 1 fatty replacement of supraspinus. This is grade 2 fatty replacement of the infraspinus Then you move on to calcified tendonitis. Now here you can notice that there is itis This is because there is inflammation because of deposition of calcification within the tendon substance or The calcification within the tendon substance has just extruded and gone out into the subacromial space Subacromial bursa and that is what is incited in inflammation or inflammatory response That is when it is called as calcified tendonitis and it becomes painful And when you start doing a lot of rotator cuff ultrasound You will find that there are calcifications in a lot of people But all of them do not have tendonitis because all of them do not have symptomatic calcifications So whenever the symptoms are there there is tendonitis because the rotator cuff tendons are susceptible to External impingement. You have to look for types of acromion Type 1 is the flat under surface. Type 2 is concave or some under surface which is parallel to the humeral head Type 3 is type 2 morphology with an anterior inferiorly directed spur and type 4 is when the under surface is convex Then there is something called as a keels spur in which the spurring is seen on the lateral aspect as well as the medial aspect on the coronal images This is what is called as a keels spur and keels spur is almost always associated with a tear of the underlying suprasmanidus tendon You have a down sloping acromion in which the horizontal Appearing bone is the clavicle and the acromion has gone down or it is down sloping and that is what reduces the space For the suprasmanidus to move and that becomes a factor for external impingement Acromion clavicle arthrosis itself because of presence of osteophytes and synable hypertrophy can cause reduction in this space in the critical zone And thereby leading to a tear of the rotator cuff Pass acromion if there is a formation of the pseudo arthrosis because of assacromion Then this fragment moves with every abduction and adduction and that gives rise to impingement or external impingement of the suprasmanidus tendon Similar to the suprasmanidus tendon you have partial thickness in complete or full thickness tears Which are seen in the infrasmanidus subscapularis in the rest of the tendons Whenever there is a tear of the tendon you should measure the tendon tear from anterior to the posterior aspect And whenever there is a partial thickness there you have to measure the percentage of the thickness that is involved That is whether the partial thickness involves 50% of the tendon thickness 30% or more than 70% or whether it is near full thickness tear In this patient you are seeing that there is full thickness tear of the infrasmanidus tendon with retraction of the tendon up to the glenohumeral joint Next is subscapularis tears subscapularis tears you have to remember that subscapularis Tears subscapularis inserts from in a vertical fashion from top to bottom along the placer tuberosity So you have tears involving the upper portion mid portion and the entire subscapularis This has been further classified by left force as type 1 2 3 4 and 5 tears Type 1 is upper one-third which is partial tear type 2 is upper one-third which is a complete tear type 3 is upper two-third type 4 is The entire suprasmanidus subscapularis tendon But there is fatty infiltration of 1 to 3 and more than 3 is Type 5 so these are the left force subscapularis tears Now why you need to identify that is if the upper portion is involved then you are going to look for long head of biceps dislocation or subluxation They usually are not involved in lower subscapularis tendon tears and Second most important thing is there is different treatment for the different types So this is an example of left force type 1 in which you have a tear Which is partial thickness involving only the upper portion of the subscapularis Type 2 when there is full thickness tear, but only involving the upper portion This is type 3 and this is type 3 But it's almost upper two-third and lower portion of this tendon is still intact and type 4 in which there is complete Or superior to inferior entire subscapularis tear is there in this patient and that's why the humerus has subluxed anteriorly In the intrasmanidus tendons the sub the humeral head sublux is posteriorly Now whenever you must have Seen terms that people have described as massive rotator cuff tear The massive rotator cuff tear is called when the tear is more than five centimeters in size and involves at least two muscles So it usually involves the combination of supra spinners and infraspanidus tendons and the tears are more than five centimeters in size So in this patient you can see that subscap is intact the teres minor is intact But there is a tear of the supra as well as infraspanidus So this is what you call as a massive tear and whenever there is complete tear of all the tendons around the Humerus except may be the Teres minor tendon the subscap supra and infra all of them are torn Then you call it as a global rotator cuff tear Sometimes because of chronic complete tears of the supraspanidus What happens is the humerus has shifted upwards or there is superior migration and that Constantly irritates the acrylamide clavicular joint which undergoes a diastasis or dislocation and then the fluid in the subacrylamide Bursa goes out and forms what is called as a subcutaneous Swelling cystic swelling, but you identify this subcutaneous swelling clinically, but what is actually a problem is a full thickness complete tear which is Kind of a neglected tear and that is what is called as a geezer sign So whenever you see a subcutaneous swelling Overlying the acrylamide clavicular joint you should always look for a tear in the supra's penitentus tendon Adhesive capsulitis is almost always mistaken for rotator cuff tears. That's why I just put one slide Strict scene, adhesive capsulitis the findings are the anteroinfra joint capsule is thickened and bright and there is dirty Looking soft tissue in the rotator cuff interval. If you find these two or either of these two then you can give a diagnosis of adhesive capsulitis Firstly, let me conclude by take home points. What to report in a supra's penitentus or basically a rotator cuff tear? First identify if there is a tear If there is no tear then you can call it as tendinosis and grade it as mild moderate or severe If there is a tear try to identify whether it is an industrial partial thickness or full thickness tear If it's a partial thickness tear identify whether it is a Barsal surface tear, which is also called as anti-pasta Articular surface tear, which is called as the pasta and insertional tear and whenever there's a partial thickness tear Identify what thickness of the tendon it is involved in. If it's a full thickness tear then look out for retraction Measure the APN transverse dimension of the tear identify any muscle bulk loss Identify the grid of fatty infiltration look for tears of other cuff tendons Rotator cuff arthropathy if there are if there is any chronic change like Intraucous cystic changes and I try to identify what caused the tear in the first place like types of acromion or any other factors of external impingement Thank you very much for your kind attention


Hi everyone, Maria here. Today I'll be talking to you about accelerating the Delft-Galbraith algorithm with fast sub-field root detection. This is based on joint work with Craig Costello and GSU. The general super-singular isogenic problem is the foundational problem in isogenic-based cryptography and it's believed to be secure against both classical and quantum computers. Given two super-singular elliptic curves defined over fp squared, it asks us to find an isogenic between them. Note that we do not assume the knowledge of any torsion point or that we know the degree of the isogenic. This makes the problem substantially easier, as shown independently by Castrick and DeCru and Mano and Martindale in their recent papers giving polynomial attacks against the key exchange SIDH or the encryption scheme Psyche. So here we're really just considering the general isogenic problem, where all we know is that we have two elliptic curves defined over fp squared and we want to find an isogenic between them. We can convert the isogenic problem to a path finding problem in the isogenic graph. Here the nodes are elliptic curves which we label with the J invariant which lies in fp squared. The edges are then isogenes. So finding a path between two J invariants in this isogenic graph is equivalent to finding an isogenic between the two elliptic curves labeled by this J invariant. In the isogenic graph there are two types of nodes, those lying in fp squared and those lying in fp. Gelsen-Gelbreit's key idea was that finding paths between the fp nodes is comparatively easy. So the bottleneck set of finding isogenes between these two J invariants is really walking in the graph until you hit a node defined over fp. Because once you find a path from your start and end node to nodes defined over fp, then you can navigate in the fp subgraph which is a lot easier. In Solver we implement an optimized Gelsen-Gelbreit's algorithm and determine its concrete complexity. This is really important for determining concrete parameters for schemes whose best attack is the Gelsen-Gelbreit algorithm such as the soundness of a recent isogenic-based signature scheme, SkiSign. Building on this we present Supersolver with superpower fast subfield root detection. This allows us to scan a larger proportion of the graph at each step, therefore minimizing the number of fp operations per node revealed in the graph. In this way we can cover a larger proportion of the graph while still minimizing the number of fp operations. In doing so we provide the best algorithm for finding paths to the fp subgraph and we decrease the concrete complexity of the Gelsen-Gelbreit's algorithm. This affects schemes such as SkiSign and isogenic-based signature scheme and Beeside and isogenic-based key exchange. For more details please come to the full talk on Wednesday. Thank you.


Hello, how is everyone? I'm Nick Johnson founder of ENS and lead developer And I'm here to give you an update on what's happened with ENS in the last three years Which is give or take three hundred years in crypto Before I actually start Can anyone who's got an ENS card hold it up above their head? Wonderful probably about half of you. I'm so delighted with the hell everyone's been doing with this If the person next to you held a card up Have a word with them say hi Tap your phone to their card and you'll get a poet that proves that you visit other you met them at DevCon We still have a few of these cards left at our booth on level three So after the event come down. We'll print one for you with your ENS name and your ENS avatar on it We expect we'll run out sometime this evening. So I'm sorry if we don't get to everyone But this is a great opportunity to meet the person next to you and have cryptographic proof of that afterwards So first off the agenda I'm going to recap everything we've done in the last three years and then go on to talk about What we're working on now and what we're working on next First of all in the next category Thorin which is ENS's new look and design system and new app Second of all talking about scaling ENS with off-chain reads and writes Next the name wrapper which you may have heard about as a way to improve the functionality of ENS names and the ability to issue trustless sub-domains Finally zero gas DNS integration how we can use these other components we've built to make ENS integration possible for DNS names without any gas fees and then the conclusion First of all the recap it's been a long long time since I've been at a conference since I've talked on a stage in front of a lot of people Since I've given anyone an update on ENS Last time I spoke was at last DevCon October 2019. We're just transitioned from the interim auction registrar to the permanent registrar Featuring its current renewal model and That was a mere five months ago and while it was doing well at the time We had very little idea of the phenomenon ENS was going to be coming in the next Few years. We had about 50 integrations with various wallets including MetaMask applications such as Etherscan and so forth. That's changed a bit in the last three years Our set of integrations now looks more like this So as you can see we've come a long way from under 50 integrations to over 500 We had about 300,000 registrations back in the day. That's now over two and a half million We had about 96,000 Ethereum addresses that had interacted with ENS in some way. That's now over a million addresses 66,700 years of registration had been purchased. That's now over six and a half million If you strung them all end-to-end figuratively And the nascent ENS treasury had a stunning 382 Ethernet at the time. That's now 38,000 Ether And I'll talk soon about the Dow and how it's able to put that to use Of course, it's not all about the numbers ENS has accomplished a lot on both technical and governance fronts in the past three years Some of it will seem like old news, but it's been a long time At DevCon 5 we had limited DNS integration with only the dot XYZ TLD supported You could take an ENS, sorry, dot EXYZ name You could import it into ENS and use it just like you would any dot ETH name Since then this has been expanded to nearly every top level domain That supports DNSSEC, so that's nearly 90% of all top level domains Nearly any name can now be imported into ENS and used as a native name Just ask our developer advocate Luke.computer. It's printed on his badge, I believe There are transaction fees associated with importing any of these names And at times when gas prices have been very high and the ether price has been very high It's been quite pricey, but we've got a plan to improve that massively, which I'll talk about shortly Another major improvement has been ENS's transition away from being just a way to name wallets and decentralised content To being a Web3 native identity platform With the introduction of avatar records and text fields that provide information about your profiles Such as your Twitter handle, your email address Your ENS name now represents you as your Web3 identity It's a universal portable identity And one project that's been bringing that to more users is Sign In with Ethereum It started out as an RFP issued by ENS and it was funded by a joint grant from ENS and the Ethereum Foundation Spruce won the bid for that and has done an outstanding job of growing it into the primary way that people authenticate with Ethereum replacing a plethora of incompatible and different standards for signing messages to assert your identity With a symbol system that can be, thank you, that can be Easily plugged into existing systems including Web2 legacy systems But of course when I talk about the last three years and particularly the last year Top of most people's minds will be the launch of the ENS DAO Which is now one of the largest and most active DAOs in Web3 Which I am absolutely both blown away about ENS has always aimed for gradual decentralisation Starting with the minimum set of permissions held by the widest number of people we could Which was the original four of seven multi-sig Unlike most multi-sigs it included participants from around the ecosystem not team members And they had limited powers to upgrade ENS to replace components Our goal was always to move from that to a system where ENS was governed by a decentralized organisation Since we launched all the way back in 2017 The only example we had to go on was the DAO Which needless to say was not a stunning success that inspired us to immediately decentralise But things changed a lot and the DAO space is now a lot more mature than it was in the past And we decided that the time had come that things were mature enough that we could Let the ENS community govern ENS And the DAO is the major milestone along that path of gradual decentralisation The DAO is now responsible for almost all governance levers and controls available to ENS Including approving contract upgrades, changes to core parameters such as pricing and how expired names are used It's also responsible for treasury grants and projects using the funding gathered from the protocol In the year since the DAO's launch The ENS DAO has shown that it can maintain a high level of civilised discussion Made useful progress forward in improving the protocol Besides budgeting and day-to-day bookkeeping, it's made meaningful changes to the protocol Including changing how expired names are handled in order to safeguard the stability and fairness of the system The DAO has also started to build out public goods and grants programmes of its own One example of this is the small grants rounds that we now run Inspired by nouns props room This is a regular system where anyone can submit a proposal for work they want to do or work they have done Anyone with ENS tokens from the DAO can vote on them And the top five in each category, we have a public goods category and an ecosystem category Then receive one each in funding to pursue it The public goods is focused on anything in the wider ENS ecosystem And the ecosystem category is focused more on things that relate directly to ENS And we hope this can work to better incubate and start up new projects Both for ENS and for the wider public goods on Ethereum and Web3 ecosystem Working groups have also funded initiatives on scales small to large Ranging from a 200,000 K, sorry, 200 K ENS token grant to the protocol guild Who have formed to help fund core developers throughout the platform 169 K GITCOIN matching pool and we continue to fund and support GITCOIN And smaller projects such as this plugin for discourse forums Which provides you with insight into the roles of delegates and their participation on the forum Which is something that any DAO that uses discourse can take and plug into their own system This was built by Karma and integrates with all their stuff You can also just use it to provide insight into how your delegates have voted How active they are, how many tokens they have and so forth The DAO has also resulted in more community participation in the core protocol One major success story is Rafi's work on improving ENS's normalisation functions Normalisation is how we handle names like uppercase knack, being different from lowercase knack Ambiguous emojis, hidden characters and so forth To start, we used a well-tested system called UTS46, which is what the domain world uses But it's become clear over time that ENS has some unique requirements And we wanted to enable things such as emoji and other characters that are popular in the community But not supported directly by DNS So Rafi has been working on harmonising all of this We're very close to rolling out the new standard for DAO approval And it will enable a much wider array of characters, while also providing more protections against deceptive names The last three years has also seen an explosion in community-led ENS initiatives Independent projects that build on top of the ENS ecosystem One popular example you may have seen is the ENS leaderboard Which shows people with Twitter handles that contain .eath and their ranking relative to followers We've had some pretty popular ones, including Paris Elton, for instance, right up the top of the leaderboard I myself am now ranked, I don't know, number 400 or something We've had the launch of ENS Vision, which is a third-party ENS trading market Allows people to now register names from scratch and also trade existing names And projects such as NEMI, which is a web3 profile Site, it lets you generate a customised profile and in fact the eth.limmo gateway folks have integrated with NEMI So if you have an ENS name that doesn't have content set up It will automatically show your profile with your PoEPS and so forth and you can customise it as you wish Before we start talking about what's new, one small announcement TrueNamesLimited is the name of the development company that builds ENS The company I founded that gets paid by the DAO employees about a dozen of us to build out ENS When we formed it, we didn't really think of it as a name that would be visible to people It was purely an internal thing, but in the intervening time it's become more and more visible And every time we have to say we're from TrueNamesLimited, the company that develops ENS and it gets a bit tiresome So we're renaming to ENS Labs Limited to better reflect what we do and who we are So what's next? First we're going to talk about Thorin Thorin is ENS's new design system and it's built from the ground up with usability and Web3 in mind We've used it to completely rewrite the ENS app from the ground up Coupled with improvements to the smart contracts behind ENS This enables a huge improvement in usability for ENS users The ENS UI faces kind of a unique challenge from amongst Web3 apps and in fact kind of apps in general In that it needs to provide an interface that is both easy and user-friendly for new users But has the advanced levers and sophisticated interaction required by advanced users We don't want to create a situation where the app is sufficiently flexible to do anything with ENS But deters existing users, which is a little bit the case of the current app Or is so straightforward and wizard-based that you need to go somewhere else if you do have more than basic needs By surfacing the important details and flows while still making advanced functionality available under the covers The front-end team have done an outstanding job of writing an app that is all for all users Aside from the functional improvements, we've hugely improved the loading times and made the new app 100% mobile-friendly The new app is at feature parity and live now on the girly testnet Would be live on Ropsten, but that's already been deprecated And you can try it out now at alpha.es domains Just to emphasise it's only on girly. It is a little bit You know sharp edges still the team really raced to get it out in time and did an amazing job Please send us your bug reports, but we aim to have this Launch on mainnet shortly after DevCon once the name wrapper and other contracts are approved by the DAO as I'll discuss shortly So keep your eyes peeled Thorin isn't just for E&S either We've made it available as a standard react library that anyone can use for their web3 apps You can check it out on thorin.es domains And you may have noticed it powering a number of our other sites such as the swag microsite and so forth One of our major ongoing projects is scaling E&S For many projects, this is accomplished by going multi-chain deploying to just multiple chains If you're Uniswap for instance, you fragment your liquidity a bit, but you can work in parallel across multiple chains E&S is in kind of a unique position here We need to maintain a single cohesive registry of names And it's far too early in the L2 and the roll-up ecosystem to pick a single service as the winner that we're going to migrate to Instead we've been pursuing options that make it possible for people to host their E&S names anywhere Without the resolving having to know or care where that is Earlier this year we launched CCIP Read as a collaboration between E&S and Chainlink While previous systems such as bridging often introduce new trust assumptions and require L1 transactions to execute CCIP Read uses a lower level primitive of proofs Which means that in many cases such as with L2s This can be done with no additional trust assumptions over those the L2 itself requires Meaning you could host your E&S name on optimism, have users resolve it from any client that doesn't know what optimism is Without introducing any additional trust that relies on the gateway operator for instance Further the solutions far more flexible than bridging Allowing data to be stored not just on L2s or side chains, but on arbitrary systems including centralized databases At its core E&S is a way for any contracts to fetch data from off-chain resources Because contracts can't directly talk HDB requests This ends up being a little bit like having one of those conversations With a couple who have had a fight and are refusing to talk to each other Well, you tell the gateway that I think that they should give you this data I need So the conversation tends to go like that Unfortunately, just ask them yourself isn't an option So the client has no choice but to play middleman the end result is good With the resolver and the gateway agreeing on a protocol It's possible for the client to facilitate a lookup of off-chain data Without any knowledge of what their shared languages or what the off-chain system in use is The necessary proofs to make this trustless are encapsulated in the response sent by the gateway And verified by the resolver before returning the result from the name resolution This means that implementing the base protocol is enough to enable all current and future L2s and off-chain storage Systems to be used in the ns name resolution For instance, ethers already supports this Which means that you can resolve any ns name that uses it Even if it uses an L2 that didn't exist when the ethers implementation was written CCIP readers already in use in production Both ethers and web3js Support it And so if you use either of those libraries or in fact as of I believe today Web3.py Upgrading to the latest version will mean you automatically support ENS off-chain resolution Some of the largest apps and wallets have already upgraded to support it too including meta base Metamask coinbase wallet as well as ethereum etherscan There's a long way to go in terms of making this latest change universal So please reach out to your favorite wallets and apps If you see that they don't support these new names and ask them to let them know how important it is Like our thorn CCIP read also isn't just for ens. It can be used to add off-chain resolution support to any project Coinbase has gone a step further than just integrating CCIP read for name resolution They're using CCIP read ens wildcard support and ens's dns integration Together to allow their wallet Their wallet users to create ens names under the dot cb dot id Domain for free These names will instantly work in any wallet or dApp that supports ens's new resolution improvements And they have no transaction fees to set up for either users or coinbase Likewise lens is using CCIP read to integrate their own dot lens naming system with ens Any dot lens name you can add dot x sorry dot xyz to the end And it will resolve in metamask or any other wallet that supports this So off-chain read support is great But how do we enable writes? The default option for every platform is to provide its own interface for users to update their records Meaning if you use coinbase wallet, you have to use coinbase to update your records If you use metamask, you'd have to update with metamask But this leads to fragmentation and makes general purpose apps like our own manager much less useful Fixing this is still a work in progress But eep5559 lays out a way forward by enabling a discovery mechanism that allows clients Such as our manager to discover how they can send a transaction or an htp request to update data that's stored off chain It's currently supports writing to evm based l2s or sidechains Or sending signed messages to an htp API, but this is extensible with new methods as they crop up Adding support for this to the enes manager and further standardizing the best practices and making it as as flexible and extensible as possible Is an active area of research and development for the team So next up the name wrapper, which you've probably heard about griping about on twitter because it's been underway for a while Enes predates all of the nft standards And while the dot eth registrar was written after eep721 came out That functionality only applies to dot eth second level domains. So nick dot eth, but not wallet dot nick dot eth or nick dot xyz or whatnot As a result, not only enes names can be transferred, exchanged, etc using standard nft interfaces Further one of the main advantages of tradability is trustless ownership If somebody sells you a name or a subdomain or gives it to you You want to make sure that they can't take it back next week and set it to a different address You're kind of reliant on their goodwill. There are solutions to work around this you can Give that ownership of the name to a contract and we've had a system for that called now dot enes dot domains for some time But it has significant shortcomings in that you're committing your name to a specific contract Where it has to live for the rest of time Which limits what you can do with it The name wrapper solves both these problems It allows any enes name at any level whether it's a dot eth or a subdomain or a dns name To be wrapped as an erc 1155 nft It also allows owners of wrapped names to revoke permissions such as the ability to replace or delete subdomains By mechanism we call fuses Fuses allow the owner of a name to revoke their own control and that of any subsequent owners Over certain functionality on a name such as the ability to unwrap it again To create or to replace subdomains To transfer it to another user and so forth Once the fuse is burned that fuse can't be reset until the name expires Giving a user's guarantee a guarantee as to what can be done to or with their names until the name Exploration is reached the name wrapper tracks these permissions and provides a very easy API for fetching the set of restrictions Currently applied to a name and when they'll expire Alongside the name wrapper, we've also implemented a suite of other contract improvements Including to the dot eth registrar controller The reverse registrar and the public resolver Altogether these will prevent a much smoother registration process for end users and cut down on the number of transactions and gas required As well as other quality of life improvements like allowing contract owners to set primary names for their contracts The long and short of this is that with the new dot eth registrar you will be able to Register a name wrap it in order to set permissions burn fuses And set your primary name all in a single transaction and using less gas than doing those operations would cost today All of these updates are live now on the girly test net And we're planning to submit them to the DAO for approval on main net very shortly after devcom Thank you Finally i'm going to talk about something else i'm excited we'll be able to release soon gasless dns integration Presently claiming a dns name and enus cost a substantial amount of gas It's about a hundred k to a million gas per signature. It has to verify Depending on the ether and gas price that can range anywhere from 20 bucks to at the extremes libel market a thousand dollars Obviously this isn't a particularly scalable solution And so this can be a substantial barrier to dns integration. Fortunately, we have a plan for reducing this all the way to zero So first a quick overview of how dns works It uses a chain of trust just like ssl The root zone is signed by a well known certificate authority and they sign keys for each of the subdomains such as dot com dot link etc Each of those zones uses its keys to sign this their subdomains and so on and so forth Our current dns integration uses this to allow users to claim dns names inside dns Our front end collects up all the complete set of proofs necessary and submits them to a smart contract Which verifies the signatures and if they match it lets them claim the name If you've been paying attention to the talk so far, this may sound quite familiar to you Similar to something else we've discussed ccip read if we treat the whole of enus as a massive off-chain distributed database We can have a gateway that fetches dns data Collects all the proofs necessary and submits it to the chain just like when you're resolving a name So then we can write a resolver for dns names that uses that gateway to resolve Names in enus entirely using data stored in dns users can set dns records to configure their name And they will resolve any of their enus is supported with zero on-chain transactions necessary Claiming on chain may still be useful in some cases. For example, if you need granular control over the subdomains But for most users, it'll be possible to claim your dns name just by setting some text records We're working on this right now The dns set oracle changes are done and we're working on implementing fixes from an audit before we roll it out We hope you have it ready to go before the end of the year There's been a lot more going on with enus, but compressing four years down into 25 minutes Naturally means I have to leave some things out Just one more thing the DAO is nearly a year old, but still in its infancy We have a lot of a lot to learn and a lot to do and we need your expertise Please take a look at our governance page Reach out to enus domains on twitter see how you can get involved and help us build a truly decentralized public good naming for web 3 And that's all I have for you. Thank you very much awesome Do we have any questions for nick? Please raise your hand. We'll get you a mic There's a lot of things that we talked about. We see a hand over there Keep your hands raised so we can find you and get the mic to you Hey, nick. Thanks a lot for the talk One thing I was thinking about uh, you should probably be able to use enus to uh, the problem is when you Use ui to uh to communicate with a page The metamask will generate you It will provide a transaction for you and basically You have no idea like if actually the ui Is the right ui and you if you are calling the contract you want to be calling and I guess you could un s it could be you You could un s for this for linking both the The domain and the smart contracts with the same enus and have metamask check it basically to provide A lot of attacks connected with the ui Yes spoofing. Yeah, definitely a better user insight into transactions as I think probably the major adoption barrier and and phishing and so forth issue in web 3 today um Naming contracts with enus names is one big step towards making that a bit better and in fact the latest contract updates We're pushing out uh make it easier for contracts to get enus primary names um I am also the author of a proposal with richard more on how to better provide insight into transactions, which is also very relevant there Yeah, and could you make uh Basically the the calls from the other side meaning Metamask could somehow check with dns like what what this contract Is what enus is this contract associated with? Yes, uh and further you could uh put authorized frontends in your enus record so that will warn you If you're making a transaction to say uniswap from a scammy site Which is an excellent idea. Yeah, perfect. Perfect. Thanks. Cool. Thank you very much Awesome. We have one last question here set the front row and uh then we'll be at time Uh, hi I was wondering if you could kind of give us a state of the union on efforts to resolve pages via browsers and at the os level Sure So at the os level is depending on you look at it tricky or easy You can run your own dns resolver in which case you personally get to resolve all enus names Getting it rolled out to everybody is a very steep hill to climb I think we're going to have more success getting this integration to browsers such as brave and opera which already support it Rather than integrated directly with os's On the other hand, there are efforts around dot eith talking to ethiopia about whether they would be willing to relinquish that This is all very nascent. However, so there's absolutely there's nothing Concrete for that right now the shorter term solution is as said browsers. I think Awesome. That's all the time we have please give nick a big round of applause Thank you


Welcome to this unit on Educational Video, where we will first define types of educational video and then associate these video types with content demands. As usual, you should start with a virtual session, where we first look at the parameters that help to define educational video types, then at the equipment you need for video production and last but not least at some selected aspects of video production. Please use the question sheet as guidance if you don't know how to proceed. This unit's mastery worksheet is an input task about educational video, but it should not be problematic after the virtual session. Well, and in this unit's practical, we want you to do some group work and search for specific video types and associate topics with them, but also define the main steps of video development. Try on your own first. The model suggestions will be given when the next unit comes into focus. So this unit involves a number of hopefully interesting aspects, and we made it as accessible for you as possible.