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

Hi, when correcting a previously corrected message, do you reference the original message @id or the message @id of the last correction to that message? The XEP proclaims: | A single message may be corrected multiple times by subsequent edits. which kind of leaves this question open, and from a

Re: [Standards] XMPP Council Minutes 2018-11-14

below is one vote change and one minor remark. Other pending votes will be made later. * Tedd Sterr [2018-11-15 20:41]: > 3) Advance XEP-0357 (Push Notifications) to DRAFT - > https://xmpp.org/extensions/xep-0357.html > > 4) Advance XEP-0359 (Unique and Stable Stanza IDs) to DRAFT - > https://

Re: [Standards] LAST CALL: XEP-0359 (Unique and Stable Stanza IDs)

* Jonas Schäfer [2018-10-20 13:55]: > 5. Is the specification accurate and clearly written? A point that I brought up back then, and that I think needs to be added in §2.2 is this: | The message sender MUST set the stanza's @id to the same value as the | origin-id. The example should be changed

Re: [Standards] LAST CALL: XEP-0359 (Unique and Stable Stanza IDs)

* Holger Weiß [2018-11-14 13:16]: > So this isn't just about wording but about semantics? I.e., you want > the XEP to mandate the server to strip all stanza IDs with by=$JID, > where $JID is any user or server JID the server feels responsible for? > > In that case we'd disagree. The XEP should

Re: [Standards] LAST CALL: XEP-0359 (Unique and Stable Stanza IDs)

* Holger Weiß [2018-11-14 10:41]: > * Georg Lukas [2018-11-13 18:29]: > > §3 point 2 should probably be changed from > > > > | Stanza ID generating entities, which encounter a element > > | where the 'by' attribute matches the 'by' attribute t

Re: [Standards] LAST CALL: XEP-0359 (Unique and Stable Stanza IDs)

* Jonas Schäfer [2018-10-20 13:55]: > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Unfortunately yes, as we can't just retroactively make the stanza @id field work reliably. > 2. Does the specification solve the problem stated in t

Re: [Standards] XEP-0283 Moved - Security and Usability

Hi together, I was kindly reminded to bump this thread, and to ask for actual arguments against moving forward with making 0283 fully-automatic. * Georg Lukas [2018-03-09 17:56]: > Hi together, > > as part of Easy XMPP I wanted to have a way to completely migrate from > one accoun

[Standards] Carbons of XEP-0184 Receipts (Was: XEP-0280 (Carbons) proposals)

b.com/xsf/xeps/pull/434> but it doesn't address this specific case: * Georg Lukas [2017-06-01 13:55]: > Modern clients send bodyless messages with 0085 CSNs and 0184 ACKs to > provide additional communication metadata. There is value in > carbon-copying both of these message types,

Re: [Standards] DEFERRED: XEP-0357 (Push Notifications)

Hi * Ненахов Андрей [2018-10-05 16:37]: > What you suggest imposes additional logic on the XMPP server to decide > between 'important' and 'not important'. I think that in the long term, we need to empower the server to do just that. You propose that the client (or user?) should make the decisio

Re: [Standards] XMPP Council Minutes 2018-10-03

* Tedd Sterr [2018-10-05 22:13]: > 3a) Proposed XMPP Extension: Bookmarks Conversion - > https://xmpp.org/extensions/inbox/bookmarks-conversion.html +1 This is a good thing™. There are some minor orthographical errors and §4 is not really clear. I wonder if there are any clients that support

Re: [Standards] XMPP Council Minutes 2018-08-01

* Dave Cridland [2018-08-06 17:54]: > > I’m pending being persuaded that the PR is right, rather than the original > > issue being a typo, BTW. -1 unless someone manages that (or similar). > > Therefore I concur with Kev, and hereby change my vote to -1. I fear I'm missing out on the logic here.

Re: [Standards] XMPP Council Minutes 2018-06-20

* Sam Whited [2018-06-24 17:19]: > On Sat, Jun 23, 2018, at 06:24, Tedd Sterr wrote: > > 3) Advance XEP-0363: HTTP File Upload > > Georg: [pending] > A few notes on the security section: > > - I wonder if it's worth either specifying that content-type sniffing by the > client is not allowed, or

