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 ___
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 ___
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. 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? 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 ___ 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
> -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. What do others think? Can we build a consensus around this? 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 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 signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Should we move Nicks out of MIX-CORE?
> 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. You can display participants by use of the JID. 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? Steve ___ 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
> Not to be confused with the stable participant identifier that you will get > upon > joining the MIX channel (of which I can't find an official term for). [Steve Kille] I'll sort this out with a round of editing, when the current conversation dies down Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Per Channel Nicks vs Global Nicks
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. 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. 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. Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Using route-able JIDs in MIX-CORE
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? 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 Sat, Jun 2, 2018, at 18:22, Steve Kille wrote: > Would you do me a BIG favour, and do a review of the new slimmed down > 369 (MIX-CORE). I've worked to get this to a simpler and cleaner base. > I would be very interested to hear which aspects of this you still > believe to be too complex. Let me start out by saying that MIX-CORE is now significantly easier to consume in isolation, and I really appreciate the work you've put into that. However, I don't think it's actually possible to read MIX-CORE in isolation. Eg. I get to 7.1.1 and read " The full specification of client interaction with the client's server is specified in MIX-PAM" so now I guess I have to go read MIX-PAM. Or I reach example 23 and read "the MIX service is responsible for unsubscribing the user from all nodes in the channel and for removing the user from the participants list. Presence removal is specified in MIX-PRESENCE" so I have to go read MIX-PRESENCE to understand what it's talking about and whether I need to be concerned with it. Hiding some of the complexity in other documents doesn't make it go away, even if they're "optional" in theory. And MIX-CORE at least looks complex straight from the get go. After I've cleared the initial requirements and intro sections the first thing I'm presented with is a giant table of documents that I'm told I might have to implement. This might just be a minor editorial problem that can easily be fixed, but it says "Only two of these XEPs are mandatory for providing a MIX service" and then presents a table that includes a lot more than two things marked as mandatory and a lot of section headers that aren't "MIX Service", so I'm not actually sure what it's talking about. My initial thought when seeing this is that I'll never make it through all those and that I don't know what any of the column titles even mean (eg. what is an "Administrative MIX Client"?). That being said, I do appreciate having some sort of list so that I know hat I have to look at and don't have to go dig through the bigger XEPs list to try and find them. > 4.6 Proxy JIDs All of this. At the summit where we started to write the current implementation of MIX proxy JIDs were only added to support anonymous rooms. They were later made mandatory for everything, and while I agree that this simplifies things over using them sometimes and not others, I still think the underlying assumption that they are necessary as part of the MIX protocol is wrong. Having proxy JIDs is complicated enough, but on top of that we also have a new specialized JID format to deal with that encodes information in the local part. > 5. Error Handling This section is another list of documents that must be read and supported. I'm all for building MIX out of existing building blocks, but his is becoming a long list of dependencies that are spread over multiple sections and which I have to tease out of the document (and I haven't even started looking at the 6 other MIX documents). In a more general sense, XMPP has a problem of trying to support everyones specific features while also remaining general purpose and future-compatible. The XMPP community doesn't seem to know if it's building a specific chat service meant to be run by many operators, a general protocol on top of which others may build distinct chat services that interop, or some mix of both. This means we start adding tons of specific features right out of the box. However, good software engineering and design should work the exact opposite way. We can always add features later. Good design is removing as much as possible without breaking things (I feel like I heard someone say that, but the only reference I could find was something vaguely similar in a recent blog post by Russ Cox, so apologies to whomever said it if it was a quote and I'm not citing you). —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Group chat protocol
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 - Clients can differentiate group chat contacts from regular contacts in their rosters by a specially formatted presence. - Sending messages to group chat is done by sending messages to group chat JID - 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. - 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 - 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. - 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. 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.nenak...@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 translate to English. *Important notice.* I fully understand that it is almost inevitable that we'll now receive a very big share of criticism from people who won't like this and that and how we do everything *wrong*. We will release support for this protocol in our clients and server no matter what because we need it for our product and we can't wait until this MIX enormity somehow settles down. Thus said, we're very open to constructive feedback, and since this functionality is in very active development we might consider changing some things. -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04 http://www.redsolution.ru ___ 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 03.06.2018 11:48, Florian Schmaus wrote: > On 03.06.2018 01: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.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. >> >> In MIX-CORE, messages/presence go to a channel or are distributed by a >> channel. There is no participant to participant (PM style) communications. >> >> 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. >> >> 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). >> >> >> That is it. Very simple. 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. > > 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. - 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] Another proposal - Handling JIDs for MIX-CORE, MIX-PRESENCE and MIX-PAM
On 03.06.2018 01: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.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. > > In MIX-CORE, messages/presence go to a channel or are distributed by a > channel. There is no participant to participant (PM style) communications. > > 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. > > 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). > > > That is it. Very simple. 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. 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. Further metadata, like nickname, unique client id (or whatever it is called), can be put into a extension element of the message and presence stanzas. Sending IQs would require a lookup of the address of desired participant's device which would yield something like channel@mix.service/stable-participant-id/unique-client-id That also means that you could send messages either to all devices of a participant via channel@mix.service/stable-participant-id or to a particular devices of a participant channel@mix.service/stable-participant-id/unique-client-id e.g. for IBB and the like. - 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] Another proposal - Handling JIDs for MIX-CORE, MIX-PRESENCE and MIX-PAM
On 03.06.2018 10:56, Jonas Wielicki wrote: > On Sonntag, 3. Juni 2018 09:29:13 CEST Daniel Gultsch wrote: >> 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… > > This is also a good point. Maybe we want to move nicknames to MIX-ANON (or > maybe another extension), too. The display name could be drawn from the > roster, the vcard, XEP-0172, or similar. 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. Not to be confused with the stable participant identifier that you will get upon joining the MIX channel (of which I can't find an official term for). - 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] Another proposal - Handling JIDs for MIX-CORE, MIX-PRESENCE and MIX-PAM
On Sonntag, 3. Juni 2018 01:33:12 CEST Steve Kille wrote: > Sam's message made me realize that none of the variant 1/2/3/4 stuff is > needed for MIX-CORE.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. > > In MIX-CORE, messages/presence go to a channel or are distributed by a > channel. There is no participant to participant (PM style) communications. This makes sense. > 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. This sounds great. > 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’m not 100% happy with that, because this breaks with the usual semantics of a lot. I’m not sure if at that point, handling presence via PubSub wouldn’t be better. > That is it. Very simple. 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. I like this. 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] Another proposal - Handling JIDs for MIX-CORE, MIX-PRESENCE and MIX-PAM
On Sonntag, 3. Juni 2018 09:29:13 CEST Daniel Gultsch wrote: > 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… This is also a good point. Maybe we want to move nicknames to MIX-ANON (or maybe another extension), too. The display name could be drawn from the roster, the vcard, XEP-0172, or similar. 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] 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 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
