 You don't hear me? I'm still very quiet. OK, this is better. OK, I think they help with that. OK, thanks, everyone. I'm Danny Vrandicic. I'm head of special projects at the Wikimedia Foundation. I'm still trying to figure out what it means. One thing that I'm working on, the Wikifunctions and abstract Wikipedia project. With me today is James Forrester. Do you want to introduce yourself? Hello, everyone. I'm James Forrester. I'm working also on abstract Wikipedia and Wikifunctions. I'm tech lead for that team. I've been at the Foundation for 11 years. And originally, I was a community member starting in 2002. So that's been fun. And yeah, here to talk about Wikifunctions. Also, James is one of the few people who has been to every single Wikimedia before. So if you have seen him before in one of those. Also here is Nick Wilson over there. He's having a microphone for your questions later on. And he's working also on the abstract Wikipedia team in the role of the community relations specialist. Thanks, Nick. So we're here today to introduce Wikifunctions. Wikifunctions is live since two weeks, I think, approximately, more or less. And we are slowly starting it up and rolling out, giving more and more rights to folks, to edit it, to read it, and so on. And the reason why we're so slow is because it has a few unique features that haven't been before around in Wikimedia projects. So we're trying to figure out how exactly they work, how exactly to make them work in a safe way, in a way that is efficient and that will run. So we're starting up and we're in a very excited point. So, the green one, no, this one? Oh, perfect. So, and you can go to Wikifunctions.org right now and take a look. We're going to take a demo after the short presentation. So the plan for today is I give a short presentation of introducing Wikifunctions after that James will give us a demo of the site. And then we'll all invite you to, for your questions and discussions about the topic. So we will have plenty of time for discussions. The goal is that we don't take even up in half an hour or something, but rather that we are shorter than that. So as you know, we have a lot of different communities. There were 770 different Wikimedia projects out there. All the different language Wikipedia's, Wikisauces in different languages, Wiktionaries in different languages and so on and so on. Some of those projects are really big, like English Wikipedia, for example, others are smaller. The Malai Wikipedia has about 680 monthly contributors for more than 300 million speakers. That's quite a task. Hausa has more than 70 million speakers, but only 60 million active contributors. And those small communities sometimes have to deal with working with a lot for data. So I'm a bit focusing on the Malai Wikipedia because we're here in Singapore, so this is kind of close by. This is the list of modules that we have in the Malai Wikipedia. And you will see that a lot of those are actually English names, and not in Malai, even though they could be in Malai, but the thing is that a lot of them have been copied from the English Wikipedia and just taken over and even leaving the name the same. So also if you look into, for example, one of the special of those modules, we see that a lot of them have a lot of content in English and also output in English, so they're not particularly well localized. The module was copied over from the English Wikipedia in 2017 and then partially localized. So some of the words have been translated for example, for years, months and so on, given in Malai, but for not the whole thing. But other things like, for example, the documentation has never been copied over from the English Wikipedia to the Malai Wikipedia, so we have the documentation for that is still in the English Wikipedia. If you want to go and check out how to do specific things, you have to go to the English Wikipedia and read it up in English for the documentation in order to figure out how to use this module in the Malai Wikipedia. And also the changes have happened on the English Wikipedia as it's done and there have been like a dozen improvements or so to the module that have not been translated. They have been not copied over to the Malai Wikipedia also because it would be actually difficult because as you have seen, part of it has been changed for the translation and so on. So some of the stuff that is happening on the module on the English Wikipedia is only available to the English Wikipedia and not to the Malai Wikipedia. There might be mistakes and errors that have not been corrected and so on, improvements which have been taken over and the same is true for the other 83 languages that have copied this module. And it's particularly true for the other 690 projects that don't have access to this module. So we have a lot of very different states of the functionality that the module H provides with the different Wikipedia's and very different states where they're available and a lot of splintered work and a lot of copy work and it's not clear how much of this is actually available in different language Wikipedia's. The partially translated, partially under different names, they have different parameters under such as the parameters are renamed. And so it's hard to actually take, for example, a call to this module from one Wikipedia and bring it to another Wikipedia and translate this over to the different one. And this is what we want to improve with Vicky Functions. Vicky Function really is aiming to provide a centralized place where we can work on the functionality that is currently provided by Lua modules and make it available to all the Wikimedia projects at once. We have one place where we can improve the functions, we can work on it together. Similar to what Vicky Data did for the Infobox data, we want to provide the functionality of what Lua models provide today in one centralized place through Vicky Functions so that all the Wikipedias can enjoy this improvements and that everyone can contribute in improving them at the same time. So we would have one function H with clearly defined and documented parameters that can be called in from all of the Wikipedias and from all the other projects as well. It can be Vicky Voyage, it can be Vicky Source and so all of them can use the same thing. And they know that they have the up-to-date implementation of those functions available and the documentation would be available in their language and they don't have to go to the English Wikipedia to read it and everything. Yeah, that's Vicky Functions. This is the pages that it's currently now and we are looking forward to have you all join in and to make this function available. So we're not at the point here that actually the Wikimedia approaches can use Vicky Functions calls. So this is something that we want to work on basically from now on and see how quickly we can implement that so that the projects can actually use Vicky Functions calls. For now, we are starting to work on this catalog of functions that we're going to make is available. And then hopefully in some near future you can actually make the calls, the functions from your Wikimedia project and use it from there. So how does this look like in Vicky Functions? This is a very simple function, this is the not function. The not function takes a boolean value and gives you the opposite of that. So it can if you enter not true, it should return your false. If you say not false, it should return your true. Nothing surprising here. So as I said, when you run it on true, it gives you false and you run it on false, gives you true. So this is a look under the hood for the details of the function. We see that we have two tests, the negation of true should be false as we just said and we have several implementations here for this function and all of them pass the three tests. The two tests that we have, the implementations is one in JavaScript, one in Python, one in something that calls composition. The one in Python is just using the Python not, this is nothing surprising here. And the one in JavaScript looks that, if you don't know Python or JavaScript, you don't actually have to care how exactly they implemented, you can still use the whole thing. Composition is not the programming language you have heard before, it's just, it means that we're composing the functionality of a certain function through functions that are already available in the wiki. So in this case, for example, they're saying overusing the if function and we take the argument, if the argument that you entered is true, then the return will be false, else it's true, nothing surprising here. What is interesting here is that since all of these are objects inside of wiki function, they have a set ID similar to what wiki data means of the QIDs, and they have labels for those things. So things like function call, things like the if function, false and true, they're all objects in wiki functions have labels, which means that what we see here is just the English view on this page, on the composition page. We can have the same thing, for example, in Polish, and it's completely translated into Polish, so we have to actually the function call in Polish here, is saying yes Lee, we have to argument, and if it's true, then it gives you false and not always better. So you can have, you can read those compositions in your language, whatever your language is, and you can also actually contribute in that language, just like with wiki data. So you don't have to be a programmer, you don't have to learn English first. You can just use this composition thing in order to get new functionality out of wiki functions and create it there. So that's wiki function. I think we are moving to the demo now, and thanks, and I give over to James. Hi everyone, so the first rule of tech is to never do a live demo, so I'm gonna do one anyway. So this is the front page of wikifunctions.org. I am currently logged in as me, but other than that, it's just a wiki. But if here I go to this page, this is the function join strings, this was by popular vote, the very first function that was created on wikifunctions. It may be more familiar to you if you're a programmer as the concatenate operation, but join strings is a much more familiar label. And we can actually look in here that it's got labels in English and a bunch of other languages, many of which I do not speak and will never speak, sadly. So you can try it out right there. Anyone can, in fact, if you're logged in. So I can do something like, let's write, hello wiki, oopsie, mania. And I can click run function and it thinks about it and it runs it and it says hello wiki, mania. Well, congratulations. So this is not the most impressive function ever and I would be really sad if that was the first function which was the impressive one. It should be basic and simple and just work. But this is actually a lie. If I click the details button here, which is very techie and boring and you probably don't want to press generally, you'll see that I actually calculated this 12 minutes ago because our function calls are cached. So if I change this to a second exclamation mark, I will get a result back as well, but it'll take half a second more. He says optimistically and now it's crashed. As I said, live demos. There's the second exclamation mark and there that ran eight seconds ago, not 16 minutes ago. So there are a bunch of functions that have already been created by the community. We are handing out rights so that people can do that in a slow and graduated manner, but we'd love for you to come to us and we can give you those rights right now. But you can go into the details operation here and you can see that there are multiple different implementations written in different languages that work in different ways and some of them have been approved by the community. These are connected ones and some of them have not yet been approved. So they're not connected. So when you run, when I click run that function for me, the system will run the one that's first in this list and they're reordered based on speed. So you can write a really silly slow operation to do this, but it, famous last words, it won't take down production because we'll just ignore it. Famous last words. But the idea is that this gives a lot of flexibility. So you as a user, who doesn't know any technology, feels like this could be really cool, can be like, hey, these sets of tests don't cover a test case which I have in my language and when you put these two strings together, actually the output is wrong as it's currently written. I would like it to also put these two strings together and not collapse the glyph into a single glyph, but have it as two separate glyphs or I'd like it collapsed, whatever that need is. And so you can propose a new test case and as a community, the working functions community can go like, no, this is operating as desired, we don't think that's how it should work or they can go, you're right, this is how it should work and none of our current code actually passes your new test. So let's go write some tweaked implementations that do pass all the existing tests that everyone expects and the new tests. And so the idea is not that there is a one standard function that's written and is true for all time, but those can develop over time and for different languages, different communities and different needs and maybe this function will eventually turn into a gargantuan thing that supports two trillion different character sets or whatever or maybe it won't and that's not for me to say, I'm just an engineer. So there's a small catalog of functions you can look at right now that have been curated by our community. The logic operators section is quite empty. There's one of them, boolean operations, string operations. There are, there is a lot of work we need to do to support things that aren't strings and aren't boolean operations. Some of those are very simple, like we should put numbers and then you go like, hang on, what do you mean by a number? What is it signed? Is it unsigned? Is it a float or is it an integer? What scale of number? And as soon as you say, oh, it should be in a number that supports up to 10 trillion, you're like, well, that means we can't implement it in JavaScript using basic maths, we have to support something else. And so those kinds of concerns means we're gonna have that as a big community discussion as to what types to support because those are kind of pretty fundamental decisions that will shape what use things are for on Wikipedia or wherever. There are bigger types out there that we also want to support like the concept of a string of lexemes from Wikidata that is rendered down into some text that can be translated into different contexts. The fact of fetching an entity from Wikidata itself as well. All of these things are in the magical future and are definitely not a thing for us as the team to decide without involving a lot of community discussion. So if those sound like cool discussions, the Wiki functions or Wiki is there for you to have a starting conversation there. But yeah, there are some things here that I wouldn't recommend you try and do. Like, is this an Esperanto adjective operating on a string, not a Esperanto typed language input? But it's really great to see people experimenting and try things out and things will change over time. Anyway, I've demoed a lot and talked a lot and I want to hear from you instead of me. Just one more second. Can you go back to the slides? We have a few more there. So here are a few examples besides those that James has shown next slide. All right, sorry. So this one is for example, it takes encodes a word in the NATO phonetic alphabet. So we enter here, for example, Wiki and we get whiskey in the Akilo India bag. I like this one. This is the favorite function of my daughter. So she loves playing with this one round. It takes a string and reverses it so she can actually make the system say things that she wouldn't say herself. So you get, for example, the input depots and when you turn it around the function we get then the result, which she's very proud of making the computer say that. Nine years old. I like this function. I have no idea what it actually means. It takes the final option and it reverses it so it turns, for example, YAPRAC into YAPRAC, I can't even pronounce those things. But I really love that community is already starting with those linguistically informed functions because the eventual goal of this is absolute Wikipedia. We want to create whole Wikipedia articles with these functions. So having these things start to work on morphology, on words and other natural language generation things is really really cool. And as I said, we want to eventually get to the space where we can then, for example, enter inputs and create whole sentences like Berlin is the largest city in Germany. Also then available in different languages and so on and have those things built together with the Wikipedia articles for abstract Wikipedia. And this is then the ultimate goal for Viki functions to support this kind of abstract Wikipedia natural language generation. So we hope that Viki functions will go beyond that goal. Just like Viki data, for example, had the goal of supporting the Viki media projects primarily, but has gone well beyond that goal by today. So we hope that Viki functions will have a similar trajectory. Okay, so as James has said, it's time for you to ask questions, to make comments. We're here to get into a conversation with you. So does anyone have questions? Nick? Hi, it was quite amusing to see a new way to introduce Viki functions. I had never seen it described as the centralized location for modules, even though I follow the community of it. And it's a quite intuitive way to look at it. My question is related to that. Similar to how Viki data came and took over the inter-Viki links, they didn't completely go away. I think we can still make them, but pretty much all of them have moved to Viki data. Is this a goal for Viki functions to import all the modules? Is it desirable? And if so, would the modules extension, or I don't know if it's part of media Viki proper or extension, but if it is extension, would it be disabled or would it continue to be there? So what is the plan regarding this? We do not plan to replace the current extension. I always say that we are planning to provide a way to centralize some of the functionality that modules are currently providing. But for example, we don't even support Lua right now. And this was half intentional because we didn't want to go immediately, like just people trying to copy and paste the things. Viki functions and the current Lua models work differently enough that the transition won't be completely straightforward. So this is something that is a huge social process as well. So I hope that Viki functions can provide a lot of that functionality, but it is not designed as a one-to-one replacement and to provide all the functionalities that the current Lua model does. For example, the current Lua model has a lot of access to the internals of the given Viki installation. It can look up like data inside of it, it can look like does it have this page and so on. These are all things that we don't provide right now and maybe we'll never provide. We'll see how far we get there. There are some functionalities that will be straightforward to take and implement inside of Viki functions, others which won't last. And it's not designed to be a replacement for that. I do think that it will be for a while before we see which space exactly is being filled by Viki functions and what is left, what is the space that is then makes still sense for the Lua models. If at some point we discover, well, we only need like two or three more features and we can simplify the whole thing, I'd be happy to go that way, but this is not our plan and not our goal, definitely. So currently it is meant to be additive and not to, it's really not planned as a replacement for the current system just because there's so many things which the Lua models support and have since they've been introduced like 10 or 12 years ago that we're not going to support for quite a while. Yeah, there's a question online from satdeep.gill. Is it possible to solve the issue of multiple templates across Viki media projects using Viki functions in other words, can this become the core infrastructure for global templates? So the first thing I'd say is templates. So when Denny was just talking about replacing Lua, I cast my mind back to when templates were added to MediaWiki, which was a new feature at some point and a bunch of users were like, I don't like this. I don't like centralized control over my article. I'm not going to allow templates on my article and nowadays community members change their mind and what people expect changes as well. How templates have developed over the years has turned into a really complex ecosystem of different things you do with templates. So sometimes people use templates like code and then Viki functions is probably a pretty good replacement for those. But a lot of times people use templates to group things together under a category tree on that particular wiki. Those categories generally aren't shared across different wikis because of different languages but also different community decisions about how to group things together, how to build that category set. Other templates are used for styling which is very community specific and in fact not even across a whole wiki. You just have to look at the 400 flavors of what an info box looks like just on the English Wikipedia, let alone other wikis to think that it would be really hard to say this is a single template that will apply everywhere. So that's not where we're going right now. That's not to say we couldn't do that with wiki functions. Right now the output format of a function that we're building is for plain text but it could also put out an HTML DOM element or an interactive widget which you can control or a dynamic graph or a video stream. Like there's no particular limit on wiki functions except I'd have to build it so let's do one thing at a time. But I don't think we're likely to replace all uses of templates in any short term, next five year horizon. So if people want to do global templates to do things like sharing how an info box looks, how to style references, then that's probably something to look for elsewhere and not on wiki functions. If we would have started Wikipedia from fresh and we would think of the ways that we need wiki data, here comments, we have a multi-media repository here, we have a functions repository there. We would probably make different choices than we have now but we can't ignore the fact that we have 23 years of history and the way the templates are being used is extremely diverse as James has pointed out. And I think any plan to replace all uses of templates is would be extremely, extremely complicated. So we're really, really, really not planning to do that. We're not taking those things away. In the future, we hopefully will manage to streamline a little bit the projects and get to a place where we can see how this future will shape out but it is a social endeavor mostly. The technological side is much, much simpler than actually getting like 770 communities to get or to in order to decide, okay, this is the things that we wanted to actually centralize and build and so on. So I'm being extra careful here. For wiki data, the first step was like getting the sightlings out and centralizing those and there was minimal resistance to that which I'm still thankful for. But even the step of like putting a lot of the info box data into wiki data and have this now available in all the wikis is still far away from that. Like the English Wikipedia can't even decide on getting the short descriptions from wiki data because, you know, oh, this is outside of our project. We're not doing that. We can't work together with the global community to improve those things. So the English Wikipedia will intentionally not do that. And I don't expect the English Wikipedia, for example, to decide that they want to centralize their functions inside of wiki functions and collaborate with the rest of the world on improving those things. But rather, they probably want to keep control of those things as well. I would love them to join us and we all work together on a catalog of functions. It's just not exactly my expectations on this one. Should we go with ourselves? Nick. Quick question with a view to integrating developers. So the movement has quite a lot of developers who can code in one of the two supported languages, which are Python and JavaScript. But I think most of them, if they, with a view to being of service to abstract Wikipedia, rather than implementing a sorting function or something, don't quite know what the next step would be. Like, I'm ready to code. I'm ready to create things for my exotic language like Hebrew. But what do I need to do to, you know, go one step further towards abstract Wikipedia? So I'm asking what sort of path or guide or tutorial or demo do you have to encourage people to begin testing the boundaries and giving you that exotic language edge cases, you know, that could help? Being a creation, I always love it when people who have, like, doubled the number of speakers speak of their languages, exotic. So. Which is not exotic? No. You have a really popular book that's very widely translated. This is a great question. And we do plan to push towards this direction of natural language generation figure out. I got the same request actually from the Dagbani community here as well. Like, what are now the functions? Like, we've been working on the themes in Wikidata. What is the next step for us to work on things? So, unfortunately, we're not exactly there yet. So one important thing that is missing is actually the ability to access Wikidata from Wikifunction. We don't have that yet. And without that, for example, there's no way that we can actually support irregular forms. Because I don't want people to start re-implementing irregular forms and wiki functions if we have them already in Wikidata and we could just look them up. And then forms, or? Yeah. Like what, which German verbs are male and female, which are neutral. What are the irregular forms of to be in all these different languages and so on. So we don't want to replicate that knowledge that we already have in Wikidata in Wikifunction. So this is one thing that we need to enable. There are certain sets of morphological functions, of making sentences and so on that already could be started to work on. And we will try to create those paths in the coming weeks and months and so on and invite the community to work on those things. But yeah, we have those two big technological things that we need to work on. One is being able to access Wikidata and the other one then eventually being able to be called from the Wikipedias and the other Wikimedia projects. James, do you want to talk a little bit on this whole mess? Yeah. So this is actually quite complicated. So we've talked previously about the Lua systems, Grapanto. This is a pretty powerful system that people have adopted very widely across Wikis because it replaced using templates and people would write more and more and more complicated templates and eventually MediaWiki would just say, not too many templates, I am not going to render your page for you. So the pages were slow and there is a hard limit of, I think it's 10,000 template calls and you would just reach 10,000 and then everything after that bit of the page would just be random, you know, Wikitex that people would not understand. The idea with Grapanto was to make that lots faster but it didn't actually change that time-out behavior. You still had to do everything within I think it's 50 milliseconds or the call gets killed. For Wikifunctions, we want to have a lot more flexibility about your function call. So maybe, I mean, like let's not do this, but maybe you're doing a SIVA, Aristotheny's prime number calculator in multiple threads and it's gonna take five minutes to return. Maybe that currently would get killed by our system but maybe as a community evolves that becomes a real need, maybe not that particular need, but something like that. And so we want to not make decisions right now that make the community unable to implement important things but that means that Wikifunctions potentially, the function calls are very expensive, very slow and aren't necessarily gonna be ready the moment you press publish. Well, that's a real problem for MediaWiki because MediaWiki's entire infrastructure is based around the concept that when you press the publish button within half a second, 10th of a second, the Wikitext is available and the HTML is available and they're the same thing and we're gonna have to break that connection and change how MediaWiki exports results and how things consume it. And this has a conceptually large but programmatically small changes needed in pretty much every piece of software that's ever touching MediaWiki, every extension, every client, every bot. And so if we're going to be doing this change, it's a big serious decision and we've been talking about this through the technical decision forum and on Wiki for like two years now and we have not yet finally committed to yes, we're shipping it, but if you look up asynchronous content fragments, cool name, then you can see that. The idea from our perspective very selfishly in the abstract Wikipedia team is supporting Wikifunctions, supporting abstract Wikipedia, but actually looking at that technology concept, we would probably want to also extend it to a lot of other places like Scrabunto, so maybe we could extend that 50 millisecond cap to a larger number like the template renderer. So instead of 10,000 templates, we could actually add more like possibly the video rendering which currently shows you a red link and then magically doesn't show you a red link except if you're logged out and there are a lot of other little bits of the MediaWiki set up right now that are not very satisfactory and we might change. But as I said, this is a big conceptual change to how MediaWiki's publication flow actually happens. And so I don't wanna make any promises of, oh yeah, next week it'll be fine. Who knows? Maybe it'll be easy, but a lot of that is discussions with other technical teams and technical volunteers and I don't want to presume, frankly, the outcome of those conversations let alone the engineering outcome at the end of that. Hello, I'm user name Jiku from Romania, Nukipedia. I'm curious about the license, licensing of the code and attribution eventually. If you, and if you can actually select a license for your code just like you do with materials on commons. And on the same page, can it be possible to import code from other repositories that have an open license? So no, you cannot select the license or have different licenses for different piece of code. It is all... CC zero. The code is in the BSD. Sorry, the code is MIT licensed. So whatever it has to be. BSD three clause, sorry, to be very specific. So there was a community discussion that decided on the license for the code and it came up with BSD three. So you cannot choose and have different licenses because you didn't want to get into this mess. Regarding can we have external libraries that are being used inside of it? We have completely decided on how this would work. For example, the people working on natural language generation would really like to have access to things like NLTK or other libraries. And we have to figure it out. It doesn't have to conform to it. It doesn't have to be the same license if it's like completely on the server side and basically hidden behind the user interface. So we could have, for example, a Python back end that has access to NLTK and you can just import it and use it there. So this would be one thing. This could be possible to make it available. And then it doesn't really matter what the licenses is there unless it's not viral and we have to figure out how to, in that case, but this has no effect on the code inside of Vicky Functions, hopefully. If it does, we need to figure it out. But basically what's happening on the back end and what is available in the code in the front doesn't have to be the same thing, I think. Just to correct myself, I thought wrongly. BSD3 clause was actually the losing choice. The community went with Apache 2 as the license. So it's a slightly different license which includes software patent release and things like that. Sorry. No, no, okay. For a practical question, how do you call this for a Wikipedia? Well, not yet. You can't do it yet. And when? That's exactly what James was just talking about. We need to figure out how do the asynchronous conduct fragments, how to implement that. The rough idea right now, but basically we'll have a designer go through this and figure it out. So we don't really know what the answer is to that yet. We have a few requirements on that. For example, we want to make it possible that you can just copy and paste the same function call that you see in the English Wikipedia over to the Basque Wikipedia and get the results there just being adapted to your language. So basically that we have an implicit parameter, for example, for the language that it then uses in the function generation and that you get the respective. This is our wish list right now. We don't know yet how to get there. We have a strawman proposal, but really I don't want to constrain it too much. Our designer will go through it and we'll see what kind of results we get there. And also it might be very different from how it's represented in the wiki text where we might have actually raw set IDs, for example, and how it will be represented in things like visual editor where we might have actually just a nice user interface and so on. Because honestly, I don't want to scare people away with that idea. So, but these are all questions that we still have to answer and we're very happy with input on those things. But I think everyone understands that we don't want to show ZIDs to users too much. Just like with wiki data, we try to usually keep out QIDs out of the user interface, but there's sometimes are in the wiki text. And for example, the templates that are pointing to papers actually just using QIDs there, but it doesn't mean that they're exposed to the users. Hi, Philip. James, I believe you said in one of the previous wikimani is that you are working on and trying to find solutions regarding operational stuff. So like, yeah, quote unquote, making sure that there's no abuse, making sure that the system is performant and that when the time comes, a process gets killed, et cetera. So what have been the strides in the past year or two? I don't recall when you promised that or said that. So just a broad overview of how is it going on? So the first thing I'll say is that I am absolutely definitely sure that right now there are security vulnerabilities in my system because every system has security vulnerabilities. If you think you have none, it's either encased in concrete often at the bottom of the ocean or you haven't discovered them yet or you're lying to yourself. That said, we have kind of tried to build a model that has several layers of defense in depth. Standard security modeling is about never let the user get access to a system. If they do get access, don't let them do anything. And the entire point of wiki functions is as a colleague called it, remote code execution as a service, which is kind of going directly against general security principles. And so that poses a lot of big challenges, but these are not challenges that no one in the world has as well. On a very technical sense, we are essentially running a Lambda service in the same way that Google, Amazon, et cetera run. Ours is very different in terms of why we're running it and for whom we're running it. And we don't get to bill people for running it. And consequently, we don't have the credit card company to call up to say, this person really abused our system. Can you please give us their number so we can send lawyers after them or something? So there are lots of things we're having to think about in terms of providing timeout, providing levels of abstraction. As Denny said, we are slowly rolling out the permissions to actually create functions. And that has involved people writing functions that on reflection maybe they shouldn't have written and thus disabling them, things like, if you give me a string of input, I will just randomly execute it, pretending it's JavaScript. I'm like, no, that's not okay. Whereas, or give me a string and a regex and I will run the regex on your code, also probably not okay. Maybe something we would want to support long-term, but right now it's a thing we're nervous about. There's like lots of ongoing conversations and lots of different strategies. A big strategy that is the very standard familiar Wikimedia strategy for resource exhaustion is caching. We cache everything, we cache it a lot, we cache it multiple times at multiple levels. And essentially, that might fix a lot of problems, but it also might hide a lot of problems that we really do need to solve. Because if I cast forward to a magical future where we've got pulling data from Wikidata and we've got pushing function calls into Wikimedia articles, and then you want to update a Wikidata item to say that someone has died, right? And so you want to make that edit on Wikidata and you want that to feed through into the calls and feed through into the articles. And so the fact that, hey, our service is cached a lot, doesn't help very much. If it takes 20 minutes for that edit on Wikidata end up on the French Wikipedia, that should be within a few seconds. That's what users will expect. And so we need to make sure that we're building systems actually meet the user need, not just I can write a scientific paper that claims that my decisions are fine, right? The purpose of technology is to serve not to be the technology, right? And so if that means we're gonna have to compromise on ways of doing things in some cases, then so be it. Right now we're talking about using JavaScript and Python as our two example languages. Originally we're gonna ship with just one, and I pointed out that if we wanted to ship with multiple languages in the long term, starting to ship with just one means we'll always only have just one. Scribonto technically is a multi-language system, but no one's ever added anything other than Lua to it. And actually at this point it is so concreted in that it would be really hard to add a second one. And so that's why we shipped with two. Maybe, maybe we'll support 20, maybe six, something in the future. What those are or why we have them might change over time. We might do dynamic recompilation of things into a web assembler or something scary. And that might speed things up, but also make it harder to reason about the system. So right now we're at a pretty simple level. All our stuff is obviously open source. You can go look at my code and tell me I'm an idiot. You're probably right. And I'd really love feedback or thoughts anybody has if you want to get involved. I'd be glad to talk about it. But where we go in the future is gonna be driven by the users, what we're building, who we're building that for. And so I don't really want to kind of make a decision now or even a promise now because that may not hold true. I wanted to disagree on two points quickly that James said first, he's not an idiot. And second, I'm not exactly sure that we really need to provide an update if something changes on wiki data immediately to the wikipedia within seconds. Sure it would be desirable, but one of the things that I did in preparation for the whole episode wikipedia program is to try to check how quickly does right now knowledge propagate between the wikipedia and for example the mayor changes of a city or something like this. And we have places that like, where languages take up to two or three years to update if they update ever on those things. So you know, something that takes a day or two is still better than that, right? And it would be great if, for example, it doesn't have to be automatic, that it always propagates within seconds. It can also be something like, well for this wikipedia I want now something like action purge or whatever, like kill the cashers and try to recompile it and it will take a little bit and it can be done in a few seconds. But in other cases it might take like a day or two until it is there. It's still faster than our current methodology which is basically the baseline that I'm taking here. But again, we are discussing on those things. We will discuss it also with the community and see what is actually acceptable on those things and so on. We will have to find something that works with the infrastructure and that works with the community. But not all of these things are decided yet. We're going to have ongoing discussions over the next few years with all of you. So Nick, this gentleman is having his end up for a while. Sorry, Leila. Hi, so if I get it correctly with the license that we have for wiki functions and the code for JavaScript and Python, there would be no ownership for the implementations, et cetera, right? I cannot say this is my implementation of this function or something like that. And so this is a multi-layered question because this is wiki functions. Can other people edit my implementation because different people have different approach to how to solve something. So if they do that, I don't necessarily agree with their implementation. What would happen? Or would they have to create other implementation like multiple JavaScript implementations and which one is better and which one is more precise, et cetera? Thank you. So on ownership, so our model is much more like the English Wikipedia and I think most wikipedia and wikis, which is we're against ownership of objects because community members leave and the objects will stay around. And so it's important that those are owned across the community. So there aren't going to be like, this is Bob's implementation and only Bob is allowed to edit it. Honestly though, that's really not for me to say that is a community decision and if the wiki functions community decides that they want to have named individuals and this is Bob's implementation and as a community function, people expect only Bob to edit it then obviously that is for the wiki functions community to decide and they may change their mind as well. From a very practical point of view though, once a function is approved an implementation is up there so that you can run it as a regular user. It goes to a higher security level because at that point, if I then change that implementation, I potentially break all the users who are currently relying on that function. So that doesn't mean you can't do it but we have different editing rights added in the system. The base level is a regular user who can create functions, create implementations. This is not live yet. That's how it will be. The next level up is functioneer who can approve those changes. They can say, yep, I agree. This is a good implementation. It passes these tests. I can add a new test case and I say, yep, this test case is a good test case. I can also remove them and say, doesn't work anymore. And then there's a super level called a function maintainer and that has the ability to actually edit an implementation that is currently live. That is gonna be a very big, scary, risky thing because it's possible for you to return false rather than true in your code when you make a change and that could instantly cascade out to every Wikipedia article all at once and you break every template. So that's a big thing that we would probably want as a community to think very carefully about how that would work. Maybe instead you should authorize the implementation first, make the changes, agree the new test suite and then reapprove it or maybe you create a new function and get people to switch over whatever that is. Again, that is a community process that doesn't exist yet and I don't want to like presume where that would go. Also, another thing is that a function can have multiple implementations in the same programming language. So you can have potentially several different algorithms implementing the same function. As James was showing earlier for the concatenate for the joint strings functions, we actually have three implementations in JavaScript and they all three can be approved and the system will basically look at how is it running against the use cases, how much resources does it cost and then basically automatically decide. Actually, the community cannot really decide which of the implementations to run. They should already, every approved implementation should be fine and the system should be deciding based on the resources that we currently have, this is the best implementation to run. Yeah, so right now we're making a very blunt choice, which is averaged across the test suites which is the fastest implementation, but that ignores potentially pathological cases that aren't currently in the test suites. It ignores what resources are available right now. We're gonna improve that, that's definitely not long term, that's just where we got to to ship. And one thing we might end up having is different implementations get run depending on the inputs. So if you ask for the English plural form of this, then we have a function that's really fast for English because it's hard coded in, but for every other language it's slow because it has to fetch it from Wikidata. And so we'll call you, if this function, if it's English, but if it's Hebrew or a complex language, then we'll call a different thing that has a lookup table that means it's slightly slower overall but really fast compared to the first function. And so it's not like there's a one and done decision that might be a dynamic impact on the system. And this is vaporware, all code doesn't exist until it's live in production and it doesn't exist, so I don't know what it will do but that's the kind of area we're thinking about. But I love also, for example, this is a beautiful place where I hope that external researchers or groups, for example, in the programming languages community will actually pick this up and see, this is a challenge where you can put a PhD thesis into it and someone else will go and figure it out and I'd be happy to just use those results. And for example, the Wikifunctions will provide a lot of, just like Wikidata will provide a lot of places where people can contribute also as a third party and which we'll be happy to integrate because honestly, no matter how big the team is, we can't do everything. Leila from Wikimedia Foundation Research Team, congratulations on the milestone. So actually, Denny, I think you started touching on it. I wanted to ask, do you all have thoughts about whether something like Wikifunctions can engage people who are currently not engaged with the Wikimedia projects and help them become Wikimedians? Maybe they didn't consider it so far for a variety of reasons. Is there a particular group of people or groups of people that you think could join the community as a result of this project? Yes, yes, absolutely. So just like with Wikidata, I think that the researchers have shown that about half of the people who are active in Wikidata have not previously been Wikimedians and about half of them come from other Wikimedia projects. Just, I hope that we will have also an influx of new people who are interested in kind of functions. And this also sounds kind of limiting, right? I mean, people who are interested in functions. Actually, I think there's an interesting space that there are certain domains which are able to be functionized for people who don't necessarily regard themselves as having a computer science background or something like that. Just to give a few examples, but the problem with those examples is I never know which one actually will turn out, obviously. And there might be something completely different that I don't have a narrator at all. But for example, how is this called? Knitting, the knitting community, for example, has over the last few two decades or so, has developed an amazingly complex thing for notations and for checking whether certain knitting patterns can work and so on. Which would be beautiful to capture in something like wiki functions and which it could benefit from. In music, you can do a lot of things like transpose melodies, check for keys and so on which you could do in wiki functions. And there's so many places where you can use wiki functions. And then one of the advantages of wiki functions is that you don't necessarily need to be a programmer because a lot of these things can happen with, if we have to write base functions with compositions and bring them together. This is how we want to, for example, reach out to the natural language generation communities that they can actually work on morphological functions before necessarily being Python programmers or JavaScript programmers. That even if they just provide us with test cases, for example. This is something that then one community can create a test cases. Another community can actually then create the implementations against the test cases and so on. So the way that wiki functions is designed by the separation of the test cases and implementations hopefully supports, for example, that people with different skill sets and capabilities can work together on getting those things out. So and the whole idea with having the compositions be language independent also hopefully will reach out to people who currently are not programmers simply because they don't speak English. Benjamin Marco Hill who's also somewhere in the conference, for example, has shown in papers that the language barrier, the fact that most programming languages are based on English is actually a significant wall for people to contribute in code. So we put a lot of effort into the ability to create compositions, even if you don't speak English, that you can create compositions in Polish, as I've seen, that you can create compositions in Hebrew and so on and actually create those without you having to learn English, without having to learn JavaScript and so on. So there is potentially a big pool of people that we can hopefully activate for this project and get in. I obviously have no idea who we will actually get. We're getting close to the end. I want to show, I have to think here, sorry, we're still showing the slides. I also want to give a shout out to the amazing team that has been working on wiki functions and apps of Wikipedia, thanks to all of them that we are now getting to this point of actually launch. We also are hiring. We have our positions out there. You can talk to us about that if you're interested. And yeah, let's go back and keep those. So we still have five more minutes for more questions. We have a session tomorrow where we want to teach actually hands on how to work on wiki functions. And we also want to hand out the functioneer right to people who are here at the conference. So if you want to talk to us, we are happy to make you functioneers on the wiki so that you can actually contribute to the session tomorrow and that you can try out things and talk with us directly and involve us. So feel free to chat us up and talk about how wiki functions work and we're happy to give you the rights that you can immediately go ahead and try it out. So we had more questions here. So going back to the quick analogies that help grok the idea of wiki functions, one of the things I have been thinking in the beginning was kind of an open source world from alpha. But then I started realizing that that requires not just executing code, but understanding the input. So my question is right now there's a vision to output natural language, but is there some thought about consuming natural language as input so that things like all from alpha or the Google search answer boxes or even the smart assistants like Siri, et cetera, would be possible. Because I think this is one of the things that would make not so much the creation process, but at least the use of wiki functions much more accessible to a broader audience. Yeah, that's a brilliant question and I don't have the answers for that one yet. This is again one of the places where I hope that third parties can work with us and figure out those things. I would love to have a natural language interface to wiki functions and to wiki data and similar things. But we don't have current plans to attack us in the near term future. We're doing on other stuff. But if there are third parties out there listening on the live stream or here in the room, we would be very happy to talk to you and figure out how to work on those things. One of the medium term things we want to ship is for there to be an API you can use to call wiki functions. So right now, as I demonstrated, like you go to a website, you fill in some fields and you click go. Later, we're talking about using wiki text. We also want there to be an API and that could be embedded inside a tool on tool labs or something in an app, but a third party or in the middle of your dashboard in your car. Who knows, right? Like we'd have to think very carefully about what we're promising and who that's for, but certainly for internal usage, it might be that someone could prototype a natural language parsing question and answering system powered by wiki functions without us being the people to decide whether that is or is not a thing to build, but us maybe helping build that. A beautiful example is for example, when Thomas Berniceater and others have worked on natural language queries for wiki data and created systems like that. I think what was the system's name? Platypus, Platypus, right? Yeah, it was here, right? And those things should become much simpler given that the technology that we have today. And I would really like to see those things happen, not just for wiki functions, but also for wiki data actually to have user interfaces which are based on natural language queries and then translating them to wiki functions call or to Sparkle queries and similar things. I have one more short question. Do you prefer like long complex function or break it down to some more simpler functions where they can be combined or called? So I would say this is generally a community question not for us to decide. From a technical perspective, more smaller functions gives us more layers to cash at and also from a community perspective, the smaller functions may be more applicable in different cases as opposed to one big function. But really, I think that's a community decision to make and we will support the community to make the right decisions and technologically whatever we need to. One thing that I see there happening is that they actually have both. And for example, we have compositions which are then taking the next level of abstraction combining them because so people can, the composition can also often be something like a specification like to see, okay, this is actually what's happening underneath. This is how these things are working. You can read it in my language, which is great. But then we can also, for example, have an implementation in, I don't know, go or Rust, which is then like super fast but rather bigish and doing a lot of things. But it doesn't like call out to other things and maybe it runs faster and it needs less resources. And the fact that we have them both implementations and we can test them against each other and make sure that they're actually the same thing can have like, we have this slower specification here. We have those, the community has agreed both of them are fine. The backend can choose one of these. I'm doing here now paper dreams and vaporware, right? But in fact, we could have like both of them and they are supposed to be equivalent, which means that we can serve both use cases of having like an efficient fast implementation. And at the same time, something that a non-technical user can understand what's going on and break it down and so on. And we notice both are equivalent because we have the system doing those things. So I'm dreaming here, but this could be one way that we could have basically both of those layers. But again, as James said, it's really up to the community to decide over this. And we'll be joining this discussions. Okay, that's us at time. So thank you very much for coming everyone and we'll be around. Thank you so much.