Re: [Standards] XMPP Council Minutes 2018-06-06

> http://logs.xmpp.org/council/2018-06-06/#15:01:24 > 3) Proposed XMPP Extension: OMEMO Media sharing - > https://xmpp.org/extensions/inbox/omemo-media-sharing.html This is a horrible protocol. Seriously. Still, it is better to have a horrible protocol documented than to pass it on as tribal kno

Re: [Standards] XMPP Council Minutes 2018-06-06

Hi Sam, thanks for taking the time to explain your position. I (mis)read your earlier statement as a generic opposition to any changes to MUC, but this is much more nuanced actually. * Sam Whited [2018-06-12 19:16]: > The problem as I see it is that, no matter how simple this change is, > it add

Re: [Standards] XMPP Council Minutes 2018-06-06

* Sam Whited [2018-06-12 17:03]: > I'm generally opposed right now, and think changes to MUC likely do > more harm than good, but don't let that stop us from discussing it. Okay, let's discuss it. I see three potential (non-exclusive) approaches here: 1) improve the documentation and discoverabi

Re: [Standards] Business rules of Last Message Correction

* Tedd Sterr [2018-06-11 18:31]: > That was my original expectation too, but Kev suggested the bump would be > preferable. I don't want to put words in anybody's mouth, but to me it looks like Kev said it would be better to bump this than to have a second specification, not that changing this sp

Re: [Standards] XMPP Council Minutes 2018-06-06

* Sam Whited [2018-06-09 05:11]: > On Fri, Jun 8, 2018, at 19:52, Tedd Sterr wrote: > > 4a) XEP-0045: Add a feature for the voice request flow #653 - > > https://github.com/xsf/xeps/pull/653 > Adding such a feature this late in the game doesn't really provide any benfit > because it can only be

Re: [Standards] Business rules of Last Message Correction

* Sam Whited [2018-06-11 16:20]: > I'm also not sure that one would be necessary, if we can get away with > no new protocol or namespaces I'd be very happy. Which is exactly why I asked the (non-rhetorical, seriously intended) question I asked further above in this thread, which nobody seems to h

Re: [Standards] Business rules of Last Message Correction

* Tedd Sterr [2018-06-11 15:53]: > > I think an ns bump in 308 is better than a duplicate spec, really (unless > > there’s something I’m missing). > > I'm not strongly for a new spec. What is the worst thing that happens if we just change this Draft? Georg signature.asc Description: PGP sig

Re: [Standards] Business rules of Last Message Correction

* Ненахов Андрей [2018-06-11 11:05]: > The only technical reason for doing only last message correction is a > possible absence of unique id in sent message. The XEP requires the sending client to generate IDs: | Clients MUST send ids on messages if they allow the user to correct | messages. I

Re: [Standards] Business rules of Last Message Correction

* Klaus Herberth [2018-06-11 10:49]: > The XEP just says: "While it is possible to use this protocol to > correct messages older than the most recent received from a full JID, > such use is out of scope for this document and support for this SHOULD > NOT be assumed without further negotiation.",

[Standards] The Nasal Demons of MUC Avatars (XEP-0045 + XEP-0153 = Null Pointer Exception)

Hi, a recent upgrade of some large ejabberd deployment made yaxim crash with a Null Pointer Exception when opening the participant list of a MUC. Further analysis has shown that the misbehavior is caused by the legacy XMPP library I'm using interpreting the following stanza as a participant prese

Re: [Standards] XMPP Council Minutes 2018-04-18

* Kevin Smith [2018-04-21 11:04]: > On 20 Apr 2018, at 20:19, Tedd Sterr wrote: > > On a related note: though I'm happy to continue summarising, do people find > > it useful, or is it more detail than necessary? > Thanks Tedd. I find these minutes to be tremendously useful so would love the > s

Re: [Standards] XEP-0249 (Direct MUC Invitations)

* Tedd Sterr [2018-04-17 01:06]: > XEP-0249 (Direct MUC Invitations) appears to be aimed at working > around privacy lists (XEP-0016) blocking, but since privacy lists are > now deprecated, does it have any other uses cases? Direct invitations have the benefit that the receiver can verify the ide

Re: [Standards] XEP-0045 MUC: am I still there?

