Okay, so thank you everyone for joining.
We'll soon start the talk about crystal.
One week you have to rule them all with Ludovic and Manuel.
So I'm going to give you the mic.
Okay, we're good.
So hello everybody, welcome to this talk.
So we're going to talk a bit about the new project we have at Xwiki.
And so we're going to present the team first, who we are, the product vision,
what vision we have for this product.
And since it's a new product, it's not ready, so it's not something that's usable today.
It's something that we're going to build with a lot of energy.
And then we're going to show the design proposals that we have for the UI,
which is from our belief very important, then the technical architecture,
which is another part that we believe is very important.
And then the current status and the roadmap.
We call this project crystal because we want to both...
We want that it's both beautiful on one side,
but that it's also like the chemical structure,
like it has a very nice and very well-done architecture.
So first, who are we?
So I'm Ludwig Dubost, the CEO and founder of Xwiki.
We're going to talk about Xwiki just after.
Manuel. Manuel is the tech lead of Crystal.
He's going to talk to you about the architecture.
The project has also Vincent Massaud, our CTO, Thiago, our designer on this project.
And we have also the support of the whole Xwiki team on this project.
So Xwiki SIS is a company that is established in 2004.
For 20 years, we're working on Wikis.
So it's quite a long time.
We have friends in this endeavour of Wikis.
We believe Wikis are very important.
Hence our tagline knowledge is power.
We are a self-funded company.
And we have reached 4 million euros revenue.
We're also building the CripPad software.
We have done 50% growth in 2023.
We have 60 employees in France, Romania, but also Germany and anywhere.
As I said, we have two software, Xwiki, CripPad.
We engage in digital sovereignty.
We believe open source is really important for that.
And we have a business model to really try to fund the software.
We believe it's also very important to find a way to find open source software.
Open source software cannot be done with...
Microphone is not working.
Is it okay now?
Okay.
So I have to be careful.
It turns around.
So the product vision.
So first, there are lots of technological shifts that have happened in the latest years.
For example, JavaScript is getting more and more mature.
Like better development methodologies come in JavaScript.
We come from the Java world.
And so we're very keen to have great development methodology.
And for a long time, JavaScript was like a bit in every direction.
And now we see that it's also getting more organized with development tools.
It has better frameworks also for developing JavaScript applications.
Standards have evolved.
You also have web components, JavaScript modules that are working much better.
You have also technologies such as JSON-LD or SOLID that bring new capacity.
There are also new paradigms.
Paradigms, real time, is becoming something that any application should kind of have.
We believe offline is important also.
And that the technologies allow it.
We also see a convergence in the field of wikis.
Not only between wikis, so the features of wikis are getting similar.
Like there's a better understanding of what the features of a wiki is.
But also we see that there is a convergence between wikis, for example, or even drives.
They're getting closer.
So there are also questions about how they could be similar applications.
For example, we have always had attachments in wikis.
Maybe you could consider attachments or documents like their wiki documents.
So there are convergence there in this area.
We believe there is a model of future.
So Jitsi's founder, Emil, in last year, he mentioned at the end of his 20 years Jitsi talk
that in open source building on layers is going to be an approach that matters more.
And it enables tremendous innovation.
So if you look at Jitsi, you have a Jitsi library that makes the video conferencing module.
And you have the Jitsi application.
Like I really believe in this and open source can really reach all of its power
if you can do a lot of reuse of anything.
So you need lots of modularity.
We had reached a lot of modularity in xwiki with everything's components in xwiki and Java.
But now applications are way more client side.
And so you need the same level of modularity on the client side.
And we also need integrations between open source tools.
There was a talk about OpenDesk in which we are partners where we need to bring open source applications together
so that the whole suite of open source applications could replace Microsoft or proprietary applications.
And we need to be able to integrate tools much tighter.
And for this you need, again, the modularity.
We also got an opportunity to fund that work.
We have one with other companies as part of consortiums.
We have one actually three projects, but two of these projects include the work of Crystal
that we have included in the projects of building this new UI.
And so we had this opportunity to fund it so we're able to get money for that.
And so we have this big opportunity.
We also have the opportunity to have the collaboration of partners.
So actually the partners of this project, unfortunately they're not open source,
would be also users of that Crystal module for their application storing data in their own system.
We'll come to that when we talk about the vision for the product.
So what's the vision of the product?
It's actually one UI, one wiki UI, a modern one that brings all the features that you have in wikis today
and that can support multiple back ends.
So you would have an application that is web, desktop, mobile,
and this application would be extensible, very modular based,
but it would have a common data model behind that applications,
which support offline, real time, and then it would be able to connect to different systems in terms of back ends.
Of course it would be able to connect to Xwiki.
We built Xwiki and we wanted to connect to Xwiki and support all the features that Xwiki has,
even the most advanced one that we have in Xwiki.
But we also would want it to do a basic wiki based on a file system that you store locally on your computer.
We also would want it to work as a nice wiki with the next cloud back end using webdav or git.
And we also would want it to support a wiki storing data in an end-to-end encrypted system such as CripPad that we build ourselves also at Xwiki.
And this application, as a whole, where you can activate and deactivate modules,
you could decide that these features you don't want them, you can change modules,
you could replace modules in this modular application, would also be embeddable.
That means you could put it in the next cloud server and serve it from the next cloud server.
You can put it in the Xwiki server, serve it for the Xwiki server to access Xwiki data,
or you could put it in any other application.
That's the vision of the product, Crystal.
The key concept is that we want it to be a slick UI with modern editor and slash comments, multiple back ends, as I mentioned.
So, slick UI means it needs to be as good as what Notion does today in the world of wikis in terms of UIs,
or the Notion competitors that we see coming in.
So, we believe the Notion competitors are nice because they support a lot of nice UI features,
but they don't support the modularity that Crystal will have.
It's going to be offline in real time.
It's going to have accessibility by default, support web components, and also be sustainable.
There was a very nice talk before about sustainability of software, measuring the consumption of software.
We want to try to do that also with Crystal.
We want Crystal to be a UI that is built in a way that will consume less.
It's going to be available as web, desktop, later mobile.
It's going to be extensible and configurable, and it's going to be a strong editor.
So, I'm not going to go into details of what a strong editor is.
It's going to support markdown, but it's also going to support the Xwiki syntax,
but it's going to be state-of-the-art UI.
Lately in Xwiki, we implemented slash comments.
It's going to have slash comments in Crystal too.
It's going to also support structured data.
That's one of the big advantages of Xwiki that our customers and users have loved in Xwiki compared to other wikis.
We have a whole system around structured applications, structured data,
and we're going to support that in Crystal.
Some use cases, we wanted to be a UI for simple storage, markdown.
So, it should be a simple wiki.
The idea is that it can be a local note-taking app.
You use as an offline with a storage that is local, and that would be really interesting.
It's going to be a modernization for Xwiki because Xwiki has a UI that's quite old now.
We have done a lot of things with this UI, but we wanted to be the modernization of the wiki UI in Xwiki.
It's going to be embeddable, as I mentioned, and we wanted to be a wiki view on all your wikis
so that as an individual user, you would have multiple wikis in your Crystal UI.
You could even create a wiki of wikis, so you could create your own tree of pages,
and you could be navigating different pages in different wikis that you have in the back end and locally, of course.
It can be an end-to-end encrypted wiki for CripPad, which is a feature that we would love to have.
So, we can summarize that as a new wiki UI to rule them all.
The design proposal, I give it to Manuel.
Is it working?
We only share the results of work by Ciego, UX engineer, we hired a few months ago.
Since we have some experience with Xwiki, we are able to part from a blank state,
but using the experience we have already to redesign a more clean and modern UI for wiki.
That's one example, but we have some documentation online where you can find other wireframes.
Of course, everything is community-based, so you can come to the forum where we are openly discussing design ideas and contributions.
One important aspect we want to work on is, since we want Crystal to be unbedaible,
it can be with its own style. It needs to look like the application where it's integrated.
What we want to do is, as a developer, when you design a part of Crystal,
to design it with some abstract components, UI components,
by configuration to be able to say, I want to use shoelace for the actual visualization
without much code to say, OK, now, for this application, I want to use Vue.define on...
to make it easy for the developers to switch from one design system to another.
It can even be convenient, for instance, the French government has its own design system,
so if you want to have some knowledge base for the French government,
it should be by extension to define a new concrete design system and to use it for their own needs, for instance.
We can imagine some other use cases, like in Nextcloud, they have their own set of components,
and if you want to have Crystal inside Nextcloud, you want to have it look like Nextcloud
and be seamlessly integrated inside the ecosystem.
So, a few notes on our technical view for the future.
Starting Crystal was a very good opportunity to be able to try new things,
so I'm working for a few months into studying a lot of libraries that we can use for Crystal.
That's a snapshot of things we have settled down for now.
I went to the JavaScript room this morning,
and now I have like dozens of new technologies to check.
We have this page where all the choices we made are listed, and we maintain it over time.
And so, in terms of architecture, it's starting easily with two main components,
the web one on Electron, all the ones with Dash as the platform where the most work to do in the future
because they are the most challenging for integration of Crystal inside XWiki
because it's 20 years old project, so as you can expect, a lot of features to make us compatible with.
Reach editing is very challenging.
We need to choose a new technology for the editor which is compatible with offline editing with real-time editing,
so that's a lot of work ahead, but we have plenty for our next roadmap.
So, the key aspect we have in mind is that we want to preserve from what we already have in XWiki
and that we deem as important its accessibility and sustainability.
That comes with artifact size, of course, measuring performance,
making the Crystal locally usable, modular with inversion of control,
based on standard as much as we can, for instance JSON-LD web components,
to keep having documentation for users, for developers,
to have a broad idea of the artifacts we want to publish,
so the abstract design system library for others to develop design systems on top of Crystal,
a set of connectors to different sources, as we said,
and a JavaScript syntax formula to have offline editing with a rich experience,
a software development kit to be able to develop extensions,
and a set of components we're considering web components in particular
because that's independent from a particular framework,
which I believe is better for the future, a long-term future of the project.
So, on users, we have this electronic application for desktop not taking
as a replacement for the XWiki front-end.
So, I'll get back.
And so, the tricky part now is what's the status and where are we today?
So, the first thing is we have a prototype of the extensible architecture using IOC
and the version of control.
That's actually a very important part of the way we've designed the applications.
So, people coming from the Java world understand what components in Java are
and what inversion of control is, and this is actually something that is not used that much
in the JavaScript world.
It's used by frameworks, so ViewJS or AngularJS,
they're frameworks that are doing inversion of control,
but when it comes to JavaScript libraries, this is not something that is used that much.
So, the key feature that is really important for the extensibility and modularity,
if you want to be able to replace one piece of the system because you want to change the way it behaves,
you need to be able to replace any module for which you have defined an API.
And inversion of control is a key method to be able to do that.
In the prototype we did, we've been able to load dynamically a module by configuration
that is coming from the Internet.
So, in the configuration that you want this module instead of the other module,
and from a static build that has been built as a standard crystal delivery,
you can add an extension that will replace one of the modules of the system.
And this is key.
We have designed the architecture, the basic architecture of plugins,
skins, and user interface extension.
In X-Riki there is a great feature that is called Skin and UIX.
Skin is a way to replace the UI.
UIX is a way to add an item somewhere in the UI.
So, if you want to add a feature in the product by an extension, you need extension points.
UIX and X-Riki is the way we do it.
We have replicated these methods in the crystal prototype so that you can add things in the extension.
And we'll also replicate the fact that you can replace the skin.
So, in addition to what Manuel explained about the abstract design system,
which allows to reimplement the basic view and the basic components that we're using in the whole application,
we can also replace pieces of the user interface.
We have implemented X-Riki and Markdown renderers.
One difficulty was to bring a JavaScript renderer for X-Riki.
If we want to be compatible with X-Riki, we want Markdown to be a first-class citizen in crystal
because that's the standard today, but we also need to support our customers
that are using the X-Riki syntax in with X-Riki.
We've also done prototypes of client macros, rendering in ViewGS of a macro.
So, new macros.
We've done the choices of design system libraries.
The first one we want to spend time on, Shule's Vutify.
One thing we had in the previous slide that Manuel didn't say.
Shule is one of our performance tests.
Actually, twice as fast as Vutify, and Shule is a web component library.
We were quite impressed by that.
Vutify is a pure Vutify library.
Shule is a cross-platform library of components like supporting React or Angular, etc.
Really interesting work.
We have done design work.
We have a prototype UI for basic view.
We have first test of the editor UI with Markdown and TipTap, and we have the project infrastructure.
You can check the code at the link I gave, crystal on GitHub X-Riki contrib.
Basically, what we want to achieve in 2024, we want the first version for basic wikis.
You can browse your, you can actually take notes in Markdown with an electron system.
You can access a git on the other side.
You can access a basic X-Riki with not all the advanced features of X-Riki.
Maybe about 50% of X-Riki's current features.
By, during 2025, we will achieve 75% of X-Riki's feature, including structured data.
We want to bundle it in X-Riki by 2026.
We want to have also plugin repository.
We'll probably have that earlier, but we want to start having more plugins.
We want to also have done more plugin development and a Crip at release.
We probably want it as a default UI for X-Riki.
Also, if we have done our work properly.
That's it. You can look at our website, crystalx-wiki.org.
There is also very interesting information there for anybody that does a JavaScript application,
an advanced application.
We're not necessarily the biggest killer in JavaScript.
We come from the Java world, as I said, but we have done a lot of studies of what are the good technologies,
because we have a lot of experience about choosing libraries right.
We're trying to really make tables.
We have tables about libraries and so on, about technologies.
Don't hesitate to look at this.
X-Riki is also hiring.
If you find this project interesting, you can also join.
If you're interested in what X-Riki is about, I have a beautiful conference at 9am tomorrow.
If you like to wake up early in K, and we also have a party,
you can scan the QR code if you want to join our party tonight.
There's no room left?
You can still try. You can still try. It doesn't matter.
There's a risk. Thank you. Questions?
APPLAUSE
Any questions?
Do you have an example of an extension you're imagining or planning for?
First, any macros are extensions.
If you want to add macros in your wiki, it's going to be extensions.
If you look at X-Riki, we have 650 extensions.
We have at least 50 high-quality extensions that we're not bundling with X-Riki.
Lots of them are macros.
Macros can be extensions, but it can be just adding a feature.
Structured data would be an extension.
We would not bundle it in the basic one, in the basic crystal,
if you are not using crystal as a back end, because we wouldn't support anything.
Everything is going to be X-Riki supports.
For us, anything will be an extension.
The difference is some will be bundled and some won't be bundled,
but storage system is an extension.
Access to Tiki can be an extension.
Access to GitHub is one.
Access to Git, access to file system, they are all extensions.
Thank you. Another question?
No? No question?
OK. Thank you very much.
Last second.
Do you have a specific library for JSON-LD? What do you want to use?
Can I repeat the question?
Is there a specific library for JSON-LD that we want to use?
First, when we look at storage, there are two ways to do the abstract storage.
One way is to hope that the server application will support JSON-LD by default.
We'll actually do that for X-Riki to try to make X-Riki give you JSON-LD by default.
We believe that will be better because we'll do conversions of structured data of X-Riki and JSON-LD.
That will be very interesting.
In the Java world, we have found a Java JSON-LD library that is widely available.
On the JavaScript world, at this point, we didn't feel we needed the library.
That's just JSON that we can manipulate.
At this point, we haven't seen the need for a library because we're just storing the JSON-LD data as offline right away.
Sorry, I forgot to say.
The second way is to do the conversion to JSON-LD on the client.
That means the storage module will use the standard API of the backend
and then transforms things to JSON-LD to give it to the other crystal modules that will understand JSON-LD.
The conversion would be on the client and then you store as offline the resulting of that conversion so that you can do anything in the application.
We didn't see the need yet, but we're not there yet.
We did some tests of how X-Riki.NET to JSON-LD would display when it has structured data in a page.
We've been able to replicate things we do in X-Riki on the client side in a similar way.
We're not there yet.
For now, we're focusing on the editing experience, which is the most important part for the beginning.
Thank you.
Thank you very much.
Another question.
Sorry, we'll take it outside.