[Standards] Council minutes, 20170215

XSF Council Minutes 15 February 2017 Present: daniel, Tobias, Link Mauve, SamWhited Minute taker: jcbrand 1). Vote on accepting https://xmpp.org/extensions/inbox/sasl2.html as Experimental XEP Link Mauve, daniel, Tobias and SamWhited all said that they'll

[Standards] XSF Council Minutes: 28 February 2017

XSF Council Minutes: 28 February 2017 = Present: daniel, Tobias, Link Mauve, SamWhited, Dave Cridland Minute taker: jcbrand 1). Clarify CSI and Carbons state after SM resumption Tobias: Flow created PRs which clarify things and asked council to review. Would

[Standards] 2017-04-12 XSF Council Minutes

2017-04-12 XSF Council Minutes == Present: daniel, Tobias, Link Mauve, SamWhited, Dave Cridland Minute taker: jcbrand 1). Link Mauve's SHA-1 migration review Link Mauve: No new news on this. 2). Date of next meeting Tobias: Next week usual time. Works for the rest,

[Standards] 2017-04-19 XSF Council Minutes

2017-04-19 XSF Council Minutes == Present: Tobias, Link Mauve, SamWhited, daniel Minute taker: jcbrand 1). Link Mauve's SHA-1 migration plan Nothing new to report from Link Mauve. Tobias offered to help and Link Mauve accepted, saying that he'll share his

[Standards] 2017-09-20 XSF Council Minutes

2017-09-20 XSF Council Minutes == Present: Tobias, Link Mauve, SamWhited, jonasw, daniel Minute taker: jcbrand 1) Vote on accepting "Consistent Color Generation" as Experimental XEP Tobias will vote on the mailing list +1 from daniel, SamWhited and Link Mauve 2)

[Standards] 2017-09-27 XSF Council Minutes

2017-09-27 XSF Council Minutes == Present: Tobias, SamWhited, daniel, dwd Minute taker: jcbrand 1) Vote on "XEP-0060: Add pubsub#multi-items in Publish-Subscribe features #500" The URL: https://github.com/xsf/xeps/pull/500 Tobias, daniel and SamWhited will all

[Standards] 2017-11-15 XSF Council Minutes

2017-11-15 XSF Council Minutes == Chat Logs: http://logs.xmpp.org/council/2017-11-15 Chair: * Tobias Markmann (Tobias) Present: * Sam Whited (SamWhited) * Dave Cridland (dwd) * Daniel Gultsch (daniel) * Emmanuel Gil Peyrot (Link Mauve) Minute taker: * JC Brand

[Standards] 2017-11-08 XSF Council Minutes

2017-11-08 XSF Council Minutes == Chat Logs: http://logs.xmpp.org/council/2017-11-08 Chair: * Emmanuel Gil Peyrot (Link Mauve) Present: * Sam Whited (SamWhited) * Dave Cridland (dwd) * Daniel Gultsch (daniel) * Tobias Markmann (Tobias) Minute taker: * JC Brand

Re: [Standards] 2017-11-08 XSF Council Minutes

Am 8. November 2017 17:56:26 MEZ schrieb Jonas Wielicki <jo...@wielicki.name>: >On Mittwoch, 8. November 2017 17:49:26 CET JC Brand wrote: >> jonasw asks that the previously rejected ProtoXEP "Body Markup Hints" >be >> reconsidered as a means to bridge the

Re: [Standards] Proposed XMPP Extension: Message Markup

On Wed, Nov 08, 2017 at 10:14:43AM +0100, Jonas Wielicki wrote: > On Mittwoch, 8. November 2017 08:44:16 CET Remko Tronçon wrote: > > Hi, > > > > On 7 November 2017 at 21:34, Jonas Wielicki wrote: > > > The XMPP Extensions Editor has received a proposal for a new XEP. > > >

[Standards] 2017-11-01 XSF Council Minutes

2017-11-01 XSF Council Minutes -- Chat Logs: http://logs.xmpp.org/council/2017-11-01 Chair: * Emmanuel Gil Peyrot (Link Mauve) Present: * Sam Whited (SamWhited) * Dave Cridland (dwd) * Daniel Gultsch (daniel) Minute taker: * JC Brand (jcbrand) --- 1) XEP-0146

