Hello,
I have created the membership application page for Q2 2026 at:
https://wiki.xmpp.org/web/Membership_Applications_Q2_2026
The following XSF members have to reapply:
* Daniel Brötzmann
* Artur Hefczyc
* Wojciech Kapcia
* Guus der Kinderen
* Mathieu Pasquet
* Mickaël Rémond
* Arc Riley
* Kevin Smith
* Andrzej Wójcik
* Nicolas Cedilnik
* Dele Olajide
* Jérôme Sautret
* Badri Sunderarajan
Regards,
Alex
Hi folks,
These have come up before, but I don't think the board has ever
actually voted on them as an agenda item (forgive me if I'm wrong, but
I found no record of it).
Therefore, I would like these two membership-related proposals to be
picked up for discussion and voting by the board:
1) Make the publication of members' real names optional
This has come up a number of times, and there is broad consensus that
we don't need to publish real names of our members, even if we may
need to have them privately on file.
This proposal would be to explicitly permit members to reveal their
names only to the XSF Secretary, and allow pseudonyms to be used
elsewhere.
I believe that adoption of this proposal would help encourage more
people to join the XSF as members, who may be unwilling to publish
their real name on the internet, or connect their identity with the
XSF (for which I can think of countless possible reasons).
2) Cease publishing vote tallies for membership applications
It has been raised before, by someone who said it contributed to not
renewing their membership, that the presence of "no" votes on the
membership page was not a good experience.
Realistically, it is very rare for members to be accepted unanimously
(most people have some "no" votes, and this will only increase as our
membership increases). However, I fear that publishing the vote counts
turns it into something of an unnecessary popularity contest, even if
it isn't aiming to be one. It's not necessary for them to be public,
as long as we keep the results on file.
For people who are part of minorities in our community, it can be
disconcerting to be told that some people voted against them, and to
have a publicly visible record and ranking.
Therefore I am proposing reduction of our membership results to a list
of accepted members instead of publishing tallies publicly.
I am not proposing changes to our council or board elections, as I
think those would need additional consideration and may warrant
greater transparency.
Regards,
Matthew
Dear members,
I hope you are doing all fine.
TL;DR: Can we present XMPP Project donation information at xmpp.org per
software listed? (which involes updating the DOAP XEP [1])
As you know we are having a great success since we started publishing
XMPP software and project information via the .doap files at xmpp.org.
It not just allowed to improve the visualization but helped even build
new tools for comparison of the capabilities behind each software, such
as the XMPP Software Comparison [2]. Many thanks to Daniel Brötzmann in
that regard!
For a while there is the idea out to also support the projects by
presenting a direct reference to their donation information and beyond.
It would hopefully help projects run by volunteers to generate a bit
more attention to their background and also to give something back.
Of course, there can be more ideas on what other things we can do, too.
This should be a discussion if such a promotion of donation information
is okay to do. It should not be not about the DOAP standard. That we can
take in a different fora. (But yes, it would require an update of the XEP.)
Best regards,
Eddie
[1] XEP-0453: DOAP usage in XMPP https://xmpp.org/extensions/xep-0453.html
[2] Software · XMPP Software Comparison
https://xmpp.org/software/software-comparison/
Good evening,
I have discussed this on XMPP already, however I was recommended to
bring this to the members mailing list, however back when I was
recommended I was not a member, so thank you all who elected me, and
for those who encouraged and helped me apply.
I feel like getting an XMPP presence at EMFCamp would be a good way to
outreach to new people. EMFCamp isn't just FOSS, its tech/engineering
as a whole allowing to outreach to people outside the usual bubbles. I
have been told that there is some XMPP stuff at CCCamp, this would be
similar.
What are villages?
Villages are groups of tents around a central theme, in this case it
would be XMPP. We would hopefully have people interested in XMPP camp
around the village, and then in the centre of the village have a few
tables or something to show off XMPP (see the idea) and have stickers
and stuff.
I still need to speak to some people on the feasibility of this, but
for now this is the "draft" so to speak.
The idea?
Villages should have a lot more space than at FOSDEM, so this gives a
lot more room to show more stuff off.
I am dividing it up into 3 areas.
1. Server side
I would like to copy Ralph's idea from FOSDEM, and setup an XMPP server
on a SBC, and then run it on a table for everyone to see. The event
itself is entirely Matrix (unfortunately), so my idea is to have an
unofficial chat for the event, and hopefully as we progress through the
event more and more people will yap on the XMPP MUC(s) hosted on a SBC
which you can see yourself, hopefully showing off the power of XMPP.
Someone suggested (sorry forgot who it was) that we also allow
antonymous login, to quickly onboard people for the event, the MUCs
and any accounts will be deleted after the event, and all data erased.
2. Client side
I have many spare laptops, and phones, as I do quite a bit of device
repair. I should have a spare iphone for showing off Monal, then I
planned to have an android phone (or a few) to show off conversations
(and maybe its forks, cheogram and monocles chat).
Then for desktop, gajim/dino, I might put gajim onto windows and then
dino on Linux so its more inclusive for those who don't daily drive
Linux.
Potentially show off some of the web implementations too, such as movim
and converse, however I don't want to do too many as I need to be able
to handle the workload.
The idea is so that people can pick up a device, and play with it (test
accounts), I stole this idea from PostmarketOS. Speaking of
PostmarketOS maybe it would be cool to have a Linux phone running XMPP
as well?
3. Providers (if I have help)
It would be amazing if one or maybe a few providers could be there. In
the modern age, I feel a lot of people are interested in where there
data is stored and how it is stored so it would potentially be
interesting to have someone who has hands on experience with this.
What do I need?
I can pretty much do most of this myself, I already have leaflets and
stickers from FOSDEM which I wanted to distribute at EuroBSDCon.
Most of the gear I can provide. I do not drive however, so I can carry
the devices to show off, stickers and leaflets, but might need some
help with the setup of the central part of the village to show off the
stuff. I have already had one person (forgot who it was) who offered to
help.
Obviously having as many XSF members, and XMPP users as possible would
be cool, but not required, most of this I could handle myself.
Attending?
The website [1] has a ton of information, this is a paid event, prices
can be seen here [2], tickets are released in batches, and are snapped
up quickly, so it might be difficult to get tickets, the times of
ticket dumps follows:
• Monday 9th March, 20:00 UTC
• Sunday 22nd March, 15:00 UTC
• Thursday 2nd April, 18:00 BST
If you would like to help out, please let me know. This is still a
"draft", and not set in stone. I haven't even got a ticket yet for
example :p
Thank you for reading,
--
Polarian
Jabber/XMPP: polarian(a)icebound.dev
[1] https://www.emfcamp.org/
[2] https://www.emfcamp.org/tickets
Dear all,
the XSF Communication Team is pleased to announce a new initiative to
help evolving the XMPP ecosystem in a broader and aligned perspective.
This should cover discussions, development but also extended public
communication and presence. As this is being setup in an iterative way
its participants will be able to form and steer the collaborations
direction over time.
You can read the full blog post here:
https://xmpp.org/2026/01/chat-of-the-future-initiative/
After a number of questions let me elaborate a bit more.
So, when you join the session(s) we will have a interactive
collaboration board present where we will conduct different exercises.
We start with basically exposure and a discussion of the networks status
quo is as everyone sees it from their corner. If you have ideas of what
you would like to change, you can just propose those.
Ideas could be for example that members from the XMPP community are
interest in an organised (regular?) interoperability meeting on certain
XEPs. Others think of more engagement along encryption or building a
better landing page for developers. In the end, all those great ideas
and constructive feedback can be brought to the first session, but also
at a later point. Out of this, the round will form a collaborative
direction that anyone interested can join, commit and contribute to.
There are more and other directing and hopefully fun exercises of this
nature and we will collect, review and discuss ideas that could be worth
moving on within a couple of months. Ideas, to be shaped in smaller
activities, with no long time frames but effective outcomes that the
ecosystem benefits at user or (new) developers level.
We hope this is a motivating opportunity for the XMPP network and help
us to step ahead all together. We also believe that such a collaboration
can enable the network to evolve and gain new momentum and result in
strong benefits for all actors.
Feel free to comeback with your thoughts already.
Best regards from the Communication Team,
Eddie
Dear XSF community,
Documentation has been prepared outlining example approaches for relocating
the XSF's legal home to the European Union. These proposals are intended as
lightweight, pragmatic illustrations of how such a transition could work.
They are not intended to define the eventual legal form, and no decisions
have been made.
Please note: although I am currently a Board member, these proposals were
created on my own accord and do not reflect any shared opinion or decision
of the XSF Board.
Currently, the examples focus on structures under Dutch law and assume a
complete migration from the U.S. to the EU. They are meant to help the
community explore possibilities, understand trade-offs, and discuss
potential paths forward.
The proposals can be found at:
https://wiki.xmpp.org/web/XSF_EU_Legal_Transition_Proposal
Please review these examples, ask questions, and share feedback - maybe
even add alternative proposals of your own. Your input will help ensure
that any future decision is well-informed, practical, and aligned with the
needs of the XSF community.
Kind regards,
Guus
Hi all,
I wanted to split off the recent discussion by Peter and Travis suggesting
we may consider moving away from mailing lists in favor of MUCs. I think
this deserves its own thread so as not to dilute the ongoing conversation
in the previous discussion.
Personally, I am not in favor of abandoning mailing lists for this type of
discussion. Mailing lists have several important advantages:
- Time to respond thoughtfully: Mailing lists allow participants to
carefully compose responses. Some people are naturally quick at finding the
right words in real time, but others (also including many for whom English
is not a native language) benefit from (or simply prefer) having more time
to reflect. For example, composing this email took me 41 minutes (longer
than I care to admit), a duration that would generally be impractical in a
live chat room.
- Asynchronous participation and time zones: Mailing lists naturally
allow people to contribute "later" which is much harder to do in chat rooms
(where conversations 'moved on'). This is especially helpful for people in
different time zones or those who cannot respond immediately.
- Offline processing and focus: Threads in a mailing list are ordered
and easy to read offline. Chat rooms often mix multiple topics, making it
harder to follow the discussion. In practice, I don't expect the majority
of people to scroll back in history, which significantly reduces the
potential reach.
- Engaging quieter participants: Mailing lists often generate responses
from participants who do not otherwise join MUC discussions.
- Record keeping and referencing: Mailing list archives provide a
single, persistent URL for referencing discussions. Chat logs are often
fragmented and thus lack a canonical link.
I understand that, technically, XMPP technology could be used in ways
beyond standard instant messaging to support discussions like these, and
some clients could replicate many of the benefits of mailing lists.
However, in practice, I don't expect the majority of users to take
advantage of these features consistently. Even today, features such as
message references or reactions are inconsistently supported, which can
make following discussions difficult for people who cannot, or prefer not
to, change their XMPP implementation.
So while MUCs are great for fast-paced, interactive discussions where ideas
can bounce around quickly, I see mailing lists as far more practical for
thoughtful, organized discussions that people can read, reflect on, and
reference later.
Kind regards,
Guus
Dear all,
This year the XMPP Summit 28 took again place in Brussels and we had
great participation of almost 40 people attending in-person and online.
We also had several new faces there which is great news, too!
The same, FOSDEM 2026 took also place at ULB, and though we had to
arrange for a new location our Realtime Lounge, the feedback and
impressions have been mostly positive.
Finally, writing a summary of our experience would be valuable and help
others to gain interest in the way we work and the ecosystem are
continuously building. To collaborate on this effort, everyone is
invited to contribute to this pad before we will create a final PR to
review: https://pad.nixnet.services/BoUphR54TnOzh774PhNWXw?view
To provide your individual feedback everyone is invited to participate
this survey on both events:
https://xsf-communication-team.limesurvey.net/286665?lang=en&newtest=Y
Please leave your feedback by Sun, 22nd February 2026.
At this point, many thanks to everyone who supported us making both
happenings a success!
Best regards!
Eddie
Hello,
you can find the meeting minutes here:
https://wiki.xmpp.org/web/Meeting-Minutes-2026-03-05
All applicants and reappliers were accepted. Congratulations to everyone.
And a warm welcome to our new member George Timms.
I will open the Q2 application process shortly.
Alex
Hi folks,
I would like the board to consider, at their next meeting, the
formation of a team for moderation of XSF discussion venues (at least
MUCs).
"Why?"
Currently the set of people with moderator/admin status in XSF venues
varies from channel to channel, and people are granted permissions on
a rather ad hoc basis. This raises questions of responsibility and
transparency, and moderation varies significantly between channels.
The goal of a moderation team would be to:
- Formally define a set of people to gain moderation rights across all
XSF discussion venues
- Spread the responsibility, accountability and decision-making among members
- Improve communication between moderators (formation of a dedicated
MUC for the team to discuss moderation matters would be sensible)
Currently moderators act primarily as individuals, which leaves them
open to being singled out for retaliation, rather than feeling like
they have the backing of the XSF. This sometimes leads to no
moderation action being taken, when it probably should (if we care
about the health of our community). If moderation decisions can be
agreed with a team, this will help make our moderation actions more
consistent and more fair to both the moderator and the moderated.
"What would be the difference from the conduct team?"
I see the conduct team as a smaller group reserved for tackling only
important cases, mostly reactively, in response to reports and appeals
as described in the CoC. The moderation team would (ideally) consist
of slightly more people. They would be responsible for the day-to-day
moderation duties while following the words of the CoC and the
direction of the conduct team where provided.
Regards,
Matthew
