January 2025 - Standards

XMPP Council Agenda 2025-01-14
by Daniel Gultsch 14 Jan '25

14 Jan '25

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, January 14 2025 at 16:30 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update * Proposed XMPP Extension: GRE Formatter: MIME * Proposed XMPP Extension: GRE Encrypter: OpenPGP * Proposed XMPP Extension: Gateway Relayed Encryption * LAST CALL: XEP-0484 (Fast Authentication Streamlining Tokens) 4) Items for voting a) Proposed XMPP Extension: GRE Formatter: MIME https://xmpp.org/extensions/inbox/gre-formatter-mime.html b) Proposed XMPP Extension: GRE Encrypter: OpenPGP https://xmpp.org/extensions/inbox/gre-encrypter-openpgp.html c) Proposed XMPP Extension: Gateway Relayed Encryption https://xmpp.org/extensions/inbox/gateway-relayed-encryption.html 5) Pending votes * Dan on Move 'XEP-0421 (Anonymous unique occupant identifiers for MUCs)' to stable See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/1oAHUqBdlkobDcmfQ-YRMfZHGQLMWEdOFuEU… 6) Date of Next 7) AOB

1 0

Proposed XMPP Extension: GRE Encrypter: OpenPGP
by Daniel Gultsch 13 Jan '25

13 Jan '25

The XMPP Extensions Editor has received a proposal for a new XEP. Title: GRE Encrypter: OpenPGP Abstract: This GRE Encrypter uses OpenPGP to encrypt payload. URL: https://xmpp.org/extensions/inbox/gre-encrypter-openpgp.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

1 0

Proposed XMPP Extension: GRE Formatter: MIME
by Daniel Gultsch 13 Jan '25

13 Jan '25

The XMPP Extensions Editor has received a proposal for a new XEP. Title: GRE Formatter: MIME Abstract: This GRE Formatter uses Multipurpose Internet Mail Extensions (MIME) to format payload. URL: https://xmpp.org/extensions/inbox/gre-formatter-mime.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

1 0

Re: Council Voting Summary 2019-08-18
by Dave Cridland 13 Jan '25

13 Jan '25