* Florian Schmaus [2018-04-12 09:28]: > A different approach would be to define an am-I-still-here IQ send to > the bare MUC address: Yes, this was one of my initial proposals in the October mail. > Advantages I see here is > - The MUC does not intercept IQs This is not quite true. A MUC must i

Re: [Standards] XEP-0045 MUC: am I still there?

* Florian Schmaus [2018-04-11 19:07]: > > If Juliet is not joined, the MUC will respond with > > . > I feel like this is missing "or if the ping request does not originate > from Juliet". Or is this intentional? Responding with is the correct behavior for messages sent to a participant while not

Re: [Standards] XEP-0045 MUC: am I still there?

Resurrecting the self-ping thread in light of the current Council agenda item. * Georg Lukas [2017-10-04 10:21]: > 2. Create a new, explicit am-I-joined IQ that a client can send to the >MUC JID. This seems to be the winner of the discussion from last October, even though it was qua

[Standards] Removal of GC1.0 from MUC / XEP-0045

It is this time of the month again. Georg is trying to fix MUC. This time, I'm asking the Council to remove GC1.0 support from XEP-0045. In case this motion is approved, I'd prepare a PR against 0045 where the respective section will be replaced by a stub, and where servers will be advised to resp

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

> The XMPP Extensions Editor has received a proposal for a new XEP. > Title: Bookmarks 2 (This Time it's Serious) A number of issues I have with the current Bookmarks XEPs, and that I'd like to see addressed in the mid-term future (ideally by adding them to Bookmarks2): 1) Auto-Join The 'autojoi

Re: [Standards] XEP-0283 Moved - Security and Usability

* Jonas Wielicki [2018-03-12 15:51]: > This only works for mutual subscriptions. Good catch, and you are right that it's not much of a problem for our use case. I still think that unidirectional subscriptions are a horrible result of design-by-committee, but there's not much that can be done abou

Re: [Standards] XEP-0283 Moved - Security and Usability

* Sam Whited [2018-03-09 18:16]: > What is the use case you're trying to address here? And who do you > expect to use this feature? I see two possible user stories: a) drag&drop friends from your account A to your acount B b) have a tool that will perform "account migration", i.e. you enter the

[Standards] XEP-0283 Moved - Security and Usability

Hi together, as part of Easy XMPP I wanted to have a way to completely migrate from one account to another, or to be able to move a subset of your contacts to another (local) JID. One possible side-benefit would be to get rid of the "jabber." substring that's so prevalent in many old server instal

[Standards] 2018-02-28 Council Meeting Minutes

# 2018-02-28 Council Meeting Minutes Logs: http://logs.xmpp.org/council/2018-02-28/#16:00:13 ## Role Call - Dave Cridland (chairing) - Daniel Gultsch - Georg Lukas - Kevin Smith - Sam Whited ## For fork's sake, can somebody else take the minutes? Georg this time ## Good Idea Extraction

Re: [Standards] NEW: XEP-0401 (Easy User Onboarding)

