Thank you, Mohsen, very much for the great talk.
People, if you have questions, please put them on the pad,
or IRC, but preferably the pad, and then we'll also open this room
in a minute or two so that if anyone who wants to join here and ask the questions
directly to Mohsen, they could do that as well.
Dear Mohsen, please take it away.
Hello, greetings.
Yeah, I don't see any questions yet,
so let me add a few additional notes
to what was in the presentation.
In there, I make several points.
Some of them are tactical, some are more strategic.
Let me delve into the strategic message a bit.
On the messaging capabilities of Emacs
and the broader office environment capabilities of Emacs,
we have a huge, incredibly powerful asset,
but the amount of complexity
and the surrounding configuration capabilities
and hurdles and difficulties that are involved
into making a really powerful environment for ourselves,
we have a big obstacle,
and that obstacle is that of integration.
Over the past 40 years, the general model has been that of producing components
where we do great stuff.
We put various email MTAs and support them through Emacs.
Additionally, we say that we want Emacs to be used on all platforms.
If you're on Windows, there is Emacs support for it.
If there is Mac OS, there is support for that.
And of course, all of the GNU Linux stuff,
capabilities and platforms.
So all of this results into tremendous amounts of energy
to go both on the developer side and on the user side to support everything.
And that's what we have been doing over the past 40 years.
What I am saying is that perhaps we should revisit this approach
and consider moving towards creating a complete
Libre Halal free software digital ecosystem for ourselves
and consider Emacs as the usage environment
of that totality of the digital ecosystem.
This will solve many problems if we were to buy into such an approach.
If we were to say that as the platform de facto
and because of everything that is happening,
Debian is a reasonable good choice.
And then we would tie in all Emacs capabilities
primarily and firstly to our own platform
and start building on it.
So let's take the situation with email in such a scenario.
The main obstacles that we have right now is that
GNU comes out with support for pretty much everything.
But as the user, someone trying to buy into doing email on Emacs,
which of these facilities, which of these features
would be the right way to go?
So what I am saying, having chosen our platform as Debian,
what if we were to say that we would buy into something like Q-mail
as the outgoing message model and just fully bring it in
and consider it as the only and the default MTA
for everything that we do?
Suddenly a whole lot of complexity goes away.
And similarly for bringing in email,
what if we were to say that we have bought into offline IMAP
and then the next really interesting piece is
what should be our mailboxes?
This notion that today de facto Gmail is the universal place
where you get your mailboxes.
And very easily we can, not very easily,
but we certainly can support Gmail.
But what if we were to get in the business of actually providing
mailboxes for everyone and combine that with the platform
and the main user agent?
So that's really the strategic message that I want to,
that I'm sending.
Excellent, thank you.
And I think in the meantime we have four questions
on the panel already.
Okay, I don't see them here.
Oh, are you looking in the public chat here on the big blue button?
Yes.
Okay, let me put a link.
So there's a separate pad where people are posting their questions.
Okay, now I am seeing.
Yeah, if it might be easier I could probably copy the questions over here.
No, no, I am actually seeing them.
Okay.
Perfectly, perfectly okay.
So the first question is something I have liked about Not Much
is using Maildear makes searching fast
and the knowledge that you have all your email period.
Why GNU's over Not Much?
As a side note, you have also Much Think for Not Much client
and Jmap for more exotic normal clients.
So I think there are two things going on here.
Not Much is more than one thing.
Not Much is a search, a mail search engine
and also Not Much is a MUA.
So in terms of choosing, certainly for search, for mail search capabilities,
we should go with Not Much
and there is GNU's search capabilities for Not Much in there.
So what I am suggesting is that we stick to GNU's as an MUA,
but the search capabilities that you are talking about
or that the question mentions are certainly available.
A second question is, so the idea is more about Emacs
as a holistic computing experience with other packages and services
rather than about email specifically
as an alternative to something like Microsoft Office Suite.
Yes, this is right on the point.
What I am saying is that email by itself
is not really all that meaningful or interesting
and everywhere that you look in the proprietary model,
you would see that the likes of Google and the likes of Microsoft
do not view email as standalone capabilities.
They see it as integrated with address book.
They see it as integrated with calendar.
They see it integrated with search.
They see it as integrated with your to-do list and time management.
So you are very right.
The question is right on point.
Email by itself is not significant
and the reason why Emacs is the right place to do email
is because Emacs is the kitchen sink.
It does absolutely everything and that is what you want.
The third question is,
early on you express misgivings about the Western copyright regime
but you are using a GPL license.
Is that a conflict?
Great work by the way.
No, I don't think it is a conflict.
My position is that the Western intellectual property right regime
is a colossal ownership mistake.
Having said that, and I do call for its abolishment,
having said that, it is unrealistic to assume or recognize
that just because I say it and just because I believe it,
in fact it will be abolished or that a significant change would happen,
particularly in the Western world.
So in the Western context, what can we do?
What should we do?
What I am saying there is that particularly in the context of services,
all licenses should be the strictest ones possible
and the one that is codified is the Afero GPL license.
So I have subjected all my work to the Afero GPL license.
I know of GNU, how do you think about using it for packaging,
configuring Emacs, your various packages,
else you might look it up or NixOS.
So the idea here is that when we go back to this full integration
in the context of a digital ecosystem,
a major challenge is that of bringing in all the necessary packages
from different sources.
So for example, in the context of male user agents,
to put things together you need a set of apt packages
coming from the DBN world.
You need a set of pypi packages coming from the Python world
and you need a set of list packages coming from Elisp archives.
And likely you need a whole lot of others.
You need possibly Node.js stuff and you also possibly need Ruby stuff.
And this integration is going to be complex.
The approach that I have taken is that of going best of breed
in the context of each of the domains.
So in Python, while there may be other packaging models,
we go with pypi.
On the platform, it's clear that it's apt.
On the Linux, over the past five years, we have solved mostly
that archiving machinery.
If the question is, and I'm not familiar with the specifics
of what was mentioned in terms of a unified packaging model,
but if the question is that of a unified packaging integration model,
I'd love to do it when it's mature and ready.
At this point, I am going the route of best of breed selections
within each domain.
And if I chime in briefly, Mohsen, I think there was a typo in the question.
They are asking about GNU Geeks or mentioning GNU Geeks
and also potentially NixOS.
And I think these two also very much go with your idea
of tying everything together, these different package management systems.
So GNU Geeks is a GNU Linux distribution like Debian is,
but it's written in GNU Guile Lisp or Guile Scheme.
And it's a very interesting concept where all of the packaging code
and everything is done in GNU Guile Scheme and ties everything together
and integrates great with Emacs.
So that might be something worth checking out later on.
Right.
I had taken a very cursory look at that, and I'll keep my eyes open on it.
I think in due course, maybe that's the way to go.
There's one more question coming in.
I let the person who is asking the question to complete it.
Okay.
Yeah, in the meantime, I'll also mention that I think we have about
four more minutes of on-stream live Q&A time, at which point after that,
the stream will move on.
But you Mohsen and, of course, people watching are welcome to come here,
join this Big Blue Button Room directly and ask the questions here
or on the pad.
Great.
So let me read the question.
Is this being split up in a heavily configured server for email hosting
and the thin client package for you locally client to integrate with your
Emacs package?
Maybe with a client thin Docker container for other packages,
like not much locally?
Actually, that is not really exactly what I am speaking of.
The concept of a thin client is difficult to characterize.
So if you have Emacs and everything else that you want to use as a usage
environment along with your email system, if we want to call that a thin
client, certainly that is what I call the usage environment.
On the services side, I am not speaking of just one.
I am speaking of support for multiple, of course, obviously,
but having one that in my own case, for example, by name.net,
is the primary support.
And in terms of packaging that as a thin client instead of inside of a
Docker, that is certainly possible, but it is not, I don't consider it as
the only way to go.
You can do your packaging any way you want and, well, you can do your
packaging and then deliver it however you want.
On these questions, if I was not on the point in understanding the
questions and answering them correctly, if there are any follow-ups,
I would be happy to take them.
Yeah, if there are no other questions, I can perhaps bring up the
presentation and maybe make a few additional points.
So, I think one key slide in here is this one, where what I am saying
is that we have been very good at producing components and that we
really need to get into systems development or environments
development as opposed to components development.
And to raise that a bit more so that we can move towards having
something that we can call a non-procreatory digital ecosystem,
I think we need to work towards having frameworks for services.
And while we have defined free software or what I call Libre
Halal software, we don't have precise definitions for Libre services,
free services.
Free services is going to be a very bad name, because we want it to
be commercial.
We want people to pay for it as they use it.
And so the natural name would be something like Libre services.
And in that context, if you go to Libre services.org, you will see
my definition of what that would mean, what non-proprietary
codification of services would mean.
Another slide perhaps to take a look at is this one, where I am
making the case for not considering Emacs by itself as core of
anything, but viewing and cultivating and introducing this
concept of common agent and building on it.
Let me go see if there are any other questions.
Yeah, I didn't see any more.
May I drop in and ask a question directly?
Of course.
Okay, so I have a question regarding combining GNU and NotMuch.
Yes.
So do you combine tagging facilities of NotMuch into GNU as well?
Sorry, can you repeat that?
Do you also integrate tagging facilities of NotMuch into GNU?
Tagging? I have not done that.
Okay, because I was looking into combining GNU and NotMuch at some point,
but what stopped me from continuing is that NotMuch is mostly about tags,
and then GNU has a search option for NotMuch, using NotMuch.
But how do you add tags from GNU?
Right, in terms of continuous use, it's only recently that I'm doing that,
and I don't think it means that it is not doable.
It's just that in my own case, I haven't done it.
Yeah, it's certainly doable.
You present this unified system that brings everything together.
So I was wondering if it's already implemented.
Yeah, I must say all that I do is I want to say that that is the direction that I want to go.
Okay.
We have a long way to go.
It's mostly a question of, and that is not the general direction and formalization that has been happening.
So more or less, a lot of what I mentioned in there is not fully baked.
Okay, thanks.
I think we also have a question here in chat, Mohsen.
I wasn't sure if you already saw or answered it or not.
Sorry.
No, let me, is it on the chat?
Yes, public chat here on big blue button.
Question by Thuna.
Oh, public chat on the big blue button.
Yeah.
Can you expand on definition of Libre Halal?
I'm a bit lost.
Yes.
Yes, yes, yes, yes.
So, you see, we have labels of free software that are well established, and we have definitions of open source that are well established.
And both of these are in the Western context and from the perspective of Western folks.
What I am saying is that neither free software nor open source are the right labels.
What we are looking for is actually ethical software, not free software.
Freedom is something that is wonderful and great, but it may not be the right thing to be free.
What I am saying here is that a manner of existence of software is the key concept.
Allow me to share the screen.
Just one moment.
And maybe point you to a place where I could answer it in depth.
It is certainly not a topic that I could do justice to in just a moment.
So, if you were to look for nature of polyexistentials and Googling that would take you there, there is a 250-page document there that says why I believe the Western intellectual property rights is wrong.
And it goes through and says, well, if polyexistentials are not to be governed by the intellectual property rights regime, then what is the right manner of governing them?
So, what is the right manner of existence of software? And what label should we use for that?
And in here, there is a whole section that about 10 pages or so that describes what Halal means and why the Libre Halal label is the right label.
So, let me perhaps point you to that section.
Yeah, this is on the Cure section.
I think if you were to go to chapter 12, that would be a good place.
Do you happen to have the link to this page handy, Mohsan?
Yeah, it is included in the presentation. Let me go there very quickly.
Oops, sorry.
Just one moment.
Yeah, it's in the presentation with a QR code. So, let me look it up and bring it back up again.
Thank you.
So, the link for that document is on slide 13.
Can you see it?
I'm not seeing your slides, but okay, it is getting shared again. Yep. Thanks.
Yeah, sorry. Go ahead.
Yeah, that is the...
Oh, very good. Somebody else also threw it up on there.
But it's a little bit different.
Yes, yes.
Yeah, it's PLPC 120.0.33.
I mean, any other questions? Yes, thank you.
Thanks. Yeah, I don't see any other questions on the panel.
Oh, there's one new question here from Thuna again.
What is the scope of what you are imagining? Just software?
No, certainly not just software. It is software and services.
So, that is, I think, the next challenge and the next step for us.
We have to think of ways of competing with Gmail and Outlook.com.
So, services are certainly within the scope.
In the abstract sense of what polyexistentials are.
So, polyexistentials are things that exist in multiples.
So, any form of knowledge is within the scope.
And that goes to medications, goes to anything that is patentable and art and anything that is copyable.
Yes, NFTs are a form of creating mono-existentials out of polyexistentials.
So, by the time that you create an NFT, it is no longer the subject of what I am talking about.
But the process of creating mono-existentials off of polyexistentials is what we should be discussing.
There is a section in that book on that topic as well with the same subject of how one goes about creating that.
You see, any sort of a name could be thought of as an NFT.
So, if you think of our domain name system, although it is in the realm of software and services,
what you have emacsconf.org that has become unique and it's a mono-existential.
I think my key message here is this vocabulary of polyexistence and mono-existence and mixed existence,
which is the novelty in the stuff that I have written.
We all have understood these for a long time.
It's a question of coming up with the right vocabulary to express them with precision that remains and then acting on them.
Excellent.
As a lot of people have said, I think both here and also in IRC, there is a lot of information and material to digest from this talk
and to try to think really deeply about for the coming weeks and months.
So, that's great.
Thank you.
We can keep this session going as long as you want.
The stream has already moved on, but here it is open.
If folks have any more questions, feel free to post them here or on the separate pad page.
Yeah, or if not, then we can all drop off at some point.
Sure.
If there are any questions, I'll be happy to answer them.
Otherwise, perhaps we could go and watch the rest.
Yeah, I mean, I think perhaps it's a good thing to consider the session complete.
Sure, sounds good to me.
Thank you again very much Mohsen, really appreciate it.
Thank you.
Cheers, take care.
Take care.