Re: [Standards] Should we move Nicks out of MIX-CORE?
Nicknames are what users use to refer to each other. If, in a channel, I say, "Steve, that's a terrible idea!", then I'm referring to the user whose nickname is Steve in the channel. If we say clients should name channel occupants by any name they like, this won't work. We'll then have to handle things by references - a better idea, certainly, and one that solves the question of who I'm talking to. But then in the text, you'd still see what name I use to refer to you as... Now, as it happens, you're simply Steve Kille in my roster - hooray for posting on good terms, eh? - but what if I'd got a silly name for you? Or misspelled your name? Autocorrect really hates it, after all. These aren't technical interoperability, but they do harm to user experience and might even be a privacy leak. On Mon, 4 Jun 2018, 19:53 Steve Kille, wrote: > > > > > *From:* Standards *On Behalf Of *Dave > Cridland > *Sent:* 04 June 2018 19:11 > *To:* XMPP Standards > *Subject:* Re: [Standards] Should we move Nicks out of MIX-CORE? > > > > > > > > On 4 June 2018 at 07:53, Steve Kille wrote: > > This can be a client choice. The client could show JID, or MIX provided > Nick, or a user-assigned Nick for the participant. MIX is not mandating > what gets shown. > > > > I actually think it should have an opinion on what the client shows, at > ;least when MIX is being used for "chatrooms". > > > > Otherwise there's a risk that different clients end up having such > radically different user interfaces that interoperability is hampered at > the user level. > > > > I have vague recollections of this being a problem in other cases - didn't > Georg do some work on common terminology and suchlike? > > > > Dave. > > *[Steve Kille]* > > > > *Having MIX mandate what is shown or not show in a client UI is drifting > into very dangerous territory. * > > > > *Steve* > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Should we move Nicks out of MIX-CORE?
From: Standards On Behalf Of Dave Cridland Sent: 04 June 2018 19:11 To: XMPP Standards Subject: Re: [Standards] Should we move Nicks out of MIX-CORE? On 4 June 2018 at 07:53, Steve Kille mailto:steve.ki...@isode.com> > wrote: This can be a client choice. The client could show JID, or MIX provided Nick, or a user-assigned Nick for the participant. MIX is not mandating what gets shown. I actually think it should have an opinion on what the client shows, at ;least when MIX is being used for "chatrooms". Otherwise there's a risk that different clients end up having such radically different user interfaces that interoperability is hampered at the user level. I have vague recollections of this being a problem in other cases - didn't Georg do some work on common terminology and suchlike? Dave. [Steve Kille] Having MIX mandate what is shown or not show in a client UI is drifting into very dangerous territory. Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Should we move Nicks out of MIX-CORE?
On 4 June 2018 at 07:53, Steve Kille wrote: > This can be a client choice. The client could show JID, or MIX provided > Nick, or a user-assigned Nick for the participant. MIX is not mandating > what gets shown. > I actually think it should have an opinion on what the client shows, at ;least when MIX is being used for "chatrooms". Otherwise there's a risk that different clients end up having such radically different user interfaces that interoperability is hampered at the user level. I have vague recollections of this being a problem in other cases - didn't Georg do some work on common terminology and suchlike? Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Nicks as UUIDs
Sam, > > > The MIX service generates the nick. In this case it is RECOMMENDED that the > assigned nick is a UUID following RFC 4122 [17]. > > This seems unnecessary and a terrible UX to the point where I'm wondering if > maybe I'm misunderstanding something and this doesn't mean "Show UUIDs to > users"? > [Steve Kille] You are 100% correct. I don't know where this text came from. Will sort this in the next edit. Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Should we move Nicks out of MIX-CORE?
On Sun, Jun 3, 2018, at 14:10, Daniel Gultsch wrote: > 2018-06-03 18:22 GMT+02:00 Steve Kille : > > My sense is that it is handy to have Nicks associated with channel > > participants, to give a more compact display. Perhaps this reflects the > > UIs I'm used to. It feels a pretty basic capability to me. Having some sort of nick seems sensible if the alternative is me having to set a name for each of my contacts in my roster. > My issue with nicks in non-anonymous group chats (and MIX core is now > going to be non-anonymous by default) is that you loose the single > source of truth on what to name that participant. > If I have you in my contact list and I have given you a custom name I > have probably done that for a reason and in 1:1 chats with that person > I will always see that custom name; But how should this be handled in > group chats then? Should it display the nix? Should it display the > roster name? This doesn't seem to be a mix specific problem. My view has always been that I get to make decisions about what my client shows, so what I set in my roster overrides what my contacts send to me. So the fallback is Roster Name -> Remote Nick -> Other identifier (probably JID local part or similar). This also works well because it means that if I don't care what my contacts look like I don't necessarily have to rename each and every one of them (they do it for themselves once and it gets broadcast), but if I do rename all of my contacts (I do "Firstname Lastname" personally) then it's no different, but at least I don't have to look at a JID in the mean time. > In any case; We don’t necessarily need to have a discussion on whether > channel nicks are a good idea or not; Instead I’d rather make the > argument that MIX promotes itself as being an extensible and flexible > solution; so if it is technically possible to move nicks into it's own > XEP it should be done. > > > However, I could move it out into a new MIX-NICK. What do people think? > > Yes let’s put it into a separate XEP I tend to disagree with this; splitting out all these optional parts makes the MIX core smaller, which is definitely nice, but I'm not convinced it actually makes it any easier to implement or understand (see the examples I gave in my previous email to this list). In this particular case, nick setting is a small simple enough section and, I suspect, such a common feature that moving it out will just mean that people have to go dig it up, or will think that MIX doesn't support it and will use it as a reason not to implement MIX. The fact that there are currently 7 MIX XEPs is part of the complexity, not a fix for it. On a tangentially related note: > The MIX service generates the nick. In this case it is RECOMMENDED that the > assigned nick is a UUID following RFC 4122 [17]. This seems unnecessary and a terrible UX to the point where I'm wondering if maybe I'm misunderstanding something and this doesn't mean "Show UUIDs to users"? —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Requirements for "Jid Hidden" Channels
On 2 June 2018 at 17:36, Steve Kille wrote: > It is clear that much of the complexity around JID encoding that is being > postulated as necessary, ties back to requirements to support participant > communication through JID Hidden channels. > > This note is to step back from the JID discussion, and consider JID Hidden > channel requirements. > > I'm writing out a list of requirements here, which I think when agreed, > could be usefully used as part of the introductory material to MIX-ANON. > > With JID Visible channels, real JIDs are shared and participants can use > this to communicate directly. > > When looking at MIX requirements, quite a few argued that we should not > have > JID Hidden. A lot of other chat systems (e.g., Facebook) do not have an > equivalent of JID Hidden. I think that many channels will be JID Visible. > > That's not been the case, though, historically. Most MUC rooms are anonymous. > > It was agreed clearly that we need JID Hidden, primarily to prevent JID > Harvesting. This is going to be useful for public and semi-public > channels. > > REQUIREMENTS: > > 1. Participants can see which other participants have one or more online > clients. > > 2. Online participants can be displayed with a Nick. > > 3. Participants MUST be able to see if another participant changes Nick. > > 4.Participants can sent messages to other participants through the > channel if channel policy allows this. > > 5.A participant can share real JID with another participant and request > real JID. Can't do this currently, but it seems sensible to allow a pair > of willing participants to shift from restricted communication through the > channel to direct communication. > > > POSSIBLE REQUIREMENTS: > > 6. Participants can share presence status additional to online/offline. > I am wondering if, in an environment where JIDs are being hidden, if it > makes sense to share other presence stuff with the channel. My sense is > that for a public MUC, it might make sense to restrict. I would vote to > make this a non-requirement. > > If we assume that people will use MIX in the same way MUC is typically used, then presence is usually (intentionally, I think) shared amongst anonymous participants. > > 7. Where a participant has multiple clients, other participants can see > independent status of these clients. I think that this is not appropriate > for JID Hidden channels. If you are not sharing your JID, it feels wrong > to > be sharing how many clients you have. > > I this this depends on *why* you're hiding your JID. In some cases, people are after perfect anonymity. In general, I think we should ensure that it is possible to have a MIX channel which JIDs are completely hidden (which probably includes avoiding pass-through for IQ, etc in those cases). The two cases I can think of are the e-health case, where we want to be able to assure participants that their identity is secret, and the legal case where corporations wish to participate in some collaborative venture without being definitively identified. (Cyber collaboration, or collaborative security, is an example of the last case). In most cases, though, people seem to want to hide their JID, but not hide their identity. This seems to be the case in the vast majority of MUC rooms I'm in, in fact. Your point (5) would be very useful here, since it would allow, in principle, to subscribe to your presence through a chatroom, which is (pretty much) the use-case here. > > NON REQUIREMENTS > > > 8. vCard. If you are hiding your JID, it seems wrong to allow retrieval > of generic information about you. I think that getting vCard information > about other participants should be explicitly excluded. > > Well, it does seem a bit crazy - and why, back when I did the higher level MUC implementation in M-Link, I explicitly made passing through vCard requests an option. But it turns out most people usually want this for avatars if nothing else. > > 9. Client Disco. I think that allowing clients to use IQ disco of JID > Hidden participants is wrong. If you feel that JID should be hidden, it > does not make sense to > > Totally disagree. This blocks nearly every elective feature of XMPP being used. You might think an anonymous client will never want to do, say, voice calls, but I suspect that's only true if the goal is true anonymity - in which case burner jids are more useful. In practise, though, things like focus users in conference systems work using this. > > > I appreciate that this has switched topics. I think that getting some > agreements here, would help to sort the JID discussion. > > Can we keep this thread on "JID Hidden" and see if we can agree > requirements? > > > > > > Steve > > > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___
Re: [Standards] Addressing for IQs in MIX-CORE
On 04.06.2018 16:43, Jonas Wielicki wrote: > A random side note: I found another argument against the variant where the > client resource is encoded together with the participant id in the resource: > The client resource is -- in contrast to the channel name and participant id > -- not under control of the MIX service. Just to clarify: Not sure about others but I never meant to encode the client resource when I used `client-id`, but an ID assigned by the MIX service for the participant's XMPP session (which maps to a client resource). - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] LAST CALL: XEP-0363 (HTTP File Upload)
This message constitutes notice of a Last Call for comments on XEP-0363. Title: HTTP File Upload Abstract: This specification defines a protocol to request permissions from another entity to upload a file to a specific path on an HTTP server and at the same time receive a URL from which that file can later be downloaded again. URL: https://xmpp.org/extensions/xep-0363.html This Last Call begins today and shall end at the close of business on 2018-06-19. Please consider the following questions during this Last Call and send your feedback to the standards@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! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0363 (HTTP File Upload)
Version 0.7.0 of XEP-0363 (HTTP File Upload) has been released. Abstract: This specification defines a protocol to request permissions from another entity to upload a file to a specific path on an HTTP server and at the same time receive a URL from which that file can later be downloaded again. Changelog: (see in-document revision history) URL: https://xmpp.org/extensions/xep-0363.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. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Addressing for IQs in MIX-CORE
On 4 June 2018 at 15:43, Jonas Wielicki wrote: > I think this is a good point, and I’ve run into this quite a few times > when > implementing MUC. Branching on the message type where 'groupchat' is > somehow > special, but then again only if it does *not* come from the bare JID, and > if > it *does* come from the bare JID, you may be confused (but that happens, > in > fact). And non-groupchat messages from the bare JID have a different > semantics > than non-groupchat messages from the occupant JID (I’m only talking about > MUC > here). This is weird, and I think if MIX does away with that, that would > not > be too bad. > > I'm not sure that type=groupchat messages from the '45 chatroom bare jid are different from type=groupchat messages from the '45 occupant bare jid except in who they're from, are they? I mean, they're different because they're from the chatroom itself, of course, but beyond that? Well, errors, I suppose, come from the bare jid, but they're not groupchat of course. > > A random side note: I found another argument against the variant where the > client resource is encoded together with the participant id in the > resource: > The client resource is -- in contrast to the channel name and participant > id > -- not under control of the MIX service. A client resource can be very > long > (although it probably isn’t right now), and that would break things. > Combining > the participant ID and channel name in the nodepart allows the MIX channel > to > control both parts to always fit in a nodepart (restricting the length of > the > channel name most likely). > > > kind regards, > Jonas > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Addressing for IQs in MIX-CORE
On 4 June 2018 at 14:37, Kevin Smith wrote: > On 4 Jun 2018, at 12:15, Dave Cridland wrote: > >> > >> > >> > >> On 4 June 2018 at 11:37, Steve Kille wrote: > >> > >> To support IQs in MIX-CORE, there needs to be an addressing and routing > >> scheme. > >> > >> I am proposing that this uses a different scheme to messages from the > >> channel (this is Kev's variant 4). > >> > >> The rationale for having a different scheme is that you want to be able > to > >> distinguish from a stanza that comes from the channel, from a stanza > (IQ) > >> that is relayed by the channel. > > > > > > I think that's a false dichotomy. > > I think calling out the language here might be a fair call (although I > don’t find it too confusing), but I think the underlying dichotomy is still > there. Some stanzas are sent in the context of fanout to potentially all > participants, and some are sent to be distributed in private to a single > participant. > That's somewhat different - but even here, you're arguing to change the *from* address depending on where it's been sent *to*? > > >> A message distributed by the channel would come from: > >> channel@domain/stable-participant-id > >> > >> Bare JID is the channel, reflecting that the message comes from the > channel. > >> > >> An IQ message being relayed by the channel would come from: > >> stable-participant-id#channel@domain/resource > >> > >> Bare JID reflects the sender, which will enable the receiver to clearly > >> distinguish that this is not coming from the channel. > >> > >> We want to use this scheme for PMs (MIX-ANON), and here the difference > >> becomes more important. You want to clearly distinguish messages from > the > >> channel from PMs, and this approach gives a framework to achieve this. > >> > > So type='groupchat' is no longer enough? > > Yes, that’s surprising isn’t it? > > I came to this realisation a couple of days ago, not just that it’s no > longer enough, but that it never was really adequate and definitely not > ideal. > A few reasons: > > * Elsewhere in XMPP, the ‘to’ alone is used to determine which entity > receives a stanza (I’m terminating entities at the user, not each of their > devices, for these purposes). That here the difference between sending to a > whole group of people and a single person is predicated not on the address, > but the message type, is cause for us to think twice. > I'm not sure how the to address isn't still governing how receives the stanza. You're arguing for changing the from here, aren't you? > * I have seen multiple bugs from people who are not XMPP-naive in this > area, because it’s very easy to slip when the to no longer gives you > addressing (including security issues). This makes it easy to shoot > yourself in the foot. > Same - a message stanza from A to B has been sent from A to B. The type indicates who *else* has received this. No? > * Even where it doesn’t end up in a bug, I’ve seen bad UX resulting from > this. > * Querying a MAM archive becomes ‘interesting’ when you want to query just > room messages, or just PMs with a particular occupant > This is an interesting and valid point, i think. I'm not convinced it's outweighing the address altering depending on the traffic used though. > > there are others, but this is a reasonable flavour, I think. > > Now, one might assert that it’s not worth changing this in MUC, but in MIX > where we have the chance to avoid all these issues it seems worth giving > serious thought to alternatives. > Absolutely - but I'd argue we want the addressing consistent irrespective of the traffic. > > /K > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Addressing for IQs in MIX-CORE
On Montag, 4. Juni 2018 15:37:00 CEST Kevin Smith wrote: > On 4 Jun 2018, at 12:15, Dave Cridland wrote: > >> On 4 June 2018 at 11:37, Steve Kille wrote: > >> > >> To support IQs in MIX-CORE, there needs to be an addressing and routing > >> scheme. > >> > >> I am proposing that this uses a different scheme to messages from the > >> channel (this is Kev's variant 4). > >> > >> The rationale for having a different scheme is that you want to be able > >> to > >> distinguish from a stanza that comes from the channel, from a stanza > >> (IQ) > >> that is relayed by the channel. > > > > I think that's a false dichotomy. > > I think calling out the language here might be a fair call (although I don’t > find it too confusing), but I think the underlying dichotomy is still > there. Some stanzas are sent in the context of fanout to potentially all > participants, and some are sent to be distributed in private to a single > participant. > >> A message distributed by the channel would come from: > >> channel@domain/stable-participant-id > >> > >> Bare JID is the channel, reflecting that the message comes from the > >> channel.>> > >> An IQ message being relayed by the channel would come from: > >> stable-participant-id#channel@domain/resource > >> > >> Bare JID reflects the sender, which will enable the receiver to clearly > >> distinguish that this is not coming from the channel. > >> > >> We want to use this scheme for PMs (MIX-ANON), and here the difference > >> becomes more important. You want to clearly distinguish messages from > >> the > >> channel from PMs, and this approach gives a framework to achieve this. > > > > So type='groupchat' is no longer enough? > > Yes, that’s surprising isn’t it? > > I came to this realisation a couple of days ago, not just that it’s no > longer enough, but that it never was really adequate and definitely not > ideal. A few reasons: > > * Elsewhere in XMPP, the ‘to’ alone is used to determine which entity > receives a stanza (I’m terminating entities at the user, not each of their > devices, for these purposes). That here the difference between sending to a > whole group of people and a single person is predicated not on the address, > but the message type, is cause for us to think twice. * I have seen > multiple bugs from people who are not XMPP-naive in this area, because it’s > very easy to slip when the to no longer gives you addressing (including > security issues). This makes it easy to shoot yourself in the foot. * Even > where it doesn’t end up in a bug, I’ve seen bad UX resulting from this. * > Querying a MAM archive becomes ‘interesting’ when you want to query just > room messages, or just PMs with a particular occupant > > there are others, but this is a reasonable flavour, I think. > > Now, one might assert that it’s not worth changing this in MUC, but in MIX > where we have the chance to avoid all these issues it seems worth giving > serious thought to alternatives. I think this is a good point, and I’ve run into this quite a few times when implementing MUC. Branching on the message type where 'groupchat' is somehow special, but then again only if it does *not* come from the bare JID, and if it *does* come from the bare JID, you may be confused (but that happens, in fact). And non-groupchat messages from the bare JID have a different semantics than non-groupchat messages from the occupant JID (I’m only talking about MUC here). This is weird, and I think if MIX does away with that, that would not be too bad. A random side note: I found another argument against the variant where the client resource is encoded together with the participant id in the resource: The client resource is -- in contrast to the channel name and participant id -- not under control of the MIX service. A client resource can be very long (although it probably isn’t right now), and that would break things. Combining the participant ID and channel name in the nodepart allows the MIX channel to control both parts to always fit in a nodepart (restricting the length of the channel name most likely). kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Using route-able JIDs in MIX-CORE
On 04.06.2018 08:54, Kevin Smith wrote: > On 3 Jun 2018, at 17:27, Florian Schmaus wrote: >> 3.) IQ requests usually send to / received from >> channel@mix.service/stable-participant-id/client-id >> >> To allow us to address a particular client for IQ exchange. (We could >> add IQ semantics for channel@mix.service/stable-participant-id later on, >> but I'm undecided yet if it is a good idea) > > Why would we want iqs to full JID but not bare JID of a client? Hard to say since we did not yet specify the semantic of an IQ send to channel@mix.service/stable-participant-id. Is it an IQ send to the groupchat-participant's account on the groupchat? Or is proxied by the groupchat to the user's account on its home server? >> Bonus points if: >> >> - Messages send to channel@mix.serivce/stable-paticiapnt-id are send to >> a participant (PMs, e.g. fan-out via carbons, most available resource, … >> - Messages send to channel@mix.service/stable-participant-id/client-id >> are send to single XMPP session of the participant identified by >> client-id (IBB (?)). > > Those two aren’t a bonus, because they break archiving and introduce the > significant risk of subtle bugs (such as those we’ve already seen in the > wild) in implementations. I'm sorry I can't follow without a little bit more elaboration and context. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Addressing for IQs in MIX-CORE
On 4 Jun 2018, at 12:15, Dave Cridland wrote: >> >> >> >> On 4 June 2018 at 11:37, Steve Kille wrote: >> >> To support IQs in MIX-CORE, there needs to be an addressing and routing >> scheme. >> >> I am proposing that this uses a different scheme to messages from the >> channel (this is Kev's variant 4). >> >> The rationale for having a different scheme is that you want to be able to >> distinguish from a stanza that comes from the channel, from a stanza (IQ) >> that is relayed by the channel. > > > I think that's a false dichotomy. I think calling out the language here might be a fair call (although I don’t find it too confusing), but I think the underlying dichotomy is still there. Some stanzas are sent in the context of fanout to potentially all participants, and some are sent to be distributed in private to a single participant. >> A message distributed by the channel would come from: >> channel@domain/stable-participant-id >> >> Bare JID is the channel, reflecting that the message comes from the channel. >> >> An IQ message being relayed by the channel would come from: >> stable-participant-id#channel@domain/resource >> >> Bare JID reflects the sender, which will enable the receiver to clearly >> distinguish that this is not coming from the channel. >> >> We want to use this scheme for PMs (MIX-ANON), and here the difference >> becomes more important. You want to clearly distinguish messages from the >> channel from PMs, and this approach gives a framework to achieve this. >> > So type='groupchat' is no longer enough? Yes, that’s surprising isn’t it? I came to this realisation a couple of days ago, not just that it’s no longer enough, but that it never was really adequate and definitely not ideal. A few reasons: * Elsewhere in XMPP, the ‘to’ alone is used to determine which entity receives a stanza (I’m terminating entities at the user, not each of their devices, for these purposes). That here the difference between sending to a whole group of people and a single person is predicated not on the address, but the message type, is cause for us to think twice. * I have seen multiple bugs from people who are not XMPP-naive in this area, because it’s very easy to slip when the to no longer gives you addressing (including security issues). This makes it easy to shoot yourself in the foot. * Even where it doesn’t end up in a bug, I’ve seen bad UX resulting from this. * Querying a MAM archive becomes ‘interesting’ when you want to query just room messages, or just PMs with a particular occupant there are others, but this is a reasonable flavour, I think. Now, one might assert that it’s not worth changing this in MUC, but in MIX where we have the chance to avoid all these issues it seems worth giving serious thought to alternatives. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Addressing for IQs in MIX-CORE
From: Standards On Behalf Of Dave Cridland Sent: 04 June 2018 12:15 To: XMPP Standards Subject: Re: [Standards] Addressing for IQs in MIX-CORE On 4 June 2018 at 11:37, Steve Kille mailto:steve.ki...@isode.com> > wrote: To support IQs in MIX-CORE, there needs to be an addressing and routing scheme. I am proposing that this uses a different scheme to messages from the channel (this is Kev's variant 4). The rationale for having a different scheme is that you want to be able to distinguish from a stanza that comes from the channel, from a stanza (IQ) that is relayed by the channel. I think that's a false dichotomy. Whether a stanza is "relayed" or not really depends on your viewpoint. For example, some people see messages as relayed, and others see them as a notification from the channel that a new message was submitted. You might say that IQs are relayed; I might argue that they're serviced by the channel - and the channel may service them by, itself, performing an equivalent IQ. [Steve Kille] I think there is a clear difference between a stanza that is routed 1:1 through the channel and a stanza which goes 1:many. Perhaps this is a better way to describe the difference. A message distributed by the channel would come from: channel@domain/stable-participant-id Bare JID is the channel, reflecting that the message comes from the channel. An IQ message being relayed by the channel would come from: stable-participant-id#channel@domain/resource Bare JID reflects the sender, which will enable the receiver to clearly distinguish that this is not coming from the channel. We want to use this scheme for PMs (MIX-ANON), and here the difference becomes more important. You want to clearly distinguish messages from the channel from PMs, and this approach gives a framework to achieve this. So type='groupchat' is no longer enough? [Steve Kille] You can always work things out by looking inside the message.If the JIDs are different, it will be helpful, particularly for messages. For MAM access to the archive, it would be very helpful to be able to distinguish PMs by JID alone. Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Addressing for IQs in MIX-CORE
On 4 June 2018 at 11:37, Steve Kille wrote: > > To support IQs in MIX-CORE, there needs to be an addressing and routing > scheme. > > I am proposing that this uses a different scheme to messages from the > channel (this is Kev's variant 4). > > The rationale for having a different scheme is that you want to be able to > distinguish from a stanza that comes from the channel, from a stanza (IQ) > that is relayed by the channel. > > I think that's a false dichotomy. Whether a stanza is "relayed" or not really depends on your viewpoint. For example, some people see messages as relayed, and others see them as a notification from the channel that a new message was submitted. You might say that IQs are relayed; I might argue that they're serviced by the channel - and the channel may service them by, itself, performing an equivalent IQ. > A message distributed by the channel would come from: > channel@domain/stable-participant-id > > Bare JID is the channel, reflecting that the message comes from the > channel. > > An IQ message being relayed by the channel would come from: > stable-participant-id#channel@domain/resource > > Bare JID reflects the sender, which will enable the receiver to clearly > distinguish that this is not coming from the channel. > > We want to use this scheme for PMs (MIX-ANON), and here the difference > becomes more important. You want to clearly distinguish messages from the > channel from PMs, and this approach gives a framework to achieve this. > So type='groupchat' is no longer enough? > > > Thoughts? > > > Steve > > > > > > > > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Group chat protocol
On 3 June 2018 at 15:30, Ненахов Андрей 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. > > It is quite simple: > >- Group chat is listed in a roster, we use standard xmpp subscription >to join-leave group chats > > So you're thinking that a presence subscription to a groupchat should equate to a groupchat message subscription (but not, as I understand things, a groupchat presence subscription)? That sounds pretty horrible, but I see why you've done it. > >- Clients can differentiate group chat contacts from regular contacts >in their rosters by a specially formatted presence. > > I think that's the case with '45. Seems fine, as long as you're "specially formattng" by just plonking in an extension element. > >- Sending messages to group chat is done by sending messages to group >chat JID > > (Same as '45?) > >- Group chat server resends messages to everyone but sender with >special formatting, that includes unique message ID, sender nickname, >sender JID, avatar hash. For older clients, we provide a plaintext body >that starts with *nickname:\n *before actual message. >This way allows a client to display everything they need without >fetching data from a list of group chat members. Avatar hash is also a >filename so avatar can be retrieved from a server when needed. > > I'm fine with stuffing data into the messages, in general terms. I worry about putting routing info in, but I can live with it. Stuffing data into the text is very horrible. > >- Non-anonymous groups transmit real user JID, semi-anonymous transmit >JID assigned to this user for identification purposes. >- Nicknames and avatars are retrieved from user's vCard when he joins >the group. Can be redefined later by user > > I'd be a little concerned with that approach in anonymous rooms, but I think that the general principle of the service pulling information from the endpoint for relay is fine. > >- No private messages support. XMPP is already a protocol for private >messaging. In non-anonymous groups users can contact each other directly. >In semi-anonymous groups, users can send a special message (via group) to >other users that would disclose their real JID to the user they want to >talk to. If the recipient accepts he can add him to his personal roster and >chat privately. > > Yeah, that's definitely something I disagree with. I see two problems immediately: * Sometimes, anonymous users are anonymous because they want to interact, even in PM, without disclosing their identity. This is particularly true - I think - in e-health cases (though ask Winfried Tilanus about that). * Sometimes, occpuants of a groupchat can be services (bots and other things) which really benefit from knowing the context of the interaction - ie, which room this is. So I think having PMs is useful - this is unfortunate, because otherwise a "decloak" is indeed much cleaner and simpler to implement. > >- Clients can fetch a list of group chat members and turn on/off >receiving updates. We imagine users of big groups of 300+ users don't >really want to receive presence data all the time, but might want to open a >list of participants and see who's online. > > Seems fine. I think this is in MIX too. > Group chat also provides a centralized message archive, so members can > fetch chat history directly from group chat server. > > Advantages of this approach: > >- Simple >- Compatible with existing clients >- Compatible with existing servers >- Easy to implement in any XMPP client > > Parts of it are already implemented (we run it on modified ejabberd), we > already use it for internal communications. It is also already supported in > a web version of Xabber. I expect a mid-July release with support in Web, > Android and iOS versions of Xabber. Most likely we'll also make a Gajim > plugin, but a bit later and maybe not fully featured. > > Admin stuff is not yet done. Most likely will be somewhat akin to Telegram > group chats model. Admins can be granted rights by owners and other admins, > users can be restricted by admins. > > Anyone interested to try it can connect with me xmpp:andrew.nenakhov@ > redsolution.com, I'll invite you to existing groupchat we made. Best way > to try is to connect using development version of Xabber, > https://web.xabber.com/develop/ > For now, it's limited (and sometimes breaks ;) ) and you can only join > already created group chats, I think we'll also add permissions for > anyone to create group chats on our server. > > ... > > Documentation for all of this is now in a somewhat inconsistent state (and > is also in Russian), we changed a number of things from our original plan > and our proto-protocol spec is now already outdated at some places, I plan > to fix it next week and
[Standards] Addressing for IQs in MIX-CORE
To support IQs in MIX-CORE, there needs to be an addressing and routing scheme. I am proposing that this uses a different scheme to messages from the channel (this is Kev's variant 4). The rationale for having a different scheme is that you want to be able to distinguish from a stanza that comes from the channel, from a stanza (IQ) that is relayed by the channel. A message distributed by the channel would come from: channel@domain/stable-participant-id Bare JID is the channel, reflecting that the message comes from the channel. An IQ message being relayed by the channel would come from: stable-participant-id#channel@domain/resource Bare JID reflects the sender, which will enable the receiver to clearly distinguish that this is not coming from the channel. We want to use this scheme for PMs (MIX-ANON), and here the difference becomes more important. You want to clearly distinguish messages from the channel from PMs, and this approach gives a framework to achieve this. Thoughts? Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] IQ Support in MIX-CORE
I had a discussion with my co-author about IQ support in MIX-CORE. I believe that we need to provide support in MIX-CORE for participants to send IQs through the channel to other MIX participants. This is not currently made explicit/clear and I believe that we need to make a change. The reason that this is needed, even with JIDs fully visible, is that many clients will block IQs from unknown clients. If the IQ comes through the channel, then the client may apply different rules. I am proposing to add a section to MIX-CORE that defines this support, as this seems important for basic operation. I'd like to make sure that there is consensus on this change. Please shout clearly if you think this should not be in MIX-CORE. There are some addressing implications from this, which I'll set out in next message. I'm keeping separate, as I suspect that addressing discussion is more likely. Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Requirements for "Jid Hidden" Channels
On 2 Jun 2018, at 17:36, Steve Kille wrote: > It is clear that much of the complexity around JID encoding that is being > postulated as necessary, ties back to requirements to support participant > communication through JID Hidden channels. > > This note is to step back from the JID discussion, and consider JID Hidden > channel requirements. > > I'm writing out a list of requirements here, which I think when agreed, > could be usefully used as part of the introductory material to MIX-ANON. > > With JID Visible channels, real JIDs are shared and participants can use > this to communicate directly. I think that’s at the core of the issue with where the addressing/routing rules go - if it was true then moving them out into mix-anon would make sense, but I don’t believe it is. Because the current state of the network is that stanzas from entities not in your roster/not a room you’re joined to are very often blocked for spam reasons relying on real JID routing to enable communication between MIX participants is unlikely to work and that we’ll need the routing and addressing logic in core because of this. This is only the very basic routing/addressing logic and all of the anon-related stuff remains in mix-anon. > When looking at MIX requirements, quite a few argued that we should not have > JID Hidden. A lot of other chat systems (e.g., Facebook) do not have an > equivalent of JID Hidden. I think that many channels will be JID Visible. > > > It was agreed clearly that we need JID Hidden, primarily to prevent JID > Harvesting. This is going to be useful for public and semi-public > channels. > > REQUIREMENTS: > > 1. Participants can see which other participants have one or more online > clients. > > 2. Online participants can be displayed with a Nick. > > 3. Participants MUST be able to see if another participant changes Nick. > > 4.Participants can sent messages to other participants through the > channel if channel policy allows this. That’s the one that we fail with. > 5.A participant can share real JID with another participant and request > real JID. Can't do this currently, but it seems sensible to allow a pair > of willing participants to shift from restricted communication through the > channel to direct communication. Is that really a requirement? It might be, but also sharing the JID manually seems like a sensible sort of thing to do (I could be persuaded, but I don’t see this really as a core requirement currently) > POSSIBLE REQUIREMENTS: > > 6. Participants can share presence status additional to online/offline. > I am wondering if, in an environment where JIDs are being hidden, if it > makes sense to share other presence stuff with the channel. My sense is > that for a public MUC, it might make sense to restrict. I would vote to > make this a non-requirement. It might make sense to restrict it in some cases, but not in the general case, I think. > 7. Where a participant has multiple clients, other participants can see > independent status of these clients. I think that this is not appropriate > for JID Hidden channels. If you are not sharing your JID, it feels wrong to > be sharing how many clients you have. I’m not sure about this. > NON REQUIREMENTS > > > 8. vCard. If you are hiding your JID, it seems wrong to allow retrieval > of generic information about you. I think that getting vCard information > about other participants should be explicitly excluded. > > > 9. Client Disco. I think that allowing clients to use IQ disco of JID > Hidden participants is wrong. If you feel that JID should be hidden, it > does not make sense to Except that we rely on disco/caps for basic functionality, so this seems hard to avoid. There may be specific channels where it’s appropriate to block this (just as direct interactions are blocked in specific channels in MUC at the moment), but I don’t think that’s true in the general case. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Per Channel Nicks vs Global Nicks
On 4 June 2018 at 09:28, Kevin Smith wrote: > On 3 Jun 2018, at 17:13, Steve Kille wrote: > > > > Daniel, > > > >> -Original Message- > >> From: Standards On Behalf Of Daniel > Gultsch > >> Sent: 03 June 2018 08:29 > >> To: XMPP Standards > >> Subject: Re: [Standards] Another proposal - Handling JIDs for MIX-CORE, > MIX- > >> PRESENCE and MIX-PAM > >> > >> 2018-06-03 1:33 GMT+02:00 Steve Kille : > >>> (Nick and Bare JID). > >> > >> I’m just on my way home from a very productive and interesting meetup > with > >> designers and artists. And without knowledge of the current MIX debate > - just > >> by analyzing the way Conversations currently implements group chats / > MUC - > >> people very quickly challenged the need for having per room nicks. And > the very > >> few arguments I was able to make in defense of having nicks in groups > chats are > >> only valid for anonymous groups. > >> > >> Just wanting to put this out there… > >> > >> cheers > >> Daniel > > > > [Steve Kille] > > Thanks 0 this is useful to share. > > > > I can see that most users joining a public channel would want to use the > same Nick for this and for all public interactions. > > I think that’s usually true, yes. There are clearly cases, like the > Discord model, where you want a different nick in different (sets of) > channel(s), but usually on XMPP I’m Kev and want to remain Kev. I think > that’s straightforwardly achieved by my client just setting me Kev in any > room or channel I join based on my local preference. > > I *think* that for cases where anonymity is needed for legal or high-privacy reasons (I'm thinking ehealth in the latter, for instance), you want to have a nickname per-channel. (Surevine didn't need nicknames at all, but did need to be assured that an anonymous user in one MIX channel was not identifiable as the same user in another channel on the same service). > > There is no global registry, where users can register Nicks. I won't > debate if this is good or bad. However, I think it means that channels > (or MUC rooms) need to get users to pick a Nick.I think it would be > helpful for an XMPP client to make it easy to choose the same Nick for all > channels. > > > > We also see environments where service operators want to enforce > consistent and sensible Nicks. > > The ability for a channel to set the nick (override the nick) for a user > based on local policy might not be core, but I think knowing that clients > will react sensibly to that override is core, and so both end up needing to > be in -core. > > Yes, and ... > > MIX has a concept of Nick Registration (now in MIX-MISC) which provides > a framework for users to have a single Nick across channels in a single > domain.This is clearly not a global Nick, but can help deployments > where only one or a small number of MIX domains are used. > > I think that helps with the “don’t let someone else steal my nick” case > (which is a definite case), but for the “just want to be Kev everywhere” > case where Kev isn’t a popular name, probably just setting from the client > automatically is straightforward. > > ... I think you can build nick registration on top of server-assigned nicknames fairly easily later. > /K > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Per Channel Nicks vs Global Nicks
On 3 Jun 2018, at 17:13, Steve Kille wrote: > > Daniel, > >> -Original Message- >> From: Standards On Behalf Of Daniel Gultsch >> Sent: 03 June 2018 08:29 >> To: XMPP Standards >> Subject: Re: [Standards] Another proposal - Handling JIDs for MIX-CORE, MIX- >> PRESENCE and MIX-PAM >> >> 2018-06-03 1:33 GMT+02:00 Steve Kille : >>> (Nick and Bare JID). >> >> I’m just on my way home from a very productive and interesting meetup with >> designers and artists. And without knowledge of the current MIX debate - just >> by analyzing the way Conversations currently implements group chats / MUC - >> people very quickly challenged the need for having per room nicks. And the >> very >> few arguments I was able to make in defense of having nicks in groups chats >> are >> only valid for anonymous groups. >> >> Just wanting to put this out there… >> >> cheers >> Daniel > > [Steve Kille] > Thanks 0 this is useful to share. > > I can see that most users joining a public channel would want to use the same > Nick for this and for all public interactions. I think that’s usually true, yes. There are clearly cases, like the Discord model, where you want a different nick in different (sets of) channel(s), but usually on XMPP I’m Kev and want to remain Kev. I think that’s straightforwardly achieved by my client just setting me Kev in any room or channel I join based on my local preference. > There is no global registry, where users can register Nicks. I won't debate > if this is good or bad. However, I think it means that channels (or MUC > rooms) need to get users to pick a Nick.I think it would be helpful for > an XMPP client to make it easy to choose the same Nick for all channels. > > We also see environments where service operators want to enforce consistent > and sensible Nicks. The ability for a channel to set the nick (override the nick) for a user based on local policy might not be core, but I think knowing that clients will react sensibly to that override is core, and so both end up needing to be in -core. > MIX has a concept of Nick Registration (now in MIX-MISC) which provides a > framework for users to have a single Nick across channels in a single domain. >This is clearly not a global Nick, but can help deployments where only one > or a small number of MIX domains are used. I think that helps with the “don’t let someone else steal my nick” case (which is a definite case), but for the “just want to be Kev everywhere” case where Kev isn’t a popular name, probably just setting from the client automatically is straightforward. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Another proposal - Handling JIDs for MIX-CORE, MIX-PRESENCE and MIX-PAM
On 3 Jun 2018, at 00:33, Steve Kille wrote: > Sam's message made me realize that none of the variant 1/2/3/4 stuff is > needed for MIX-CORE. I’m not at all convinced that this is true. Anything that relies directly on real-JID routing is breaking PMs, and I don’t think disallowing PMs in real-JID rooms is something that’s been generally accepted. >There are some things that might be needed in > MIX-ANON, but let's worry about these in the MIX-ANON spec and keep them out > of MIX-CORE. If that were true, I’d go along with it. > In MIX-CORE, messages/presence go to a channel or are distributed by a > channel. There is no participant to participant (PM style) communications. That sounds like saying that PM communications are handled out of band, but what it really means is that PM communications can’t be achieved. > I suggest. > > 1. Messages come from the channel (channel@domain). This is what is > happening as the channel is distributing messages. Inside each message you > have a mandatory sender information: (Nick and Bare JID). There would be > an elegance to putting this information into the JID, but I do not think it > is practical and it does not gain you anything. I might buy ‘it does not gain you anything’, but I don’t see the basis for it not being practical to do so. > > 2. Presence come from the channel (channel@domain). This reflects that > the channel is distributing presence. Inside each presence stanza you have > a mandatory sender information: (Nick and Full JID). I really dislike the idea of having all the presence information inside a presence stanza. It seems very unidiomatic to have mean “One of the clients of one of the users in this channel has gone offline, and there are plenty of other presence from=X that are still online”. This will break assorted things in implementations (e.g. have an optimisation to fold presence updates for CSI? Broken. Have a client that maintains a presence map based on JID? Broken. Have a server that does 163 subscriptions? Broken. etc. etc. etc.). /K > That is it. Very simple. Very simple, but also not workable, I think. > No variant JID addressing. There are some > issues for MIX-ANON, but lets worry about these in MIX-ANON, and not make > the core more complex than it needs to be. We can’t make mix-core the simple core we’d like it to be on the promise that we fix things in mix-anon if the core itself is broken. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Using route-able JIDs in MIX-CORE
> On 3 Jun 2018, at 17:32, Steve Kille wrote: > > > >> -Original Message- >> From: Standards On Behalf Of Florian >> Schmaus >> Sent: 03 June 2018 17:27 >> To: XMPP Standards >> Subject: Re: [Standards] Using route-able JIDs in MIX-CORE >> >> On 03.06.2018 18:01, Steve Kille wrote: > That very much looks like that I would currently favour, besides > that I don't see a reason why we shouldn't also use the stable > participant identifier as the resourcepart of the originating address. Uh, and I slightly favour presence also from channel@mix.service/stable-participant-id/unique-client-id as otherwise you will get presence from different devices from the same address. But presence from users with multiple devices is not trivial anyway, not only in the context of MIX, so no matter what we do, someone has to handle it. I still prefer keeping the invariant that presence comes from a unique address per user session, because I think >> it has the potential to make things easier. >>> >>> [Steve Kille] >>> >>> This is an important point.All of the information needed is carried in >>> the >> message.So a change like this does not provide any more information to >> the >> final recipient. >>> >>> However, it means that the JID will be unique for each sending client. >>> This can >> facilitate an implementation handling JIDs internally, by enabling sensible >> switching of messages. >>> >>> If we do this, I think that it makes sense (for similar reasons) to >>> have messages sent from a JID that uniquely identifies the sender of >>> form: channel@mix.service/stable-participant-id >> What exactly do you mean with "uniquely identifies the sender"? The sending >> entity? Or a concrete XMPP session of the sending entity? >> >> Where are possibly a little bit ouf of sync here. Therefore I try to >> summarize the >> approach I currently champion: >> >> 1.) message stanza originate from channel@mix.service/stable-participant-id >> >> Rationale: The tuple of channel, service and stable participant id consists >> of the >> most valuable information of message receiving entities in the context of >> persisent groupchats. The unique client id, identifying the concrete sending >> client(/user session) can be put as (possibly optional) metadata into an >> extension >> element of the message. >> >> 2.) presence stanzas originate from >> channel@mix.service/stable-participant-id/client-id >> >> To keep the invariant that distinct from addresses in presence stanzas >> represent >> distinct clients(/user sessions). >> >> 3.) IQ requests usually send to / received from channel@mix.service/stable- >> participant-id/client-id >> >> To allow us to address a particular client for IQ exchange. (We could add IQ >> semantics for channel@mix.service/stable-participant-id later on, but I'm >> undecided yet if it is a good idea) >> >> Bonus points if: >> - Messages send to channel@mix.service are standard groupchat messages >> - Messages send to channel@mix.serivce/stable-paticiapnt-id are send to a >> participant (PMs, e.g. fan-out via carbons, most available resource, …) >> - Messages send to channel@mix.service/stable-participant-id/client-id >> are send to single XMPP session of the participant identified by client-id >> (IBB (?)). >> >> - Florian > [Steve Kille] > > I would be happy with this.I think it reflects what my message said and > is aligned to variant 2. I note that only 1/2 are needed to sort out > MIX-CORE/MIX-PAM/MIX-PRESENCE > > 3 and bonus stuff only impacts MIX-ANON. I don’t think that’s so - if you’re suggesting you could use a real JID for messaging just because you have it available, this isn’t true. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Using route-able JIDs in MIX-CORE
On 3 Jun 2018, at 17:27, Florian Schmaus wrote: > 3.) IQ requests usually send to / received from > channel@mix.service/stable-participant-id/client-id > > To allow us to address a particular client for IQ exchange. (We could > add IQ semantics for channel@mix.service/stable-participant-id later on, > but I'm undecided yet if it is a good idea) Why would we want iqs to full JID but not bare JID of a client? > Bonus points if: > > - Messages send to channel@mix.serivce/stable-paticiapnt-id are send to > a participant (PMs, e.g. fan-out via carbons, most available resource, … > - Messages send to channel@mix.service/stable-participant-id/client-id > are send to single XMPP session of the participant identified by > client-id (IBB (?)). Those two aren’t a bonus, because they break archiving and introduce the significant risk of subtle bugs (such as those we’ve already seen in the wild) in implementations. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Should we move Nicks out of MIX-CORE?
> -Original Message- > From: Standards On Behalf Of Daniel Gultsch > Sent: 03 June 2018 20:11 > To: XMPP Standards > Subject: Re: [Standards] Should we move Nicks out of MIX-CORE? > > 2018-06-03 18:22 GMT+02:00 Steve Kille : > > My sense is that it is handy to have Nicks associated with channel > > participants, > to give a more compact display. Perhaps this reflects the UIs I'm used to. > It > feels a pretty basic capability to me. > > My issue with nicks in non-anonymous group chats (and MIX core is now going > to be non-anonymous by default) is that you loose the single source of truth > on > what to name that participant. [Steve Kille] I'm not sure this is true. Including the JID is mandatory in MIX-CORE > If I have you in my contact list and I have given you a custom name I have > probably done that for a reason and in 1:1 chats with that person I will > always > see that custom name; But how should this be handled in group chats then? > Should it display the nix? Should it display the roster name? [Steve Kille] This can be a client choice. The client could show JID, or MIX provided Nick, or a user-assigned Nick for the participant. MIX is not mandating what gets shown. > > In any case; We don’t necessarily need to have a discussion on whether channel > nicks are a good idea or not; Instead I’d rather make the argument that MIX > promotes itself as being an extensible and flexible solution; so if it is > technically > possible to move nicks into it's own XEP it should be done. > > > However, I could move it out into a new MIX-NICK. What do people think? > > Yes let’s put it into a separate XEP [Steve Kille] It is quite separable, and I can see some real upsides to a new MIX-NICK XEP. I am not opposed to a split. However, I take Tedd's point about excess splitting. Kev made the same point while I was typing. Let's see what others think. Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Using route-able JIDs in MIX-CORE
On 3 Jun 2018, at 17:01, Steve Kille wrote: > > Flo, > >>> That very much looks like that I would currently favour, besides that >>> I don't see a reason why we shouldn't also use the stable participant >>> identifier as the resourcepart of the originating address. >> >> Uh, and I slightly favour presence also from >> >> channel@mix.service/stable-participant-id/unique-client-id >> >> as otherwise you will get presence from different devices from the same >> address. But presence from users with multiple devices is not trivial >> anyway, not >> only in the context of MIX, so no matter what we do, someone has to handle >> it. I >> still prefer keeping the invariant that presence comes from a unique address >> per >> user session, because I think it has the potential to make things easier. > > [Steve Kille] > > This is an important point.All of the information needed is carried in > the message.So a change like this does not provide any more information > to the final recipient. > > However, it means that the JID will be unique for each sending client. This > can facilitate an implementation handling JIDs internally, by enabling > sensible switching of messages. > > If we do this, I think that it makes sense (for similar reasons) to have > messages sent from a JID that uniquely identifies the sender of form: > channel@mix.service/stable-participant-id > > Are there any downsides to doing this? There are, with PMs, mentioned in earlier threads (when introducing variant 4), but I can’t immediately think of any for room messages. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Should we move Nicks out of MIX-CORE?
On 3 Jun 2018, at 17:22, Steve Kille wrote: >> As far as I understood nicknames are already optional in current MIX. If >> that's >> the case, then it should be moved out of MIX-CORE. > [Steve Kille] > > We do not fundamentally need Nicks to be in MIX-CORE. We do not *fundamentally* need them in core, because we don’t need anything in core, but > You can display participants by use of the JID. I think that would be fairly unpleasant if you just name people with their JID. Other options like vcarding everyone in the MUC to get their nick to render is unpleasant - both from a flood point of view, and that they need have no nick set, and they’re probably not in your roster either. > My sense is that it is handy to have Nicks associated with channel > participants, to give a more compact display. Perhaps this reflects the UIs > I'm used to. It feels a pretty basic capability to me. This is why it > remained in MIX-CORE. > > However, I could move it out into a new MIX-NICK. What do people think? I think not. It’s unhelpful if we have many documents that are theoretically optional but practically required for most every deployment. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Should we move Nicks out of MIX-CORE?
Tedd, So is this a vote to NOT split out Nicks? Steve From: Standards On Behalf Of Tedd Sterr Sent: 04 June 2018 01:05 To: XMPP Standards Subject: Re: [Standards] Should we move Nicks out of MIX-CORE? > However, I could move it out into a new MIX-NICK. What do people think? You could probably move channels into a separate XEP too, and messages, and nodes, and maybe a few other things. I think if you really try, you could probably get MIX up to at least 24 separate XEPs - that would be pretty cool. There are features that are essential, and then there are features that are sensible which could be moved into separate XEPs because they're not essential, but in practice they're necessary anyway. Don't get carried away with splitting off every little thing - it doesn't help anyone to have to rummage through a dozen XEPs just to check whether they need/want listed features. It's probably a rare case that a user will want to set a channel nick different from their 'normal' one. Participants also in a user's roster will already have an assigned nick, but those not in the roster will not; so either: they stay 'bare' (just use JID), or the channel provides nicks along with JIDs, or there's a ridiculous barrage of requests to find out everyone's nicks when the channel could have provided the same information in a single response. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
