Re: [Standards] XEP-0444 update: restrict reactions

Hi, On 06.01.2023 11:01, Kevin Smith wrote: My earlier iteration of the PR did include a mechanism to fetch the available emojis (and rules, eg 1 emoji per reacter per message), but after discussion with Marvin (author), we decided that it's a bad idea, since, as you said, most instances are

Re: [Standards] Announcing Slummit 2021

On 27.01.2021 22:01, Tedd Sterr wrote: In lieu of an official Summit, I invite all interested parties to participate in the unofficial Slummit! Reply in this thread with a few short paragraphs about what you've been working on, participating in, any projects you feel others should be made aware

Re: [Standards] Proposed XMPP Extension: Service Outage Status

On 20.01.2021 15:55, Jonas Schäfer wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Service Outage Status Abstract: This document defines an XMPP protocol extension that enables a server to communicate issues with the server to all users in a semantic manner.

Re: [Standards] Proposed XMPP Extension: Service Outage Status

On 20.01.2021 17:04, Jonas Schäfer wrote: A couple notes: - I think it would be worthwhile to extend this to also include future outages. Hence, make the current root an array, or rather an object with a single property which is an array, because this is how JSON do or so. While I find the

Re: [Standards] Proposed XMPP Extension: DOAP usage in XMPP

On 13.01.2021 19:41, Sam Whited wrote: I do not believe this is an appropriate technology whether it's an existing specification or not. It's just too complicated. —Sam On Wed, Jan 13, 2021, at 19:35, Dave Cridland wrote: On Wed, 13 Jan 2021 at 18:24, Sam Whited wrote: > I'd like to

Re: [Standards] NEW: XEP-0439 (Quick Response)

On 05.05.2020 19:06, Jonas Schäfer wrote: Version 0.1.0 of XEP-0439 (Quick Response) has been released. Abstract: Quickly respond to automated messages. Changelog: Accepted by vote of Council on 2020-04-22. (XEP Editor (jsc)) URL: https://xmpp.org/extensions/xep-0439.html Note: The

Re: [Standards] Server status pages

On 24.05.2020 11:31, Dave Cridland wrote: On Sat, 23 May 2020 at 11:53, Mathieu Pasquet wrote: On 23.05.2020 11:38, Matthew Wild wrote: >On Sat, 23 May 2020, 10:51 Maxime Buquet, wrote: > >    All those who expressed feelings against adding this to 157 at the time

Re: [Standards] Bookmarks and autojoin issues

On 24.05.2020 06:50, Philipp Hörist wrote: Hi, The problem is there are no rules what goes into which profile. If i add a bookmark as a desktop client, i don't know if it should go into the mobile profile or not. And btw we try to abstract bookmarks away from the user, so managing profiles of

[Standards] Bookmarks and autojoin issues

Greetings, I want to raise an issue that appears with bookmarks in their current form in the multi-client scenario. It appears as long as we have more than one client, and gets worse for every added client and MUC bookmark. XEP-0048 and XEP-0402 both re-use the element, which has an autojoin

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On 23.05.2020 20:08, Georg Lukas wrote: [snip] This is a very short and very slippery slope. I'm sure that you are aware of the coordinated attacks on centralized social networks where trolls mass-report accounts that they disagree with. It's okay to block a certain sender JID on your own

Re: [Standards] Server status pages

On 23.05.2020 11:38, Matthew Wild wrote: On Sat, 23 May 2020, 10:51 Maxime Buquet, wrote: All those who expressed feelings against adding this to 157 at the time you sent this didn't mention why. I personally don't see much issue with it, so I just PR'd against it to add that

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On 12.09.2017 12:45, Georg Lukas wrote: * Sam Whited [2017-09-12 01:52]: I had assumed that the server would be storing things and we didn't need to send it back, but maybe that's not always the case. This does seem like the kind of thing we might need to store or send back somehow. Yeah,

Re: [Standards] Proposed XMPP Extension: Ephemeral Messages

mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___________ -- Mathieu Pasquet (mathieui) - Poezio developer ___ Standards mailing list Info: https://mail.jabber.org/mailman/li

Re: [Standards] Proposed XMPP Extension: Anonymous unique occupant identifiers for MUCs

On Mon, Jul 15, 2019 at 03:57:12PM -, Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Anonymous unique occupant identifiers for MUCs > Abstract: > This specification defines a method that allows clients to identify a > MUC participant across

[Standards] Carbons with Bind 2.0 and Routing 2.0

