Difference between revisions of "User:Moparisthebest/Council Candidacy 2021"
(Created page with "== Contact == * Name: Travis Burtrum * Nickname: moparisthebest * github: [https://github.com/moparisthebest moparisthebest] * fediverse: [https://moparisthe.best/moparisthebe...") |
m |
||
| Line 12: | Line 12: | ||
I've written 2 XEPs that were accepted, [https://xmpp.org/extensions/xep-0368.html XEP-0368] and [https://xmpp.org/extensions/xep-0418.html XEP-0418], and one that was not [https://xmpp.org/extensions/inbox/hacx.html HACX]. | I've written 2 XEPs that were accepted, [https://xmpp.org/extensions/xep-0368.html XEP-0368] and [https://xmpp.org/extensions/xep-0418.html XEP-0418], and one that was not [https://xmpp.org/extensions/inbox/hacx.html HACX]. | ||
Recently I've found a security vulnerability, [https://www.moparisthebest.com/eatxmempp-cve-2021-32918/ eatxmempp: CVE-2021-32918], and written [https://github.com/moparisthebest/xmpp-proxy xmpp-proxy] to both mitigate that, and experiment with various XMPP transports, including QUIC and S2S-over-WebSocket. | Recently I've found a security vulnerability, [https://www.moparisthebest.com/eatxmempp-cve-2021-32918/ eatxmempp: CVE-2021-32918], and written [https://github.com/moparisthebest/xmpp-proxy xmpp-proxy] to both mitigate that, and experiment with various XMPP transports, including QUIC and S2S-over-WebSocket (XEPs to come). | ||
If I had to pick a goal/passion when it comes to XMPP, it would have to be connectivity. After all, if a user is faced with a "cannot connect" error, nothing else matters. | If I had to pick a goal/passion when it comes to XMPP, it would have to be connectivity. After all, if a user is faced with a "cannot connect" error, nothing else matters. | ||
Revision as of 15:09, 7 November 2021
Contact
- Name: Travis Burtrum
- Nickname: moparisthebest
- github: moparisthebest
- fediverse: moparisthebest@moparisthe.best
- XMPP address: travis@burtrum.org
- Email address: travis@burtrum.org
About Me
I'm just your average programmer interested in open source, federation, e2e encryption, and running my own services to avoid reliance on 3rd parties.
I've written 2 XEPs that were accepted, XEP-0368 and XEP-0418, and one that was not HACX.
Recently I've found a security vulnerability, eatxmempp: CVE-2021-32918, and written xmpp-proxy to both mitigate that, and experiment with various XMPP transports, including QUIC and S2S-over-WebSocket (XEPs to come).
If I had to pick a goal/passion when it comes to XMPP, it would have to be connectivity. After all, if a user is faced with a "cannot connect" error, nothing else matters.
Council Goals
Accept Early Accept Often: ProtoXEPs should be accepted as experimental if they are clearly written (ie, can someone read this an implement it) and solve a problem. It doesn't matter if they solve a problem another XEP has already attempted to solve but in a different way. It's not council's job to decide which way is better, that decision should be left up to "running code" (ie implementations).
What follows from that is XEPs that have stood the test of time and are widely implemented need moved to Stable aggressively, and XEPs that have been abandoned need Deferred/Deprecated as appropriate.