- Standards

XEP-0484: Fast Authentication Streamlining Tokens and TLS Early Data example

by Michael Uvarov

Hi, I cannot figure out how to use early data in XEP-0484. Main question, which part does go into the early data? <authenticate/> stanza? And how does it combine with XML stream start? How does the server should reply and when? It would be nice to have the complete example for successful auth, including indication of what goes into early data and what does not. Maybe people who already implemented early data in XEP-0484 could comment. https://xmpp.org/extensions/xep-0484.html

1 year

2
2
0 0

UPDATED: XEP-0474 (SASL SCRAM Downgrade Protection)

by Daniel Gultsch

Version 0.4.0 of XEP-0474 (SASL SCRAM Downgrade Protection) has been released. Abstract: This specification provides a way to secure the SASL and SASL2 handshakes against method and channel-binding downgrades. Changelog: * Use better value delimiter (tm) URL: https://xmpp.org/extensions/xep-0474.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.

1 year, 1 month

1
0
0 0

UPDATED: XEP-0424 (Message Retraction)

by Daniel Gultsch

Version 0.4.2 of XEP-0424 (Message Retraction) has been released. Abstract: This specification defines a method for indicating that a message should be retracted. Changelog: * Use a XEP-0425 /me command in the fallback body * State that a tombstone's <retracted/> element's 'id' attribute should match the retraction message's 'id'. * Specify XEP-0359 as a dependency and require that the stanza 'id' be used instead of the origin-id. * Update the "Security Considerations" to mention the risk of non- unique message IDs. (jcb) URL: https://xmpp.org/extensions/xep-0424.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.

1 year, 1 month

1
0
0 0

Proposed XMPP Extension: Gateway Relayed Encryption

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Gateway Relayed Encryption Abstract: This specification describes a mechanism for end-to-end encryption with gateways that is compatible with third-party networks. URL: https://xmpp.org/extensions/inbox/gateway-relayed-encryption.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

1 year, 1 month

5
10
0 0

Media sharing with Metalinks

by Schimon Jehudah

Greetings! I am drafting a post to next Tuesday evening about Metalink. I did a superficial search, and I did not find a mention of Metalink in the XEP index. Metalink is known as standard RFC 5854, and RFC 6249. > Metalink supports listing of multiple partial and full file hashes > along with PGP signatures. It supports listing any URI (i.e. FTP, > Gemini, HTTP, rsync, BitTorrent, eD2k, IPFS, magnet link etc.). It also has a "description" field, which is crucial in messaging system, as it can save the effort of sending an extra message to describe the content. This saves in half the number of messages upon sharing files via messages. See the example Metalink file in the following post. https://portal.mozz.us/gemini/woodpeckersnest.space/~schapps/journal/2024-1… In the example Metalink file, the content is available via BitTorrent, eD2k, FTP, HTTP, and Kad. Handling Metalink would be of benefit to XMPP. Sending of a file: > http://hfu.xmpp.i2p/StealThisFilm.Part1.avi > This is the first part of the movie "Steal This Film I" from 2006. Sending of a Metalink file: > http://hfu.xmpp.i2p/StealThisFilm.Part1.metalink XMPP client parses the Metalink file (StealThisFilm.Part1.metalink), and displays the given description which is found in that file. I advise to create an XEP for handling of Metalinks. I would be greateful to whom who would want to intstruct me. Kind regards, Schimon

1 year, 1 month

1
1
0 0

STABLE: XEP-0421 (Occupant identifiers for semi-anonymous MUCs)

by Daniel Gultsch

Version 1.0.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: Accept as Stable as per Council Vote from 2025-01-14. (XEP Editor (dg)) 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.

1 year, 1 month

1
0
0 0

XMPP Council Agenda 2025-01-14

by Daniel Gultsch

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 year, 1 month

1
0
0 0

Proposed XMPP Extension: GRE Encrypter: OpenPGP

by Daniel Gultsch

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 year, 1 month

1
0
0 0

Proposed XMPP Extension: GRE Formatter: MIME

by Daniel Gultsch

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 year, 1 month

1
0
0 0

Re: Council Voting Summary 2019-08-18

by Dave Cridland

[[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 year, 1 month

1
0
0 0

2026

2025

2024

2023

Standards