* Jonas Wielicki [2018-02-23 11:39]: > - This is a larger one: If we’re changing XEP-0077 flow in a backward- > incompatible manner, wouldn’t it make more sense to do this in a wholly new > namespace, with a new stream feature to advertise support? That would save a > round-trip (to detect that

Re: [Standards] NEW: XEP-0401 (Easy User Onboarding)

* Jonas Wielicki [2018-01-25 15:57]: > > However, then we need to define how the client can determine whether > > this Data Form is a PREAUTH compatible form, and whether the user is > > still required to add more content. > > This can easily be done. Just specify the field @var. If the form has

[Standards] MAM Corner Cases: MUC-PMs and Self-Messages

Hi, Philipp H. pointed out an interesting issue today: MUC-PMs are sent by a MUC to all joined client full-JIDs, so if you are joined to a MUC with two devices, your account will see two copies of the messages. Your MAM archive is also going to store two copies of them, with different MAM-IDs, whi

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

* Guus der Kinderen [2018-02-07 08:44]: > I propose that the XEP is updated with an instruction to, upon detection of > an invalid acknowledgement, terminate the stream with stream error. +1 The rationale behind current behavior is to be permissive in what we accept, but the result is that subtl

Re: [Standards] XEP-0280: Should carbons of carbons be produced?

* Владимир [2018-01-30 08:49]: > A transport wants to inform a xmpp user (say, exam...@xmpp.org) of a message > sent by the associated legacy network account (say, exam...@skype.com) from a > different legacy client (e.g. Skype for PC). > > Looks like this is a job for XEP-0280 carbons, right?

[Standards] XEP-0045: Finding your reflected messages in seven easy steps.

So you (the client) sent a message to a MUC and want to immediately display it as "on the way" (good UX). Some time later (usually within some seconds) you receive a message from the MUC which might or might not be your sent message. You need to update the delivery status of your sent message, so y

Re: [Standards] NEW: XEP-0401 (Easy User Onboarding)

* Jonas Wielicki [2018-01-25 10:26]: > Version 0.1.0 of XEP-0401 (Easy User Onboarding) has been released. > > This document defines a protocol and URI scheme for user invitation in > order to allow a third party to register on a server. The goal of this > is to make onboarding for XMPP IM newcom

[Standards] XMPP Council Minutes for 2018-01-24

# 2018-01-24 Council minutes Logs: http://logs.xmpp.org/council/2018-01-24/#16:00:28 ## Role Call - Dave Cridland (chairing) - Daniel Gultsch - Georg Lukas - Kevin Smith - Sam Whited ## Minute Taker Georg this time ## Outstanding Votes Daniel votes +1 on https://xmpp.org/extensions/inbox

Re: [Standards] [Council] XMPP Council Minutes for 2017-01-10

* Dave Cridland [2018-01-10 18:30]: > 4) ProtoXEP: PEP Avatar to vCard conversion. +1. I like the general idea and I'm pretty sure the security issue I outlined on standards@ can be sorted out. > 6) ProtoXEP: TOTP 2FA +1 I'm not quite sure how the interop between the TOTP Device and the XMPP c

Re: [Standards] Proposed XMPP Extension: User Avatar to vCard-Based Avatars Conversion

* Jonas Wielicki [2017-12-19 09:58]: > Title: User Avatar to vCard-Based Avatars Conversion This is a nice and short patch to the convoluted avatar vs. MUC problem we are having. My only issue is that an 84-only client will upload the avatar under the assumption that it will be limited to contac

Re: [Standards] Instant Stream Resumption 0.0.5 ProtoXEP

* Florian Schmaus [2017-11-30 21:13]: > I've just submitted version 0.0.5 of the Instant Stream Resumption (ISR) > ProtoXEP [1]. §5.2 Performing Instant Stream Resumption | The initiating entity must also provide a element | qualified by the 'https://xmpp.org/extensions/isr/0' namespace, which

Re: [Standards] Connection Type in XEP-0198 'location' (Direct-TLS vs STARTTLS)

* Jonas Wielicki [2017-12-20 13:06]: > > a) the server inspects the client connection type and returns the port > > for the same connection type in 0198/location, i.e. if the client > > connected via Direct-TLS to 5223, the server will return server:5223. > > This will obviously break clients that

[Standards] Connection Type in XEP-0198 'location' (Direct-TLS vs STARTTLS)

Hi, when reading the Instant-Stream-Resumption Proto-XEP, I encountered this piece, which shows a deeper problem in 0198/6120: | The element can optionally also contain a 'location' | attribute which specifies the preferred IP address or hostname, and a | TCP port number of the host which should

