User:Goffi/Council Candidacy 2024

I am applying to serve on the XMPP Council for the 2024-2025 term. For years, I've hesitated due primarily to time constraints; however, I believe this year presents an opportunity that I can commit to.

You can find my general profile on my user page. In short, since 2008, I have been the lead developer of the Libervia project, which is an XMPP client that focuses not only on instant messaging but also provides blogging, file sharing, photo albums, calendar events, calls, and more. Around this project, I am working on a comprehensive PEP/Pubsub service that can be used as a replacement for internal server implementations thanks to XEP-0355 (Namespace Delegation) and XEP-0356 (Privileged Entity), which I have authored.

Additionally, I work on components such as:

- An XMPP <=> ActivityPub Gateway

- A Galène based SFU component

- An advanced XMPP <=> email gateway

- A file sharing component

I've authored several XEPs:

- XEP-0355: Namespace Delegation

- XEP-0356: Privileged Entity

- XEP-0413: Order-By

- XEP-0460: Pubsub Caching Hints

- XEP-0465: Pubsub Public Subscriptions

- XEP-0470: Pubsub Attachments

- XEP-0471: Events

- XEP-0473: OpenPGP for XMPP Pubsub

- XEP-0477: Pubsub Targeted Encryption

Additionally, several other XEPs I have authored are currently being evaluated by the council.

I have also given talks on my project and XMPP in general, and attended numerous events and summits. Working on these varied projects has provided me with extensive knowledge of various aspects of XMPP, particularly Pubsub, which is an area I am deeply interested in and wish to improve upon.

In terms of philosophy, I believe that most protoXEPs should be accepted as experimental unless there are significant conflicts or major issues. The XMPP Standards Foundation mailing list is where discussions and evolutions should take place, given its public nature and broad reach within the community. In short, I think that the council should not block proposals except in cases of major conflicts or problems; the ecosystem will naturally determine which features are implemented and used.

I believe specifications should be flexible enough to accommodate unforeseen use cases while remaining clear (using MUST and SHOULD wherever possible) to prevent unintentional implementation discrepancies. Older XEPs should be deprecated when newer ones prove better or more popular, and I advocate for namespace bumps and discovery as effective methods of handling specification evolution. Until a XEP is "stable," developers should expect significant changes; we shouldn't hold back necessary updates due to fear that implementers won't keep up.

Additionally, existing specifications should be reused wherever possible, with XMPP's own methods being prioritized whenever feasible. I believe XMPP’s scope is extensive and goes far beyond instant messaging.

Finally, contributions and work must be respected, and discussions should remain constructive, polite, and healthy even in the face of disagreement (which can indeed be vocal but not aggressive).

I have remained committed to XMPP over the years because I believe it remains one of best decentralized protocol, and most versatile communication platforms out there. I have worked hard to enhance its features beyond instant messaging, especially with Pubsub, and intend to continue doing so.