Hi List, Looking at XEP-0409 and XEP-386, it appears that 0409 says: > A client activating IM-NG MUST NOT also activate Carbons. while 0386 says that after binding, the server MUST: > Silently enable carbons for this session While not strictly conflicting in RFC legalese (with bind 2.0 it’s

Re: [Standards] Proposed XMPP Extension: Styling

On Mon, Nov 06, 2017 at 11:58:15AM -0600, Sam Whited wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Styling > > Abstract: > > > This specification defines a plain-text formatting syntax for use in > > exchanging instant messages with simple text styling.

Re: [Standards] Date and time period in XMPP (Was: [XEP-0097] reviving iCal in XMPP)

Hi, On Fri, Sep 08, 2017 at 09:27:26AM +0200, Goffi wrote: > > Hi, > > I'm thinking again about this date/time thing. I see that there is already > https://xmpp.org/extensions/xep-0149.html which define a simple start/stop > using XEP-0082 which seems more simple and adapted to XMPP (there

Re: [Standards] [Members] 33C3 talk on Signal and current XMPP issue in providing a similar UX

Hi, It was indeed a nice talk. On Thu, Dec 29, 2016 at 04:48:19PM -0600, Sam Whited wrote: > A few scattered thoughts after a first reading of this thread: > [snip] > > > * Current SPAM/SPIM issue needs to be addressed in some way. > > The slides (with no other context, I wasn't at the talk)

Re: [Standards] Deprecating XEP-0138: Stream Compression

On Mon, Aug 29, 2016 at 09:29:23AM +0200, Florian Schmaus wrote: > On 29.08.2016 05:29, Sam Whited wrote: > > On Sun, Aug 28, 2016 at 2:53 PM, Mathieu Pasquet <mathi...@mathieui.net> > > wrote: > >> Two years late, but can we deprecate it XEP-0138 now,

Re: [Standards] XEP-0375 (XMPP Compliance Suites 2016) clarification

On Sun, Aug 28, 2016 at 08:57:11PM +0100, Dave Cridland wrote: > On 28 August 2016 at 20:34, Mathieu Pasquet <mathi...@mathieui.net> wrote: > > On Wed, Jul 20, 2016 at 02:22:48PM +, XMPP Extensions Editor wrote: > >> Version 0.3 of XEP-0375 (XMPP Compliance Suites

Re: [Standards] Deprecating XEP-0138: Stream Compression

algorithms support here? > > I've been trying to look into LZW, as it is described by XEP 0229, but while I > can find enough descriptions of the algorithm itself, I can't find much about > the output encoding. Most of the LZW API's I've seen also have no flush-method > or somethi

[Standards] XEP-0375 (XMPP Compliance Suites 2016) clarification

mended providers must be implemented for compliance. ”, the use of “must”, with “needs to”. Otherwise one could confuse it with having a limitation of one provider for the service. Thanks -- Mathieu Pasquet (mathieui), poezio developer signature.asc Description: PGP signature _

[Standards] RFC6120 - digitalSignature bit set for the CA

-13.7.1.1 [2] https://tools.ietf.org/html/rfc3280#section-4.2.1.3 Thanks in advance, -- Mathieu Pasquet (mathieui) poezio developer signature.asc Description: PGP signature ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards

Re: [Standards] XEP-0045 join when already in MUC

On Fri, Jun 24, 2016 at 04:27:22AM +0100, Emmanuel Gil Peyrot wrote: > On Fri, Jun 24, 2016 at 12:05:46PM +1000, Daurnimator wrote: > > On 24 June 2016 at 08:35, Georg Lukas wrote: > > > Hi, > > > > > > TL;DR: whenever a client (re)sends a join, the MUC service should return > > >

Re: [Standards] wiki for xeps

don’t think that I’m overly negative, I’m just writing down some quick thoughts) -- Mathieu Pasquet (mathieui) pgpPpeL5bvUwL.pgp Description: PGP signature

Re: [Standards] OTR

On Fri, Dec 19, 2014 at 02:51:02PM -0500, Sam Whited wrote: On 12/17/2014 11:46 AM, Winfried Tilanus wrote: In response to my comment that it left a lot of information unencrypted he suggested to start a second OTR protocol in XMPP, one that does proper service discovery and properly

Re: [Standards] Get IP addresses of xmpp server( Openfire) logged in users

(as in the XEP example). I don’t know how to go around this, except by patching the server software to make it accet bigger ranges. -- Mathieu Pasquet (mathieui) pgpoxJ3jtpNHn.pgp Description: PGP signature

Re: [Standards] XEP-280 and MUC private chats

On Tue, Jul 16, 2013 at 01:02:36PM -0600, Peter Saint-Andre wrote: On 7/14/13 1:13 PM, Mathieu Pasquet wrote: On Sun, Jul 14, 2013 at 05:36:51PM +0100, Kevin Smith wrote: On Sun, Jun 9, 2013 at 7:40 PM, Mathieu Pasquet mathi...@mathieui.net wrote: I was starting to implement carbons

Re: [Standards] XEP-280 and MUC private chats

On Sun, Jul 14, 2013 at 05:36:51PM +0100, Kevin Smith wrote: On Sun, Jun 9, 2013 at 7:40 PM, Mathieu Pasquet mathi...@mathieui.net wrote: I was starting to implement carbons in poezio when I came across some kind of design issue that I haven’t been able to work out. As I understand

[Standards] XEP-280 and MUC private chats

there is no way to distinguish those. I think the XEP should cover that case, because it is rather common to have private conversations with people in a groupchat, and letting clients guess how they should handle the message is very error-prone. -- Mathieu Pasquet - poezio developer

Re: [Standards] DRAFT: XEP-0308 (Last Message Correction)

, it MAY apply a correction from a different fullJID, (different resource) as long as it knows it is the same entity (which contradicts with “A correction MUST only be allowed when both the original message and correction are received from the same full-JID.”). -- Mathieu Pasquet - Poezio Developer

[Standards] XEP-0196 modification

a hostname:port string in the server_address/ element (not to mention ipv6 addresses). -- Mathieu Pasquet

Re: [Standards] NEW: XEP-0317 (Hats)

can be list-multi instead of list-single. Mathieu Pasquet (mathieui)

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

than underline, relative margins, etc). -- Mathieu Pasquet (mathieui) signature.asc Description: OpenPGP digital signature