Re: [Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

Hi Steve, thanks for your feedback. Please allow me some more remarks. * Steve Kille [2017-12-07 14:03]: > > | 13. Although some protocol is shared with MUC, MUC clients are not > > | interoperable with a MIX service. This means that where a user > > | chooses to use MIX, all of the user

Re: [Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

Hi, so I finally found the time to recover my notes for the first half of MIX, and to get through the second half. Notes below :) §3.2 Core Concepts | 13. Although some protocol is shared with MUC, MUC clients are not | interoperable with a MIX service. This means that where a user | ch

Re: [Standards] XEP-0392: Consistent Color Generation - Issues using JID

* Jonas Wielicki [2017-11-24 09:13]: > So I now tend to use the nickname instead of the JID in MUCs. Does anyone > have > objections? My first gut feeling was to only use the bare JID in non-anon MUCs (as opposed to "when it's known"), which would solve most of the consistency problems - except

Re: [Standards] UPDATED: XEP-0363 (HTTP File Upload)

* XMPP Extensions Editor [2017-02-02 00:14]: > Version 0.3.0 of XEP-0363 (HTTP File Upload) has been released. from a brief reading of the XEP, it might be a good idea to add to the security consideration a sentence or two about the inclusion of new-line and other illegal characters in the name,

Re: [Standards] XEP-0313: Treatment of type=groupchat in user archive with or without hint

* Kevin Smith [2017-11-23 18:33]: > On 23 Nov 2017, at 17:11, Daniel Gultsch wrote: > > For me it doesn't ever make sense to store type=groupchat messages in > > the user archive. I agree with that. We shouldn't make MAM more complicated, and we should specify that MAM should not ever return typ

Re: [Standards] Problems with IM Message Routing: Message Types

Kevin Smith : The only RFC6121 rule that needs to go is the re-routing of "chat" messages sent to an unavailable full-JID: §8.5.3.2.1. https://xmpp.org/rfcs/rfc6121.html#rules-localpart-fulljid-nomatch I think that if we start sending chat messages always to the bare JID, we don’t even need this

Re: [Standards] Problems with IM Message Routing: Message Types

* Florian Schmaus [2017-11-10 21:54]: > > - bare-JID = all-clients + archive > > - full-JID = single client, no carbons, no archive, no redirection > > Which rules of RFC 6121 do you exactly need/want to bend or violate? The only RFC6121 rule that needs to go is the re-routing of "chat" messages

Re: [Standards] Problems with IM Message Routing: Message Types

* Kevin Smith [2017-11-10 21:31]: > I don’t think this needs a new session type. It would be sufficient to > enable these rules when clients enable ‘mamsub’ (for want of a better > term). You are probably right, but my ideas about mamsub so far involve changing the routing behavior for messages,

Re: [Standards] Problems with IM Message Routing: Message Types

* Daniel Gultsch [2017-11-10 21:15]: > I think there is even a XEP recommending sending to full jids. Do you mean resource locking? As Kev said, we should probably get rid of it for messages but possibly keep it for IQs. > > https://wiki.xmpp.org/web/XMPP_2.0) > I always advocate simple solution

[Standards] Problems with IM Message Routing: Message Types

Hi, Hello, this is part 3 of the thread about how broken XMPP is , today we are going to cover Message Types. There are five different well-defined message types that influence how a message is stored and forwarded by servers a

Re: [Standards] Proposed XMPP Extension: Styling

* Daniel Gultsch [2017-11-08 10:40]: > I mild annoyance is that the sending client needs to support this. So > if i'm using mcabber which doesn't support styling I can never trigger > styling on the receiving side even if I, as a knowing user, know about > the syntax and the consequences of stylin

Re: [Standards] Proposed XMPP Extension: Message Markup

* Goffi [2017-11-08 08:17]: > about the stars in the list items, it's not really nice to keep them. > > It would be good to have an attribute to say which plain text characters can > be safely removed without changing the meaning. > For instance type="numeric" means than "^[0-9]+\)" can be remov

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[XEP-0313 for LC] I have three points to make. a) What to store: As already mentioned by Jonas and Kevin, the business rules in §5.1.1 are only a first approximation of what we want to persist, and we need to figure out better / more explicit ways to determine persistent / transient messages. As

[Standards] Council Minutes 2017–10–18

# 2017-10-18 Council minutes Logs: http://logs.xmpp.org/council/2017-10-18/#14:56:10 ## Roll Call - Tobias (chairing) - Dave Cridland (on 4G) - Sam Whited - Daniel Gultsch - Emmanuel Gil Peyrot ## Minute Taker Ge0rG this time ## Vote on "XEP-0071: make security considations much clearer" htt

Re: [Standards] A Quick and Dirty design for "Snippets"

* Dave Cridland [2017-10-15 11:06]: > A Snippet is a small item of content. It is normally referenced within > a chatroom or 1:1 chat. I'm only going to define use in MUC; I'm curious what the benefits are compared to just sending whatever snippet you want inside of a message, or using http-uploa

Re: [Standards] Security issues with XHTML-IM (again)