[Standards] 2017-10-25 XSF Council Minutes

2017-10-25 XSF Council Minutes -- Chat Logs: http://logs.xmpp.org/council/2017-10-25 Present: Tobias (chairing), SamWhited, daniel, dwd, Link Mauve Minute taker: jcbrand 1) Discussion on obsoleting XHTML-IM Trello link:

Re: [Standards] Maintaining a list of ongoing conversations

Am 14. Mai 2018 12:40:31 MESZ schrieb "Ненахов Андрей" : >We are working on extension that we call by provisional name >'conversation >metadata' which is basically a list of all conversations with unread >messages counters and read/delivered markers. I believe

[Standards] Maintaining a list of ongoing conversations

Hi folks I'm interested in finding a way to keep track of ongoing conversations and whether any new messages were added to them since the user was last online. I think this is the so-called "Inbox" feature that was brought up at the 2018 summit. At the summit the suggested approach was a

Re: [Standards] Maintaining a list of ongoing conversations

can also be pushed. - JC >On 14 May 2018 at 12:28, JC Brand <[4]li...@opkode.com> wrote: > > Hi folks > > I'm interested in finding a way to keep track of ongoing conversations > and > whether any new messages were added to them since the

Re: [Standards] Group chat protocol

On Sun, Jun 03, 2018 at 07:30:48PM +0500, Ненахов Андрей wrote: >To whom it may concern, we're working on group chat solution for XMPP. >It is quite a simple solution that we feel is good enough to counter most >issues of XEP-0045. Is this an extension/modification of XEP-0045, or is

Re: [Standards] XEP-0384: Staleness of devices

Am 28. August 2018 16:42:13 MESZ schrieb "Philipp Hörist" : >Yes you can call this a Heartbeat message, but it doesnt solve the >Problem >it only makes it less likely. > >I as a client developer want to secure my users Communication, i cant >depend for that on other devices sending me Heartbeat

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

Am 22. März 2018 08:28:21 MEZ schrieb Matthew Wild : >On 21 March 2018 at 17:27, Maxime Buquet wrote: >> On 2018/03/21, Sam Whited wrote: >>> On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote: >>> > I’d argue (and did at the Summit) that the opposite is true

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

On Tue, Mar 20, 2018 at 05:27:05PM +0100, Daniel Gultsch wrote: > The security section needs a bit about the correct use of > publish-options or developers will get that wrong. I updated the security section of the XEP in a branch a few days ago already, but the change is still in a PR.

Re: [Standards] Private Data storage discrepancy

