- Standards

Re: [XEP-0284] Shared XML Editing revival

by Goffi

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

3 months, 3 weeks

2
1
0 0

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

by Daniel Gultsch

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 months, 3 weeks

3
2
0 0

[XEP-0284] Shared XML Editing revival

by Goffi

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

3 months, 3 weeks

2
3
0 0

Blasta, Libervia, and Movim

by Schimon Jehudah

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

3 months, 3 weeks

1
0
0 0

XMPP Council Agenda 2025-01-07

by Daniel Gultsch

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

3 months, 4 weeks

1
0
0 0

Encrypting PubSub node items

by Schimon Jehudah

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

3 months, 4 weeks

2
2
0 0

Join us at the 27th XMPP Summit

by Daniel Gultsch

Hi, as a member of the SCAM Team¹ I’m proud to announce that the 27th XMPP Summit will take place on Thursday January 30th and Friday January 31st 2025 in Brussels, Belgium. As usual we picked the two days before FOSDEM² takes place in the same city. https://wiki.xmpp.org/web/Conferences/Summit_27 If you are planning on coming please sign up on the wiki. (We have somewhat limited capacity) If you are unsure if the Summit is right for you, I (not in my capacity as a member of the SCAM team) wrote a short thread on Mastodon describing what the Summit typically looks like: https://gultsch.social/@daniel/113385481055735606 See you in Brussels! cheers Daniel ¹: Summits Conferences & Meetups Team https://xmpp.org/about/xsf/scam-team/ ²: https://fosdem.org/2025/

3 months, 4 weeks

1
1
0 0

LAST CALL: XEP-0421 (Anonymous unique occupant identifiers for MUCs)

by Daniel Gultsch

This message constitutes notice of a Last Call for comments on XEP-0421. Title: Anonymous unique occupant identifiers for MUCs Abstract: This specification defines a method that allows clients to identify a MUC participant across reconnects and renames. It thus prevents impersonification of anonymous users. URL: https://xmpp.org/extensions/xep-0421.html This Last Call begins today and shall end at the close of business on 2025-01-06. Please consider the following questions during this Last Call and send your feedback to the standards(a)xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!

4 months

3
3
0 0

Id risks

by Dave Cridland

Hi all, Further to the note in the LC thread on XEP-0424, I'd really like to have a document (XEP, probably) that answers these questions: What are the risks of choosing an stanza identifier that is not unique? Does this still matter if the stanza identifier is unique to the session? To the sending jid? To the bare jid of the sender? What about missing off the stanza id attribute entirely? What about MUC? PubSub? Etc? If people have opinions, write away, and I'll volunteer to collate these into a XEP (or, possibly, a patch against XEP-0359). My reasoning is that we seem to vaguely know things can get Bad, but I for one can't find where we've documented these Bad Things. I'd be delighted to be corrected, as ever. Dave.

4 months, 1 week

2
2
0 0

XEP-0001 Changes to reflect current practice wrt XEP Authors

by Dave Cridland

Hey hey, Boring incoming: https://github.com/xsf/xeps/pull/1407 This is draft to avoid the XSF Board accidentally approving it before the community has had a chance to discuss. The main change is the paragraph added in Section 6 (Discussion Process), covering changes to the XEP during Experimental: The XEP author incorporates the feedback by creating source control patches > (such as Pull Requests), in line with the preferred method in &xep0143;. > Direct changes to an Experimental XEP, such as a contributor providing a > patch (or Pull Request on GitHub), are still the responsibility of the XEP > author, and are only applied if the XEP author agrees. If a XEP has > multiple authors, while agreement is sought from all authors, only those > opinions from responsive authors are considered. If the Approving Body > feels that the XEP author is not responsive, another author may be added > unilaterally by the Approving Body. This is trying to do two things: 1) Document the existing practice that the XMPP Council has followed, whereby changes to Experimental XEPs need "agreement" (PR approval, or similar) from the XEP Author. 2) Document the existing practice that the XMPP Council has followed. whereby if a XEP Author isn't responsive (ie, doesn't respond to emails, etc) the XMPP Council can add a new XEP Author. 3) Document the *new practice* that if a contribution isn't a PR, it's the XEP Author who is responsible to turn it into one. The rest of the changes surface and restate existing process/policy/URLs and aren't that interesting (well, even less interesting). There is one additional possible process deviation we should document (or call the Process Police out, or something). Submission of a XEP, as per XEP-0143, occurs via email tot he Editor. Is this really still the case? Or are these now by PR? That'll need changing in XEP-0143, which I'm happy to do if that's the case. It'd be nice to have a non-PR variant of the process (post here?) Dave.

4 months, 1 week

6
16
0 0

2025

2024

2023

Standards ----- 2025 ----- May 2025 April 2025 March 2025 February 2025 January 2025 ----- 2024 ----- December 2024 November 2024 October 2024 September 2024 August 2024 July 2024 June 2024 May 2024 April 2024 March 2024 February 2024 January 2024 ----- 2023 ----- December 2023

Standards