Hi Sam, * Sam Whited [2017-10-11 22:44]: > I'd like to suggest (again) that we obsolete XHTML-IM. If the easy way > to implement a spec is insecure, you can be sure users will do that. We > can't guarantee security in a spec, but we can certainly make something > that's harder than XHTML-IM to im

[Standards] IM Message Routing 2: Device Identity

Hello, this is part 2 of the thread about how broken XMPP is . Today I'd like to talk about device identity (in the sense that a server knows when a certain client application instance reconnects). Having such a universal clien

Re: [Standards] XEP-0045 MUC: am I still there?

* Evgeny Khramtsov [2017-10-07 15:45]: > No, you can filter out incoming self-IQs, nobody requires you to reply. What about RFC 6120, §8.2.3? "An entity that receives an IQ request of type "get" or "set" MUST reply with an IQ response of type "result" or "error". The response MUST preserve the 'i

Re: [Standards] XEP-0045 MUC: am I still there?

* Florian Schmaus [2017-10-07 09:58]: > > Can be fixed by specifying the server rules for such self-IQs, i.e. > > resources in 'from' and 'to' should match. Even if we mandate that self-IQs have to be reflected to the sender, it's still two round-trips just to figure out if we are still joined:

Re: [Standards] XEP-0045 MUC: am I still there?

Hi Kev, * Kevin Smith [2017-10-04 11:43]: > Thanks for the write-up. I agree this is a problem worth solving. Thanks for the feedback! > I think (3) seems like it has nice properties in terms of a single > round-trip, but I think (2) is the preferable option in practice. It’s > simple to implem

[Standards] XEP-0045 MUC: am I still there?

Hi, TL;DR: checking if you are still in a MUC is broken and needs to be fixed, either with new IQs or with a new rejoin-if-needed presence. MUC presence tends to break === Most of us have experienced this: our client shows us as present in a MUC, but nothing happens for

Re: [Standards] UPDATED: XEP-0359 (Unique and Stable Stanza IDs)

* Florian Schmaus [2017-09-23 11:22]: > I think I don't understand the benefits from Georg's suggestion, so > currently one reason against is that it adds more complexity without any > gain from my PoV. I would argue that it reduces complexity by decreasing the number of "unique" message IDs atta

[Standards] Problems with IM Message Routing

Hello, there is a number of open issues with how message routing currently works for the IM use case, and where it doesn't work consistently because of different patches (Carbons, MAM) that we have applied over time to modernize it. XEP-0280 has been Last-Called twice in the last two years, and i

Re: [Standards] XEP-0199: XMPP Ping - question on ping timeout

* vaibhav singh [2017-10-03 15:45]: > After Service Discovery is done, the pinging and the pinged entity could > negotiate a timeout between themselves (one of them could dictate what > timeout to use, or both parties could suggest timeouts and we use the one > which is lower). This is actually a

Re: [Standards] Rename XEP status identifiers

* Guus der Kinderen [2017-09-26 11:06]: > By doing some window dressing, we will improve the perceived maturity > and stability of the protocol. Absolutely +1. MUC is 15 years old, and it's still in "Draft". We really need better names (though we probably need to discuss those at length, first).

Re: [Standards] UPDATED: XEP-0359 (Unique and Stable Stanza IDs)

Hi, the vast number of different IDs can make a developer dizzy. Can we please specify in 0359 that an entity adding an MUST (or at least SHOULD) set the message-id value of the message to the same ID as the ? It was asked why would be needed at all then, but when a client is processing incomin

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

* Dave Cridland [2017-09-12 11:02]: > FWIW, I've never bothered blocking any spammers, because it looks like > they always use a throwaway address anyway. I think the push behind the Spam Reporting XEP is to allow the server admins who are not in the lucky position of getting spammed already, to

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

* 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, this is going to be challenging. I'd real

Re: [Standards] Reputation system for XMPP