[[Zombie Thread!!] On Sat, 24 Aug 2019 at 17:51, Jonas Schäfer <jonas(a)wielicki.name> wrote: > On Mittwoch, 21. August 2019 01:06:07 CEST Dave Cridland wrote: > > On Tue, 20 Aug 2019 at 16:58, Jonas Schäfer <jonas(a)wielicki.name> wrote: > > > On Dienstag, 20. August 2019 10:34:22 CEST Dave Cridland wrote: > > > > > *PR #808 - XEP-0045: Add Tags configuration and metadata* - > > > > > https://github.com/xsf/xeps/pull/808 > > > > > Dave: [pending] > > > > > Georg: [on-list] > > > > > Jonas: +1 > > > > > Kev: [pending] > > > > > Link: [on-list] > > > > > > > > I think I'm -1 on this. I don't think that having tags is a bad > idea, in > > > > and of itself, but I'm concerned with adding more stuff to XEP-0045. > > > > Note that I didn't say "adding more stuff to MUC". Fine with adding more stuff to MUC, but XEP-0045 ought to be Final by now, and adding yet more functionality to XEP-0045 isn't going to help that. I'm not sure this change really satisfies the spirit of Stable either. On top of that, re-reading the proposal, yes - it's just too simplistic. So even if we did put it in XEP-0045 (or rather, ram it on the side with some glue, string, and sticky-backed plastic for speed) I think it'd eventually end up with more development and that would again affect the status of XEP-0045. > > > > > In general, I think that tagging in this "dumb" way is probably never > > > > > > going > > > > > > > to be enough, and a more considered approach might be better. > > > > > > > > For what it's worth, I'm open to having my mind changed on this. > > > > > > As someone in favour of this, what do you consider "dumb" about this? > > > > Dumb as in the tags are simply "there", and therefore only of use to an > > external search engine, really. > > > > So things you can't do are filter by tag on a disco#items search, say, or > > assign some internal meaning to specific tags for state management or > > workflow or something. > > > > Put another way, I'm not sure this gives anything to build upon - it's > just > > a field of strings, and there's no indication of semantics or intended > use > > here. I can implement it easily enough from the spec, but I have no idea > > how to use it beyond "put some strings here". > > > > Quite a lot of '45 is like this already, and I'd rather not make things > > worse. > > Fair enough. Do you have a proposal with which we could provide a similar > UX > to users? > Yeah, sorry, I didn't reply to this. Well, better (5 years) late than never! Put the tagging in a different specification, and either make a registry for the tag names, or make the tags URIs (or namespaced by URIs) so they can be more safely permissionless. Pubsub nodes could probably be taggable too, via possibly the same mechanism. Once you've done this, then adding search-by-tag seems possible (and even sensible), and we can add additional semantics to particular tags safely. The most obvious thing to do would be to add a XEP-0128 form which just holds tags, make the tags URIs, and make a URI prefix that means "these are plaintext human-readable tags" - but you could of course do the tag prefix URI within the field name instead. Dave. > > kind regards, > Jonas_______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: Standards-unsubscribe(a)xmpp.org > _______________________________________________ >

1 0

Re: [XEP-0284] Shared XML Editing revival
by Goffi 09 Jan '25

09 Jan '25

Le mercredi 8 janvier 2025 20:07:04 heure normale d’Europe centrale, vous avez écrit : > On 1/8/25 9:49 AM, Peter Saint-Andre wrote: > > On 1/8/25 9:43 AM, Peter Saint-Andre wrote: > >> On 1/8/25 4:08 AM, Goffi wrote: > >>> Hello, > >>> > >>> I'm very interested in XEP-0284, and there is this PR from Link Mauve > >>> buried for years to revive it: > >>> https://github.com/xsf/xeps/pull/904 > >>> > >>> I would like to put that on council agenda, but I have the following > >>> question: > >>> > >>> - are the previous author still unreachable? I'll put their address > >>> as recipients of this email. > >> > >> I am connected to Tom on LinkedIn and Joonas is there too but I'm not > >> connected to him. If it's important, I can track them down. > > > > P.S. I have forwarded this note to a non-bouncing email address for Joonas. > > I heard back from Joonas and he is reachable but doesn't have the time > to contribute and doesn't feel that he needs to be consulted. However, > he's excited that people are still working on SXE. :-) > > Peter Great, thanks Peter! This email was sent only to me, I believe by mistake, I'm replying to standard@ as I think that it is valuable information for the Council, OK, Link Mauve is currently unresponsive, let's wait and see if he's still interested in taking over (otherwise, I can take care of it, but I hope that Link Mauve is still willing to push it to stable). Best, Goffi

2 1

UPDATED: XEP-0421 (Occupant identifiers for semi-anonymous MUCs)
by Daniel Gultsch 08 Jan '25

08 Jan '25

Version 0.3.0 of XEP-0421 (Occupant identifiers for semi-anonymous MUCs) has been released. Abstract: This specification defines a method that allows clients to identify a MUC participant across reconnects and renames. It thus prevents impersonification of semi-anonymous users. Changelog: * Adjust wording to use semi-anonymous or pseudonymous instead of anonymous * Explicitly mention issues arising from occupant id matching across rooms * Add example with server secret instead of room secret * Add some pseudocode (lmw) URL: https://xmpp.org/extensions/xep-0421.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.

3 2

[XEP-0284] Shared XML Editing revival
by Goffi 08 Jan '25

08 Jan '25

Hello, I'm very interested in XEP-0284, and there is this PR from Link Mauve buried for years to revive it: https://github.com/xsf/xeps/pull/904 I would like to put that on council agenda, but I have the following question: - are the previous author still unreachable? I'll put their address as recipients of this email. - Peter Saint-Andre is still around as the XSF Treasurer. So Peter could you tell us if you agree with this PR and with Link Mauve taking over the XEP? - Link Mauve, are you still OK with this PR and being an author of this specification? If all 3 above give green lights, Daniel would you mind adding this to Coucil agenda? Thank you all! Best, Goffi

2 3

Blasta, Libervia, and Movim
by Schimon Jehudah 08 Jan '25

08 Jan '25

Good day. I would want your advise concerning project Blasta, an annotation system based on XMPP. The project Blasta https://blasta.woodpeckersnest.eu/ is utilizing the specification Atom Over XMPP, and has insentivise me to think of a new XEP that be similar to XEP-0277 (Libervia) and XEP-0472 (Movim), which is the same without the content field. Yet the discussion to standartize bookmark structure at the buku project https://github.com/jarun/buku/discussions/795 and the structure which is used by the linkding bookmark project https://demo.linkding.link/bookmarks which does include a content field with the markdown format, which is what Movim does, has led me to think of supporting the field "content" of Atom Syndication Format. Further, the publishing project Postmill https://postmill.xyz/ works very similarly to bookmarks and forum systems, so comments, which are part of XEP-0277 (Libervia) and XEP-0472 (Movim) are also valid. Hence, I think that Blasra needs to be compatible with XEP-0277 (Libervia) and XEP-0472 (Movim) albeit its main purpose is to manage bookmarks. Please write your thoughts about this matter. Kind regards, Schimon

1 0

XMPP Council Agenda 2025-01-07
by Daniel Gultsch 06 Jan '25

06 Jan '25

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, January 7 2025 at 16:30 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update * NEW: XEP-0501 (Pubsub Stories) https://xmpp.org/extensions/xep-0501.html * NEW: XEP-0502 (MUC Activity Indicator) https://xmpp.org/extensions/xep-0502.html 4) Items for voting a) Move 'XEP-0421 (Anonymous unique occupant identifiers for MUCs)' to stable https://xmpp.org/extensions/xep-0421.html b) Move 'XEP-0424 (Message Retraction)' to stable https://xmpp.org/extensions/xep-0424.html 5) Pending votes none See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/1oAHUqBdlkobDcmfQ-YRMfZHGQLMWEdOFuEU… 6) Date of Next 7) AOB 8) Close

1 0

Encrypting PubSub node items
by Schimon Jehudah 06 Jan '25

06 Jan '25

Good day to one and all! I have been contemplating the idea of utilizing PubSub as a platform to synchronize browser bookmarks, history and tabs. See article "XMPP For Browsers" at The XMPP Newsletter of November 2024. I have received crucial criticism by the Pale Moon developers due to neglegence of encryption. It is not in my intention to neglegence encryption, yet I do not intend to add encryption before a working prototype. Schimon: > > There is no storage encryption yet. I do not know whether it is > > necessary Moonchild: > Unacceptable. > Nobody but the end user should be able to access the stored data. > Encryption is required, and encryption should be set up in such a way > that nobody aside from the end user (not even the server admin) has > access to this data. Storing everything in plaintext in an XMPP > service instance is ridiculous. That said, the owner of the server must not have any access to the data. However, I am thinking of encrypting the data, yet I do not how to implement such system which will be possible to decrypt only by the owner of the data, and I also do not know how to handle a situation in which an encryption key was lost. Links: https://forum.palemoon.org/viewtopic.php?t=31900 https://portal.mozz.us/gemini/woodpeckersnest.space/~schapps/journal/2024-1… gemini://woodpeckersnest.space/~schapps/journal/2024-11-28-xmpp-for-browsers.gmi https://xmpp.org/2024/12/the-xmpp-newsletter-november-2024/ Happy new year! Schimon

2 2