On Fri, Mar 16, 2018 at 12:32:57PM +0100, Timothée Jaussoin wrote: > Hi Guus, > > Thanks for the work on Bookmarks :) Indeed that was, I think, a mistake. > On my side I followed the structure of the 0048 > (https://github.com/movim/moxl/blob/master/src/Moxl/Stanza/Bookmark.php#L30) > which, I

Re: [Standards] XEP-0308: LMC of a previous correction

On Tue, Apr 02, 2019 at 12:06:20PM +0200, Georg Lukas wrote: > While message reordering doesn't exist in XMPP (at least in theory), the > "blockchain" of corrections provides a cleanly ordered relation over all > corresponding corrections, whereas with the 'right' way, all corrections > are

Re: [Standards] XEP-0308: LMC of a previous correction

On Tue, Apr 02, 2019 at 02:15:24PM +0200, Georg Lukas wrote: > > > While message reordering doesn't exist in XMPP (at least in theory), > > > [...] all corrections are equal and the latest one wins. > > …which is fine, AFAICS. > > While a little bit tongue-in-cheek, my comment was intended to

[Standards] XEP-0372 References: Real JID used for groupchat messages

Hi everyone In section 3.2 of XEP-0372, the groupchat example includes the real JID of the participant, instead of their room JID. See https://xmpp.org/extensions/xep-0372.html#usecase_mention For anonymous or semi-anonymous rooms this is a privacy leak. Is there any particular reason why the

Re: [Standards] Message Retractions

ion [3] and, like Reactions, it's > being held-up by the current 'message attachment' contention. I'm a bit out of the loop here, can someone please explain to me what the "message attachment" contention is in regards to message retractions? - JC On Wed, Sep 04, 2019 at 11:21:40AM +0

[Standards] Message Retractions

Hi folks I'm going to implement message retractions for Converse.js and while researching what's available XEP-wise I came across this proposed XEP from Lance Stout: https://xmpp.org/extensions/inbox/message-retraction.html It's from 2016 and was never accepted (i.e. assigned a XEP number). I

Re: [Standards] Persisting Message Errors (XEP-0280, XEP-0313, XEP-0160)

On Thu, Aug 01, 2019 at 01:08:49PM +0200, Georg Lukas wrote: > Hi, > > error type stanzas are currently ephemeral, and not taken seriously by > many (client) developers. As one step in increasing the (perceived) > reliability of XMPP messaging, I'd like to make message errors > persistent, so

Re: [Standards] Proposed XMPP Extension: Message Fastening

Am 7. September 2019 15:03:49 MESZ schrieb Andrew Nenakhov : >Seems like a copy of XEP-0367 Message Attaching. It also shares the >same >problem: no explanation whatsoever on how to fetch these attachments >from a >Message Archive in any efficient way. Ideally, we should retrieve a >message

Re: [Standards] CS-2019 Badges - Who Cares?!

B, but I'd prefer that it looks similar to the shields.io badges. Am 22. Juli 2019 17:38:00 MESZ schrieb Tedd Sterr : >There appears to be a lack of interest, which is fair enough, but just >to check opinion… > >Reply with a choice from one of the below; or don't - I'm not your >boss. > >A. I'm

Re: [Standards] Message Retractions

On Tue, Sep 24, 2019 at 10:40:30AM +0200, Maxime Buquet wrote: > On 2019/09/23, JC Brand wrote: > > Based on our off-list discussion, I'm going to go with sending an IQ to the > > MUC > > JID in order to ask for a message to be retracted. > > > > The MUC then

Re: [Standards] Message Retractions

ter myself up and speed up > translation to English. I asked Google to translate it, but only half of the document got translated. > ср, 4 сент. 2019 г. в 14:22, JC Brand : > > > > Hi folks > > > > I'm going to implement message retractions for Converse.js and while &

Re: [Standards] Message Retractions

On Tue, Sep 24, 2019 at 04:29:47PM +0200, Maxime Buquet wrote: > On 2019/09/24, JC Brand wrote: > > On Tue, Sep 24, 2019 at 10:40:30AM +0200, Maxime Buquet wrote: > > > What about looking at it the other way around? 1:1 being the general > > > case and MUC somet

Re: [Standards] Message Retractions

On Tue, Sep 24, 2019 at 03:40:22PM +0200, Georg Lukas wrote: > * JC Brand [2019-09-24 15:10]: > > > Additionally in MUCs, one could send an IQ to the room so that the MUC > > > itself broadcasts it to all participants of that room. > > I don't like the idea of th

Re: [Standards] Support for stickers (custom emojis)

On Sat, Oct 19, 2019 at 04:41:19PM +, Sam Whited wrote: > On Sat, Oct 19, 2019, at 04:57, JC Brand wrote: > > You might still have an offset in between two codepoints that should > > ideally be shown together like "EU" making the EU flag, but this seems > > less

Re: [Standards] Support for stickers (custom emojis)

e "EU" making the EU flag, but this seems less of an issue to me. I therefore think we should just do the same for XEP-0372. It would in any case be crazy to specify one way of doing things in XEP-0394 and another in XEP-0372. JC > On Thu, Oct 17, 2019, at 10:07, JC Brand wr

Re: [Standards] Support for stickers (custom emojis)

entity to ask? How are stickers added to the entity's cache? How does the client know which stickers it can send, i.e. which stickers are contained in the cache? These are all things not spec'd in BOB. Ideally I'd like to implement something that works in 2019/2020. > Marvin > &

Re: [Standards] Support for stickers (custom emojis)

e referenced by the > CID 0231 §2.1 says that you can send the IQ to request the bytes to > "potentially some other entity". If you don't expect the sending client > to provide the file, it doesn't need to cache all stickers and it > doesn't need to be onlin

[Standards] Support for stickers (custom emojis)

Hello I'm currently working on adding support for non-unicode emojis to Converse.js. Currently, users can't upload their own images to be used for custom emojis, mostly because Converse is a thin client with no backend support for it. So to add custom emojis, the web host needs to edit a

Re: [Standards] A Short Note about "Tedd Sterr"

Thank you Tedd , for the excellent work you're doing recording the minutes and the voting. It's been a big help for me as well, as I'm sure for many others. And here I thought Tedd was your real name. 樂 Am 26. November 2019 01:18:31 MEZ schrieb Tedd Sterr : >I saw the title and started

Re: [Standards] Message Retractions

On Wed, Sep 04, 2019 at 08:38:45AM -0700, Lance Stout wrote: > I don't see any specific reason in the archives why the XEP wasn't > advanced, > except that apparently enthusiasm for it fizzled out. > > I'm not the author of the proposed XEP, but I'd like to see whether this >

Re: [Standards] Message Retractions

be correcting a message (on another user's behalf) or flagging a message. Here are the relevant Github PRs: * Message retractions: https://github.com/xsf/xeps/pull/832 * Message moderation: https://github.com/xsf/xeps/pull/833 On Tue, Sep 24, 2019 at 06:35:35PM +0200, JC Brand wrote: > On

Re: [Standards] Message Retractions

On Wed, Sep 25, 2019 at 06:11:25PM +0500, Andrew Nenakhov wrote: > вт, 24 сент. 2019 г. в 21:30, JC Brand : > > > However, this method is 'server-centric', cause it requires a server > > > to calculate edit versions so that offline clients can check it there > > > w

Re: [Standards] Message Retractions

Am 25. September 2019 15:59:46 MESZ schrieb Andrew Nenakhov : >ср, 25 сент. 2019 г. в 18:57, JC Brand : >> > If by "MAM catchup" you mean fetching all messages in a >conversation, >> > well, this CAN be handled this way, but it was exactly what we

Re: [Standards] Feedback to Compliance Suites 2020

On Thu, Oct 10, 2019 at 11:01:56AM +0300, Evgeny wrote: > On Thu, Oct 10, 2019 at 10:52 AM, JC Brand wrote: > > You're arguing against a point nobody made. > > > > Nobody advocated using BOSH to bypass restrictions in XEP-0198. > > The issue Georg mentioned isn't

Re: [Standards] Feedback to Compliance Suites 2020

On Wed, Oct 09, 2019 at 09:13:59PM +0200, Jonas Schäfer wrote: > On Mittwoch, 9. Oktober 2019 21:01:18 CEST JC Brand wrote: > > On Wed, Oct 09, 2019 at 05:24:49PM +0200, Georg Lukas wrote: > > > * Evgeny [2019-10-09 17:08]: > > > > I would like to see BOSH dropped an

Re: [Standards] Feedback to Compliance Suites 2020

On Wed, Oct 09, 2019 at 10:24:54PM +0300, Evgeny wrote: > On Wed, Oct 9, 2019 at 10:20 PM, Evgeny wrote: > > I still doubt this is anyhow more secure than session resumption in > > XEP-0198 (which btw requires real re-authentication). > > Let me explain: using BOSH to bypass restriction of

Re: [Standards] Council Voting Summary 2019-10-08

Am 10. Oktober 2019 12:38:53 MESZ schrieb Kevin Smith >> Proposed XMPP Extension: Message Moderation - >https://xmpp.org/extensions/inbox/message-moderation.html > >> Dave: [pending] >> Georg: [on-list] >> Jonas: [on-list] >> Kev:

Re: [Standards] Feedback to Compliance Suites 2020

On Wed, Oct 09, 2019 at 04:56:54PM +0200, Jonas Schäfer wrote: > - Should we really require both BOSH and WebSockets for the Web Suite for > clients? Maybe it makes more sense to require it both for Servers, but only > one of them for clients, possibly even phasing out BOSH. (Disclaimer: I’m not

Re: [Standards] Feedback to Compliance Suites 2020

On Wed, Oct 09, 2019 at 05:24:49PM +0200, Georg Lukas wrote: > * Evgeny [2019-10-09 17:08]: > > I would like to see BOSH dropped and moving the XEP to historical or > > deprecated state, because I see zero advantages over Websockets now > > (supporting both XEP-0198 and BOSH makes no sense at

Re: [Standards] Feedback to Compliance Suites 2020

On Wed, Oct 09, 2019 at 06:32:12PM +0300, Evgeny wrote: > On Wed, Oct 9, 2019 at 6:27 PM, Evgeny wrote: > > According to such logic this "problem" should be resolved for plain TCP > > c2s as well. Unless it's not solved we should not kill BOSH. > > Ah, and another question is raising: why

Re: [Standards] Call for Experience: XEP-0198: Stream Management

On 26.02.20 12:25, Andrew Nenakhov wrote: пт, 21 февр. 2020 г. в 14:33, JC Brand : I have worked on deployments where Converse.js is integrated together with roster and presences and/or MUC presences and where pages are regularly reloaded (i.e. not a single-page app). Btw, I assume you use

Re: [Standards] NEW: XEP-0425 (Message Moderation)

Am 24. Januar 2020 15:03:01 MEZ schrieb "Jonas Schäfer" : > > >23 Jan 2020 10:19:49 pm Paul Schaub : > >> Hi everyone! >> >> I have a question regarding the element. Is the text content >> inside the reason element mandatory? If so, what should be a default >> reason text. If not, is is okay to

Re: [Standards] NEW: XEP-0430 (Inbox)

Am 3. Februar 2020 19:54:29 MEZ schrieb Florian Schmaus : >On 29.01.20 15:21, Jonas Schäfer (XSF Editor) wrote: >> Version 0.1.0 of XEP-0430 (Inbox) has been released. >> >> Abstract: >> This specification proposes a mechanism by which clients can find a >> list of ongoing conversations and

Re: [Standards] Call for Experience: XEP-0198: Stream Management

On 20.02.20 20:57, Andrew Nenakhov wrote: чт, 20 февр. 2020 г. в 16:05, JC Brand <mailto:li...@opkode.com>>: > > Through the message archive and with our device sync protocol. > What if you had only one device and presence stanzas were sent during > the disconnection? >

Re: [Standards] Call for Experience: XEP-0198: Stream Management

On 20.02.20 11:49, Florian Schmaus wrote: On 20.02.20 11:24, JC Brand wrote: On 13.02.20 21:13, Florian Schmaus wrote: On 2/11/20 4:21 PM, Jonas Schäfer (XSF Editor) wrote: The XEP Editor would like to Call for Experience with XEP-0198 before presenting it to the Council for advancing

Re: [Standards] Call for Experience: XEP-0198: Stream Management

On 20.02.20 11:37, Andrew Nenakhov wrote: чт, 20 февр. 2020 г. в 15:33, JC Brand : For what it's worth, our iOS and web versions work perfectly fine without XEP-0198. Android version will have it removed, too. Restoring a state > resumption of a stream. How are you able to receive stan

Re: [Standards] Call for Experience: XEP-0198: Stream Management

On 13.02.20 21:13, Florian Schmaus wrote: On 2/11/20 4:21 PM, Jonas Schäfer (XSF Editor) wrote: The XEP Editor would like to Call for Experience with XEP-0198 before presenting it to the Council for advancing it to Final status. With the advent of WebSockets and QUIC around the corner, we

Re: [Standards] Call for Experience: XEP-0198: Stream Management

On 14.02.20 11:06, Andrew Nenakhov wrote: пт, 14 февр. 2020 г. в 14:03, Dave Cridland : With the advent of WebSockets and QUIC around the corner, we shouldn't miss the opportunity to allow stream resumption over different transports (TCP, BOSH, WebSocket, QUIC, …). I think people do that

Re: [Standards] Call for Experience: XEP-0198: Stream Management

On 11.02.20 16:21, Jonas Schäfer (XSF Editor) wrote: The XEP Editor would like to Call for Experience with XEP-0198 before presenting it to the Council for advancing it to Final status. During the Call for Experience, please answer the following questions: 1. What software has XEP-0198

Re: [Standards] LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))

Am 30. Januar 2020 11:44:33 MEZ schrieb "Jonas Schäfer" : >On Donnerstag, 30. Januar 2020 08:45:22 CET Daniel Gultsch wrote: >> Am Mi., 29. Jan. 2020 um 16:34 Uhr schrieb Jonas Schäfer >: >> > 5. Is the specification accurate and clearly written? >> >> I share Sam’s concerns regarding the

Re: [Standards] Proposed XMPP Extension: MUC presence versioning

On 01.04.20 08:48, Philipp Hancke wrote: Am 31.03.20 um 20:35 schrieb Jonas Schäfer (XSF Editor): The XMPP Extensions Editor has received a proposal for a new XEP. Title: MUC presence versioning Abstract: This specification defines a versioning mechanism which reduces the amount of presence

Re: [Standards] Proposed XMPP Extension: MUC presence versioning

On 01.04.20 16:27, Georg Lukas wrote: Hi together, * Jonas Schäfer [2020-03-31 20:39]: Title: MUC presence versioning This is an awesome extension to the MUC protocol, and I think it fits in well. Next step is to re-organize the MUC membership query from four IQs to something with

Re: [Standards] XEP-0424: Service discovery on the server side

Hi Pawel, sorry for taking so long to respond, this email didn't come up on my radar. On Mon, May 04, 2020 at 01:48:52PM +0200, Pawel Chrzaszcz wrote: 8-< >According to the XEP: "If a client or service implements message >retraction, it MUST specify the

Re: [Standards] Very Simple Questions about Compliance Suites

On 02.09.20 17:23, Dave Cridland wrote: Hey all, Really simple questions, so please do reply and answer: If you have an XMPP product or public project, do you claim compliance with XEP-0423? Converse is about 80% compliant. https://github.com/conversejs/converse.js/issues/1398 I think

Re: [Standards] XEP-0424: Service discovery on the server side

archive or cache, but which might still be stored client-side, and the correct thing to do then is to simply relay the retraction to the recipient. Regards JC On Sun, May 17, 2020 at 10:14 PM JC Brand <mailto:li...@opkode.com>> wrote: Hi Pawel, sorry for taking so long t

Re: [Standards] Off-by-one error in XEP-372 "References"

substrings are adjacent, then the 'end' of the first matches the 'begin' of the second. This also appears to be the convention most people in the thread appeared to agree with. - JC On 04.12.20 13:31, JC Brand wrote: Hey folks In XEP-0372 in section 3.1, there is the following text: An end

[Standards] Off-by-one error in XEP-372 "References"

Hey folks In XEP-0372 in section 3.1, there is the following text: An end attribute is similarly used for the index of the last character of the reference However, in the example in 3.2, the "end" attribute is set to 78, which is the index of the space after the nickname "Juliet". The

[Standards] MUC Mention Notifications

Hi all I've submitted a PR for a new protoXEP: MUC Mention Notifictions https://github.com/xsf/xeps/pull/1022 The goal is to document how someone who's affiliated, but not currently present in a MUC might receive notifications when he/she is mentioned inside that MUC. For the concept of

Re: [Standards] MUC Mention Notifications

On 18.12.20 19:10, Dave Cridland wrote: On Fri, 18 Dec 2020 at 17:01, JC Brand <mailto:li...@opkode.com>> wrote: Hi all I've submitted a PR for a new protoXEP: MUC Mention Notifictions https://github.com/xsf/xeps/pull/1022 <https://github.com/xsf/xeps/pull/1022> Thanks,

Re: [Standards] MUC Mention Notifications

On 19.12.20 16:41, Andrzej Wojcik wrote: To enable this feature, I've opted for a configuration setting in the MUC. Apparently Tigase already has a similar feature to this protoXEP and relies on letting the user opt-in when registering a nickname with the MUC. Maybe someone from Tigase

Re: [Standards] MUC Mention Notifications

. What do you think? JC On 18.12.20 18:00, JC Brand wrote: Hi all I've submitted a PR for a new protoXEP: MUC Mention Notifictions https://github.com/xsf/xeps/pull/1022 The goal is to document how someone who's affiliated, but not currently present in a MUC might receive notifications when

Re: [Standards] MUC Mention Notifications

On 25.12.20 13:38, Philipp Hörist wrote: Hi, Ok i think i get it, its a warmed up XEP. Not a very successful XEP btw. Anyway back to the original use case for sending messages to people not joined the MUC i think Marvins approach is easier. But it does not replace the reference

Re: [Standards] MUC Mention Notifications

On 25.12.20 12:46, Marvin W wrote: On 24.12.20 16:25, Matthew Wild wrote: would be largely duplicating the semantics of XEP-0372 mentions. XEP-0372 (in its current version 0.4.0) does not specify any semantics for mentions at all and (according to its introduction) only "provides a

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

com/icanhazcheeseburger.jpg'/>                         On 02.07.21 12:15, JC Brand wrote: Hi everyone I've been reading XEP-0385 SIMS with an eye towards potentially implementing it, when I noticed that a XEP-0300 hash is required, in order to allow integrity checking and caching. In the introd

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

tation and sharing into two dedicated XEPs. Yeah, I'd be quite annoyed if I shared a link to a video and my client first insists on downloading the entire file so that it can send out a hash to the recipient. -JC пт, 2 июл. 2021 г. в 13:17, JC Brand <mailto:li...@opkode.com>>: Hi ever

[Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

Hi everyone I've been reading XEP-0385 SIMS with an eye towards potentially implementing it, when I noticed that a XEP-0300 hash is required, in order to allow integrity checking and caching. In the introduction of SIMS, the following is written: "This proposal aims to provide a protocol

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

Am 2. Juli 2021 13:41:26 MESZ schrieb Tobias Markmann : >On Fri, Jul 2, 2021 at 1:22 PM Florian Schmaus >wrote: > >> On 02.07.21 12:15, JC Brand wrote: >> > So, my proposal is that XEP-0385 be updated so that the XEP-0300 >hash >> > requirement gets relaxe

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

mobile client. - JC On 02.07.21 12:15, JC Brand wrote: Hi everyone I've been reading XEP-0385 SIMS with an eye towards potentially implementing it, when I noticed that a XEP-0300 hash is required, in order to allow integrity checking and caching. In the introduction of SIMS, the

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

On 03.07.21 17:44, Linus Jahn wrote: Hello, I just wanted to note that there's also XEP-0447: Stateless file sharing [1] which has some improvements over SIMS (like multiple files in one message and a little simpler API (no need to use character counting / the References XEP) and later

[Standards] XEP-0372 references pointing to different elements in same stanza

Hi everyone In XEP-0372, when references are used for "mentions", there is an implicit assumption that the referenced text is in the tag. There are however other elements where mentions could also occur, such as , and , and some stanzas could have multiple possible elements whose text

Re: [Standards] MAM Sync Strategies

Hi Sam et al Webclients have restrictions that others don't, so while what you wrote makes sense, I do something a bit different with Converse. First, depending on the type of storage used (sessionStorage vs localStorage vs IndexedDB), a webclient can easily run into a storage limit (around

Re: [Standards] MAM Sync Strategies

On 27.08.21 11:45, Andrew Nenakhov wrote: пт, 27 авг. 2021 г. в 12:59, JC Brand <mailto:li...@opkode.com>>: Webclients have restrictions that others don't, so while what you wrote makes sense, I do something a bit different with Converse. Web clients do not need

Re: [Standards] MAM Sync Strategies

On 27.08.21 12:20, Andrew Nenakhov wrote: пт, 27 авг. 2021 г. в 14:52, JC Brand <mailto:li...@opkode.com>>: Converse is made so that it can be integrated into a website where the user might be clicking many links and navigate throughout the site, thereby causing

Re: [Standards] MAM Sync Strategies

On 27.08.21 13:12, Sam Whited wrote: Thanks JC! You're right, I should have mentioned gaps. It's still possible to have them in a desktop client because it could always close before it finishes paging through catching up on history. I had planned to solve that by either switching to committing

Re: [Standards] MAM Sync Strategies

On 27.08.21 12:56, Andrew Nenakhov wrote: пт, 27 авг. 2021 г. в 15:53, JC Brand <mailto:li...@opkode.com>>: I know from professional experience that you can reach the 5MB limit with an integrated webchat of the type I mentioned. then just discard chat history (bar

Re: [Standards] MAM Sync Strategies

On 27.08.21 13:12, Andrew Nenakhov wrote: пт, 27 авг. 2021 г. в 16:03, JC Brand <mailto:li...@opkode.com>>: If the site allows users to show multiple chats side-by-side then you can't discard chat history. Ok, so you have users that use so many simultaneous chats a

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

On 31.08.21 17:23, Jonas Schäfer wrote: Libraries which currently represent body as a (mappnig of language tags to) string(s) would now need extra magic in order to be able to set ID attributes on those. This feels like a quite major change, and not just to References, but to literally

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

Hi Jonas On 31.08.21 17:23, Jonas Schäfer wrote: Hi JC, This has somehow slipped past me. Thanks for taking the time to respond. On Freitag, 13. August 2021 14:00:06 CEST JC Brand wrote: So, if you have a stanza with for example, both "subject" and "body" tags, we

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

On 01.09.21 10:06, Sergey Ilinykh wrote: why not just ``` ``` ? Because that doesn't distinguish between elements with different names. Is that reference based on the or tag? Or perhaps a tag? - JC ср, 1 сент. 2021 г. в 10:59, JC Brand <mailto:li...@opkode.com>>:

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

o know which element is being referred to. If you say an id selector (e.g. #abc123), then we're back to my original proposal, which works for all the use-cases brought up so far, but which requires an "id" attribute on the referenced element. - JC ср, 1 сент. 2021 г. в 11:10, JC Bra

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

Hi all I didn't get any response, so I've gone ahead and made an MR with the proposed changes in the previous email. https://github.com/xsf/xeps/pull/1102 Regards JC On 13.08.21 14:00, JC Brand wrote: Hi everyone In XEP-0372, when references are used for "mentions", there is an

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

On 09.09.21 19:15, Kevin Smith wrote: On 9 Sep 2021, at 18:06, Florian Schmaus wrote: On 13/08/2021 14.00, JC Brand wrote:> Attention Bart Simpson Please hand in your homework before the end of the day Why is there a number sign ('#') before the element name? W

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

On 09.09.21 19:22, Sam Whited wrote: Seems like we might as well use the element name since that has to be unique; one less unique ID to store. Element names are not unique. For example, you can have multiple elements in a PEP message. This is why my request is for the "anchor" attribute

Re: [Standards] Feedback on the proposed CoC

JC Brand, wrote: Dear list The community code of conduct (xep-0458) came up for an approval vote in a recent board meeting. I've gone through the document and am writing down my thoughts and feedback here. Quoted parts are directly from the document. > The examp

[Standards] Feedback on the proposed CoC

Dear list The community code of conduct (xep-0458) came up for an approval vote in a recent board meeting. I've gone through the document and am writing down my thoughts and feedback here. Quoted parts are directly from the document. > The examples in this document of what not to do are

Re: [Standards] Feedback on the proposed CoC

. Ah yes, "just" set up an entirely different governance process than the one we already have and which is already being used to manage procedural issues. On Fri, 4 Feb 2022, 15:39 JC Brand, wrote: On 04.02.22 11:20, Andrew Nenakhov wrote: 1. From what I've seen, CoCs

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

On February 11, 2022 3:48:47 AM GMT+01:00, Peter Saint-Andre wrote: > but that raises the issue of whether we should still >recommend BOSH, since it was a pre-websockets workaround for long polling. The Peertube webchat plugin uses BOSH because IIRC it has to run in an iframe and can

Re: [Standards] [XEP-0424] (Message Retraction) How to handle "removing fastening"?

Yes I think it should just be ignored, but I guess this is another example of how fastenings were created with a different usecase in mind and aren't necessary or relevant to retractions. I'll try to update the XEP soon to remove them. On June 10, 2022 5:00:18 PM GMT+02:00, Goffi wrote:

Re: [Standards] XEP-0424: Message Retraction - Remove Fastening

Hi Daniel Thanks for bringing this up again. This was also the feedback when the XEP was reviewed by council about 2 (!) years ago. As one of the XEP authors, I've gone ahead and made a PR with the change. https://github.com/xsf/xeps/pull/1270 The next XEP, 0425 'Message Moderation' is

Re: [Standards] LAST CALL: XEP-0425 (Message Moderation)

Hi All Thanks to everyone who responded with feedback on the XEP-0425 Last Call, especially Marvin for the well founded criticism and helpful suggestions. I've made a PR which I believe addresses the main criticisms and suggestions. https://github.com/xsf/xeps/pull/1271 To recap: 1.

Re: [Standards] XEP-0424: Message Retraction - Remove Fastening

On 20.02.23 10:32, Florian Schmaus wrote: On 13/02/2023 16.57, Daniel Gultsch wrote: I’m currently looking at implementing 'Message Retraction' and I think it should get rid of Fastening. I mentioned it during Summit and while it wasn’t discussed much further my comment also didn’t get much

  1   2   >