Dear all,
the XSF Communication Team has setup their new mail account. That allows
us to better organise as well as put aside previous limitations. Thank
you for your support here!
commteam [e t] xmpp [d ot] org
As you see we have also connected the account to the xmpp.org domain so
it looks more dedicated to the XSF organisation now.
Thank you to the iTeam and especially singpolyma here!
To make most out of it, I will just post some of the services that are
covered in the mailbox.org plan so maybe other teams can also take
advantage of the capabilities. If you see any helpful options for you in
here, please reach out.
One thing that that we could think about by the way if we want to
migrate from Google Calendar to their more privacy respecting option:
https://kb.mailbox.org/en/private/address-book-and-calendar/share-calendar-…
* 10 GB mail storage
* 25 aliases @mailbox.org
* 50 aliases @owndomains
* 5 GB Cloud Storage
* Office features
* Video conference features
* Team accounts features (address books, calendars, cloud storage)
Cheers,
Eddie
Hi folks,
Most of you are probably familiar with CVEs. They're like universal
bug numbers for security vulnerabilities. They make it much easier to
exchange information about security issues in software, if everyone
refers to the same vulnerability by the same number.
The CVE ecosystem isn't perfect, and has been a bit turbulent over
recent years. One cause of this is that the number of vulnerabilities
has been increasing for a long time, and the organization that used to
issue them became a bottleneck - it now delegates a lot of the work to
others.
One way it does this delegation is by working with "CVE Numbering
Authorities". Basically, organizations can register as a numbering
authority (CVE issuer) within a particular category of software.
Sometimes this can be a single project (the Linux kernel recently
became a CNA), but ideally it encompasses a range of related software.
Which leads to the obvious suggestion... I believe it would be
beneficial for the XSF to apply for CNA status, with the scope of
issuing CVEs for software within the XMPP ecosystem.
There are various benefits:
- The XSF is already a hub for XMPP software developers, making
discoverability and issuance easier for projects
- Response times may be faster (due to the narrow scope, the XSF will
naturally receive a far lower volume of CVE requests than generic CNAs
such as MITRE)
- The XSF has a history of coordinating vulnerability communication
between projects when necessary. This has been very useful in the
past, and it would help to bolster that activity.
I think it would be sensible for us to discuss this. If there is
positive consensus, I don't mind taking on the task of the application
and any necessary processes. However for the operation of a CNA
programme it would be good to have at least several trusted people
willing to work on such a team.
Further reading:
- https://www.cve.org/PartnerInformation/Partner
- https://nvd.nist.gov/general/cna-counting
Regards,
Matthew
Dear all,
with this email I would like to invite everyone to provide constructive
feedback on the outcomes from multiple sessions and discussions. Those
we had in the context of the Chat of the Future Initiative together with
people from the XMPP community.
- Unified promotional statements and banners for our media channels
You can add your own ideas, upvote and comment. Find the link here:
https://pad.nixnet.services/N1kbjrLWQ-SgNiJbCpZc8w?view
This is not the end of the road, and there are more ideas to be
developed. We believe this is a good and collaborative start.
- XMPP Newsletter Release Event
The idea is to get together online, speak about the monthly highlights,
celebrate the efforts of the community but also have an open space to
talk to each other and especially welcome interested people. The initial
part of such a session could also be recorded and uploaded to e.g.
Peertube. Additionally, the people and developers behind the XMPP news
could be ask to give a brief update on their own, if they want to.
We are aware that coordinating and performing such an event will require
additional efforts and more elaboration though. If you would be
interested in joining such an event, at least once in a while, would be
helpful information.
We the hope that you can find in it a new channel to reach a wider
audience to show your engagement and involvement with the XSF and the
XMPP community, share your work and maybe even find a new way to promote
your software.
We are open to your comments and contributions and would love to hear
from you - ideally before Tue, 28th April when the next check-in session
takes place. Feel free to join!
Best regards,
Eddie
Dear XSF members,
The XMPP Summit is where the XMPP community comes together to discuss
protocol development, implementation experience, and the future of the
ecosystem.
There has been discussion about organizing a potential second Summit,
possibly as an online-only event. Following recent Board discussions, SCAM
has been asked to explore the feasibility of a 2026 online Summit,
including format and constraints. As part of this exploratory phase, we are
gathering input on possible scheduling options.
The 29th XMPP Summit would, if it goes ahead, be held online on a Friday
and Saturday in September. This online edition is intended as an experiment
to complement the traditional in-person Summit by lowering participation
barriers and enabling more focused, structured technical discussions.
More context on the goals and scope of the exploration can be found on the
wiki: https://wiki.xmpp.org/web/Conferences/Summit_29
At this stage, no final decision has been made to proceed with the event.
The SCAM workteam is collecting input to assess feasibility and planning
constraints.
We would like to invite XSF members to vote on which of two proposed date
options would work best in case the event proceeds. The poll closes on 26
May 2026.
How to answer: this poll is about your availability, not a commitment. For
each date, choose “Yes” if you are available, “If needed” if you could make
it work but it is not your preference, and “No” if you are not available.
Poll link: https://beta.framadate.org/polls/5574788d6bc5a38e8853
Please keep this information within the XSF member mailing list for now. We
will make a public announcement once there is clarity on whether and when
the event will take place.
Thank you for your input.
Daniel & Guus
XSF Summits, Conferences & Meetups workteam
Good afternoon,
I am not the organiser for this, Matthew Fennell is however they do not
have access to this mailing list so I thought I would post it here
instead.
FSF LibreLocal is a series of local meetups for FOSS software, I have
no clue how many people are predicted to turn up to the London one, but
as XMPP is heavily involved within FOSS, I felt it would be a relevant
thing to bring to this list.
For more information please see [1].
Thanks,
--
Polarian
Jabber/XMPP: polarian(a)icebound.dev
[1] https://mailman.lug.org.uk/pipermail/gllug/2026-April/083787.html
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 Board members,
This email announces the agenda for our next Board meeting, scheduled for
Thursday, 16 April 2026, from 16:00 to 16:30 UTC. The meeting will take
place in the XSF chatroom at xmpp:xsf@muc.xmpp.org?join.
Brief context is included for each agenda item to support preparation.
*1. Welcome*
Opening of the meeting.
*2. Formalize Agenda*Confirm and approve the agenda for this meeting.
*3. Action item follow-up: Keep Android Open letter*
Confirm that the Chair sent the signing email on behalf of the XSF
following the vote at the March 5 meeting.
*4. Vote: Membership Name Disclosure Policy*
Vote on the motion text (see below) recorded at the April 2 meeting
regarding optional public disclosure of members' real names. Since the last
meeting, Ralph's concerns about governance transparency were raised on the
mailing list and responded to by Matthew, who argued that the current
practice of publishing unverified names provides only an illusion of
transparency and disproportionately burdens privacy-conscious members. The
proposed motion preserves public listing of all members, while allowing use
of an alternative identifier upon request, with real names retained
privately by the Secretary and accessible to the Board. Officers, Board
members, and Council members remain excluded from the opt-out. Determine
whether the Board is ready to adopt the motion as drafted, or amend it in
light of any remaining concerns. Related mailing list thread:
https://mail.jabber.org/hyperkitty/list/members@xmpp.org/thread/JLLM2YCWQBL…
*The recorded motion text*
*Members shall be listed publicly. Members may request, at any time, that
their real name not be used in such public listings, by notifying the
Secretary. In that case, the member may be identified by an alternative
identifier (such as a username or handle) of their choosing. Real names for
all members shall be retained on file by the Secretary and remain
accessible to the Board of Directors. This opt-out is not available to
members while serving as XSF Officers, or as members of the Board of
Directors or Council, for whom public identification by real name remains
required.*
*5. Vote: Publication of Membership Vote Tallies*
Vote on the motion text (see below) recorded at the April 2 meeting to
cease publishing membership application vote tallies on the voting wiki
pages, while retaining full records on file with the Secretary. Since the
last meeting, flow reiterated on the mailing list his preference that
tallies remain accessible to members, while others questioned what
practical transparency value tallies provide and highlighted that
member-only access may undermine the goal of reducing the discomfort
applicants feel from being publicly scored. Matthew also suggested a
possible compromise already reflected in recent practice: publishing
approval counts only, without “no” tallies. Assess whether to adopt the
original motion as drafted, amend it to provide members-only access, or
formalize an approvals-only publication model instead. Related mailing list
thread:
https://mail.jabber.org/hyperkitty/list/members@xmpp.org/thread/JLLM2YCWQBL…
*The recorded motion text*
*The XSF shall cease publishing vote tallies for membership applications on
the voting wiki pages. Vote results shall continue to be retained on file
by the Secretary.*
*6. XSF EU legal structure: assess proposals and next steps*
Five proposals are now documented on the wiki, covering a range of options
from full EU migration to a lightweight representative office. The mailing
list discussion has raised several overarching concerns, including
transition costs, IP transfer, and long-term sustainability. Assess whether
the discussion has matured enough to narrow the field, or whether further
input is needed before the Board can act. Wiki page:
https://wiki.xmpp.org/web/XSF_EU_Legal_Transition_Proposal
*7. Progress report: Second XMPP Summit 2026 (online)*Follow-up on the task
assigned to SCAM at the February 19 meeting to explore format and
feasibility of a 2026 online Summit. Receive an update.
*8. Progress report: Outreach initiatives*
Follow-up on the tasks assigned at the February 19 meeting: CommTeam
improving XMPP/XSF Wikipedia and public pages, and SCAM developing a plan
for attending conferences and events. Receive brief status updates from the
responsible teams.
*9. XMPP 2: Update and next steps*Prior to the April 2nd Board meeting,
Daniel Gultsch and Marvin attended IETF 125 in Shenzhen, where they report
a positive and welcoming reception to the idea of updating the XMPP core
RFC. A concrete next step has been identified: producing an initial draft
to demonstrate substance, starting with an update to RFC 6120 (core). A
side meeting at IETF 126 in Vienna is being planned to gauge broader
interest, and participation in the IETF 126 Hackathon (July 18–19, Vienna)
has been proposed as a low-barrier opportunity to raise XMPP's visibility
at the IETF. Discuss whether the Board wishes to formally acknowledge or
support these efforts, and whether any action is needed. Mailing list
thread:
https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/7LM6LN5VN…
*10. Any Other Business (AOB)*
Items not listed above that require brief attention.
*11. Date of next meeting*
Agreement on the date of the next Board meeting.
*12. Close*
Closing of the meeting.
Please review the relevant materials ahead of the meeting so that we can
use our time efficiently.
Kind regards,
Guus
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 Board members,
This email announces the agenda for our next Board meeting, scheduled for
Thursday, 2 April 2026, from 16:00 to 16:30 UTC. The meeting will take
place in the XSF chatroom at xmpp:xsf@muc.xmpp.org?join.
*Note: Daylight Savings Time switchover has happened since the last
meeting. Scheduling has been modified *(to have the meeting start at the
same *local* time for most participants).
Brief context is included for each agenda item to support preparation.
*1. Welcome*Opening of the meeting.
*2. Formalize Agenda*Confirm and approve the agenda for this meeting.
*3. Action item follow-up: Keep Android Open letter*Confirm that the Chair
sent the signing email on behalf of the XSF following the vote at the March
5 meeting.
*4. Discuss with Intent to Vote: Membership Name Disclosure Policy*Review
the state of the mailing list discussion initiated on March 3, 2026. Broad
member support exists for making real name disclosure optional. However,
the March 5 meeting surfaced a substantive Board-level objection: that the
XSF, as a legal entity, may have obligations to ensure its members are
known, identifiable people. Note that the proposal does not make names
unknown to the XSF - only to the general public - but this distinction was
not fully resolved. Determine whether the Board is ready to vote, or
whether further discussion is needed. Related mailing list thread:
https://mail.jabber.org/hyperkitty/list/members@xmpp.org/thread/JLLM2YCWQBL…
*5. Discuss with Intent to Vote: Publication of Membership Vote Tallies*Review
the state of the mailing list discussion and the exchange at the March 5
meeting. While broad member support exists for ceasing public publication
of vote tallies, at least one Board member expressed support for
maintaining the current practice. Assess whether sufficient Board consensus
exists to proceed to a vote. Related mailing list thread:
https://mail.jabber.org/hyperkitty/list/members@xmpp.org/thread/JLLM2YCWQBL…
*6. XSF EU legal structure: assess proposals and next steps*Five proposals
are now documented on the wiki, covering a range of options from full EU
migration to a lightweight representative office. The mailing list
discussion has raised several overarching concerns, including transition
costs, IP transfer, and long-term sustainability. Assess whether the
discussion has matured enough to narrow the field, or whether further input
is needed before the Board can act. Wiki page:
https://wiki.xmpp.org/web/XSF_EU_Legal_Transition_Proposal
*7. Progress report: Second XMPP Summit 2026 (online)*Follow-up on the task
assigned to SCAM at the February 19 meeting to explore format and
feasibility of a 2026 online Summit. Receive an update.
*8. Progress report: Outreach initiatives*Follow-up on the tasks assigned
at the February 19 meeting: CommTeam improving XMPP/XSF Wikipedia and
public pages, and SCAM developing a plan for attending conferences and
events. Receive brief status updates from the responsible teams.
*9. XMPP 2: Update and next steps*Since the last meeting, Daniel Gultsch
and Marvin attended IETF 125 in Shenzhen, where they report a positive and
welcoming reception to the idea of updating the XMPP core RFC. A concrete
next step has been identified: producing an initial draft to demonstrate
substance, starting with an update to RFC 6120 (core). A side meeting at
IETF 126 in Vienna is being planned to gauge broader interest, and
participation in the IETF 126 Hackathon (July 18-19, Vienna) has been
proposed as a low-barrier opportunity to raise XMPP's visibility at the
IETF. Discuss whether the Board wishes to formally acknowledge or support
these efforts, and whether any action is needed. Mailing list thread:
https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/7LM6LN5VN…
*10. Any Other Business (AOB)*Items not listed above that require brief
attention.
*11. Date of next meeting*Agreement on the date of the next Board meeting.
*12. Close*Closing of the meeting.
Please review the relevant materials ahead of the meeting so that we can
use our time efficiently.
Kind regards,
Guus