Hi, just to add some (controversial) points to the SPAM debate: The XSNDR spam is ridiculously easy to filter with some heuristics (and prosody's mod_firewall). I'm blocking north of 10K messages per day on yax.im. If you are still getting spam from XSNDR, your server operator needs some urgent h

Re: [Standards] XEP-0334 Message Processing Hints (Was: [Council] Council Meeting Minutes April 5th 2017)

Just a small summary / follow-up from todays xsf@ discussion. * Georg Lukas [2017-07-13 21:56]: > Maybe OTR and MUC-PMs are the only pathological cases here. Then you are > right and we don't even need / . Daniel's point that OTR and MUC-PMs are a legacy exception and that

Re: [Standards] XEP-0334 Message Processing Hints (Was: [Council] Council Meeting Minutes April 5th 2017)

* Daniel Gultsch [2017-07-13 18:56]: > A is the opposite of B. So every message that's not A is B by > definition. So we only need to recognize (be it by marking or by rules > defined somewhere) ephemeral messages. And yes I totally agree that > CSI should use the exact same rules. You are right.

Re: [Standards] XEP-0334 Message Processing Hints (Was: [Council] Council Meeting Minutes April 5th 2017)

* Daniel Gultsch [2017-07-13 17:53]: > Maybe we are obsessing a bit too much about hints. Maybe we should > take a step back and think about what we need hints for in the first > place and if we can maybe replace hints with some more well defined > server side rules. That's a very nice idea indee

[Standards] XEP-0334 Message Processing Hints (Was: [Council] Council Meeting Minutes April 5th 2017)

I'll make another attempt to unstall the hints situation. * Sam Whited [2017-04-19 16:54]: > On Wed, Apr 12, 2017 at 10:14 AM, Dave Cridland wrote: > - Discoverability: if or or whatever is only > used from carbons, why do I have to click through to a different long > XEP to find the one hint

Re: [Standards] XEP-0280 (Carbons) proposals

Hi Kev, * Kevin Smith [2017-06-01 12:39]: > I promised to review and start a thread on the pending PR for Carbons updates Thanks very much for reviewing it :) > Removing no-copy: > I think this goes beyond just removing no-copy, and makes what was > before a hint by the client now normative. Wh

Re: [Standards] Proto-XEP: Pre-Authenticated Roster Subscription

Hello together, thanks to everybody for the very fruitful debate! This is exactly the kind of feedback I've anticipated :) I'll try to summarize the possible further development options below. * Kevin Smith [2017-05-10 22:51]: > The thing that I’m very clear should be server-side is the accepta

Re: [Standards] Proto-XEP: Pre-Authenticated Roster Subscription

* Jonas Wielicki [2017-04-27 19:24]: > The UX is one thing. I’d first like to clear how N=1 would work > implementation > wise. Sorry, but this is doing it the wrong way around. You can store a list of tuples of (token, counter, max validity), either on the server or in the client. This is how

Re: [Standards] Proto-XEP: Pre-Authenticated Roster Subscription

* Daniel Gultsch [2017-04-27 18:58]: > As stated in MUC I'm fine with an HMAC. +1 > I think it might be useful for a client to know if they can rely on the > server to dealwith the authentication or if they will have to do that > themselves. I don't think this matters in any practical way. Your

Re: [Standards] Proto-XEP: Pre-Authenticated Roster Subscription

Hi Daniel, thanks very much for writing down the proposal! I like the principal idea very much, and I have just some small questions and remarks. * Daniel Gultsch [2017-04-27 17:59]: > * Clients subscribe to private PEP node. (See XEP-0223 on how to make a pep > node private) > * One client (the

Re: [Standards] Standardise Colours used in XMPP clients

* Tobias M [2017-03-24 08:39]: > Quite a complex problem you choose to solve there. Ideally you want a > colour palette where the colours are as much different to the user as > possible. There are three principal approaches: 1) dynamic based on # of participants - best color separation in small

Re: [Standards] Standardise Colours used in XMPP clients

* Jonas Wielicki [2017-03-22 18:54]: > So we threw together our thoughts on that matter in a wiki article > . Georg came up with using the > YCbCr > colour space for sampling the colours, and we’re pretty happy with the > results > so far. It’s trivia

[Standards] XMPP Software Developers: Action Required

this step in the following years. Thank you for observing all safety precautions. Georg Lukas, on behalf of the XSF Board [0] https://xmpp.org/software [1] https://github.com/xsf/xmpp.org/blob/master/data/README.rst [2] https://github.com/xsf/xmpp.org/commit

Re: [Standards] Join and Create

* Florian Schmaus [2017-03-23 14:25]: > It is the same feature request for PubSub/PEP. For example when using > OMEMO you always want to subscribe-and-maybe-create the devicelist node. I can see how an UPSERT operation is useful on a resource that is exclusively owned by you, but not on a "public

Re: [Standards] Join and Create

* Florian Schmaus [2017-03-23 10:11]: > That does work if the name of the channel can be random (nameless). But > I believe that there will be use cases where the name of the channel > needs to be fixed. Yes, there are use cases where a fixed channel name is needed. But do you really want to end

Re: [Standards] Join and Create

* Florian Schmaus [2017-03-23 08:22]: > Consider an chess-game service build on top of MIX. Tim and Tom want to > play a game and agree on the "TimAndTomsGame" as name. Now both clients > want to join-and-maybe-create the TimAndTomsGame MIX channel. I think this is exactly what §6.5.3 "Creating a

[Standards] Soliloquy (self-message) routing rules (RFC6121, XEP-0280)

Hi, sometimes IM users want to talk to themselves, e.g. to send a URL from one device to another, or to take notes. In systems like Slack this is recognized and the self-message area is provided as a draft board. In modern XMPP (6121+Carbons/MAM), messages-to-self are always delivered twice(*), b

Re: [Standards] XEP-0313: Storage Rules for Archives

* Tobias Kräntzer [2017-01-30 23:51]: > This also applies for other playloads send via a message stanza. If > such a message does not contain a body element (or maybe an html > element), it will not end up in the archive. This is very similar to the struggles I'm having with Carbons currently, as

Re: [Standards] Carbons of Message Acks and Chat Markers (XEP-0280, XEP-0184, XEP-0333)

* Daniel Gultsch [2017-02-26 11:53]: > Option 1 and 2 are obviously terrible. Indeed. > 3) I actually don't see 0184 or 0333 specifying any type. Examples are > not normative. I'm reading this as I can use any type I want. > What Conversations actually does for delivery receipts (for both 0184 >

[Standards] Carbons of Message Acks and Chat Markers (XEP-0280, XEP-0184, XEP-0333)

Hello, it looks like we are currently in the process of overhauling Carbons, and I'd like to improve the rules for Acks and Chat Markers, specifically to make these also carbon-copied to other devices. If A fails to send a message to B, the error is carbon-copied: -- carbon copy of message --

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

* XMPP Extensions Editor [2017-02-09 00:07]: > This Last Call begins today and shall end at the close of business on > 2017-02-22. As outlined in the "Carbon Rules for MUC-PMs" mail[0], here are two PRs against 0045 and 0280: https://github.com/xsf/xeps/pull/436 "XEP-0045: Add tag to MUC-PMs"

Re: [Standards] Example Resources in XEPs (XEP-0369)

* Jonas Wielicki [2017-02-20 10:20]: > I feel that using BIND2 resources---albeit this is likely to become the new > standard---harms readability a lot. However, I can also see that using > examples which do not fit the current standards lead to developers > implementing the wrong things, such

Re: [Standards] MAM things in MIX RE: MIX (XEP-0369) post-summit update to 0.8

* Steve Kille [2017-02-20 03:05]: > > - From that it sounds like "both". > [Steve Kille] > > Jonas - this is spot on. > > In my view, the text is clear, so I am not going to make any changes. It would be great to have that replicated in the §3.4 "MIX and MAM" section, as this is the first pl

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

* Matthew A. Miller [2017-02-16 18:31]: > About the only argument I'm aware of for keeping it is existing > implementations. If the namespace version bumps, that kind of > "solves" that problem. I really don't like bumping, but as this is a privacy-sensitive matter, I think we really need to do

Re: [Standards] MIX (XEP-0369) post-summit update to 0.8

Hi Steve, thanks again for keeping this running. I'm still confused about how MIX and MAM are going to interact in practice. While the concept is clear, I still wonder: - whether the participant's server, the MIX channel or both need to keep MAM archives of a channel (or only of individual nod

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

* Ruslan N. Marchenko [2017-02-13 19:30]: > >As there was no consensus two years ago, I just added both elements to > >0280 in https://github.com/xsf/xeps/pull/382 > > Thanks for clarification, but then still, why two? if is still > required to avoid bump, why not to stick to that? Especially if,

<    1   2   3   >