Re: [Standards] MIX-PAM: Change of annotate setting with second roster get

LGTM > -Original Message- > From: Standards On Behalf Of Linus Jahn > Sent: 15 July 2022 10:55 > To: standards@xmpp.org > Subject: Re: [Standards] MIX-PAM: Change of annotate setting with second > roster get > > I'm also fine with each roster requ

Re: [Standards] MIX-PAM: Change of annotate setting with second roster get

I'm also fine with each roster request resetting the state. :) I created/updated the PR [1]. Linus [1]: https://github.com/xsf/xeps/pull/1187 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-uns

Re: [Standards] MIX-PAM: Change of annotate setting with second roster get

-- Original Message -- From: "Steve Kille" To: "'XMPP Standards'" Sent: 15/07/2022 09:16:58 Subject: Re: [Standards] MIX-PAM: Change of annotate setting with second roster get My preference for resolving the issue raised is that the client should

Re: [Standards] MIX-PAM: Change of annotate setting with second roster get

22 22:19 > To: standards@xmpp.org > Subject: [Standards] MIX-PAM: Change of annotate setting with second roster > get > > Hello, > > in MIX-PAM [1] a client needs to add an to enable additional the > MIX roster extension > in the roster result and later roster pushes. The

[Standards] MIX-PAM: Change of annotate setting with second roster get

Hello, in MIX-PAM [1] a client needs to add an to enable additional the MIX roster extension in the roster result and later roster pushes. The XEP doesn't say anything about what happens when the user makes a second request without the element. The intended behaviour is probably that the MIX

Re: [Standards] MIX Join: JID or ID?

Thanks! Appreciate this Steve > -Original Message- > From: Standards On Behalf Of Paul Schaub > Sent: 04 April 2020 13:14 > To: standards@xmpp.org > Subject: Re: [Standards] MIX Join: JID or ID? > > Hi Steve, > > Thank you for clarification :) > &g

Re: [Standards] MIX Join: JID or ID?

and what you would like me to sort > > > Regards > > > Steve > > > >> -Original Message- >> From: Standards On Behalf Of Paul Schaub >> Sent: 28 February 2020 13:02 >> To: standards@xmpp.org >> Subject: [Standards] MIX Join: JID or ID? >> >>

Re: [Standards] MIX Join: JID or ID?

ory stable ID. This needs fixing. Let me know what you have sorted, and what you would like me to sort Regards Steve > -Original Message- > From: Standards On Behalf Of Paul Schaub > Sent: 28 February 2020 13:02 > To: standards@xmpp.org > Subject: [Standards] MIX J

Re: [Standards] MIX Join: JID or ID?

Subject: Re: [Standards] MIX Join: JID or ID? Hi Andrzej and list, I re-read the git history of MIX and decided that the jid attribute in the examples of MIX-PAM is probably a remnant from 2018. Back then the "Proxy Jid" attribute was replaced by the concept of Stable Participant

Re: [Standards] MIX Join: JID or ID?

Hi Andrzej and list, I re-read the git history of MIX and decided that the jid attribute in the examples of MIX-PAM is probably a remnant from 2018. Back then the "Proxy Jid" attribute was replaced by the concept of Stable Participant IDs in MIX-CORE. I created https://github.com/xsf/xeps/pull/91

Re: [Standards] MIX Join: JID or ID?

Hi, > Wiadomość napisana przez Paul Schaub w dniu > 28.02.2020, o godz. 14:01: > > Hi List! > > XEP-0369 (MIX-Core) section 7.1.2 about joining a channel states that > when the users server sends a join request to the mix channel, the > channel responds with an IQ of type result. Further it st

[Standards] MIX Join: JID or ID?

Hi List! XEP-0369 (MIX-Core) section 7.1.2 about joining a channel states that when the users server sends a join request to the mix channel, the channel responds with an IQ of type result. Further it states: "This stanza includes the nodes to which the user has been successfully subscribed, as w

Re: [Standards] MIX-PAM: private PEP node for joined channels

On Montag, 9. Dezember 2019 11:39:17 CET Matthew Wild wrote: > > [...] Note > > however that MAM silently treats the case of "the last stanza you saw > > expired from the archive" as "fetch everything since beginning of > > archives", which means you won’t notice that you lost notifications when >

Re: [Standards] MIX-PAM: private PEP node for joined channels

Am Mo., 9. Dez. 2019 um 10:13 Uhr schrieb Jonas Schäfer : > I think what Daniel says is sound. I also think that we don’t have to solve > versioning *right now*. We should provision this, by adding a `ver` attribute > with the following (initial semantics): I case this wasn’t obvious from my init

Re: [Standards] MIX-PAM: private PEP node for joined channels

Hi Jonas, A couple of observations about your post follow below, though not to say I agree or disagree with your overall position (I need to think about this issue more). On Mon, 9 Dec 2019 at 10:12, Jonas Schäfer wrote: > > 1. Current state of archiving in PEP > So the state transfer must be

Re: [Standards] MIX-PAM: private PEP node for joined channels

This is a length response. Table of contents: 1. Current state of archiving in PEP 2. Argument in favour of custom IQ-based wire protocol On Donnerstag, 21. November 2019 21:20:30 CET Linus Jahn wrote: > On Thu, 21 Nov 2019 11:51:11 +0100 Holger Weiß wrote: > > * Daniel Gultsch [2019-11-20 21:

Re: [Standards] MIX-PAM: private PEP node for joined channels

On Thu, 21 Nov 2019 11:51:11 +0100 Holger Weiß wrote: > * Daniel Gultsch [2019-11-20 21:49]: > > Am Mi., 20. Nov. 2019 um 20:45 Uhr schrieb Linus Jahn > > : > > > Also the 'blocking command' way isn't so flexible. Ideally I > > > would like to send one request to the server to receive all > >

Re: [Standards] MIX-PAM: private PEP node for joined channels

We can probably find solutions for the PubSub delta problem. There might also be an argument that we should solve this anyway. Normal user archive (instead of a virtual archive on the pubsub service for example) has problems if the retention period is not high enough. I'm not fully convinced that M

Re: [Standards] MIX-PAM: private PEP node for joined channels

* Daniel Gultsch [2019-11-20 21:49]: > Am Mi., 20. Nov. 2019 um 20:45 Uhr schrieb Linus Jahn : > > Also the 'blocking command' way isn't so flexible. Ideally I would like to > > send one request to the > > server to receive all updates of all of my implicitly subscribed nodes > > after logging i

Re: [Standards] MIX-PAM: private PEP node for joined channels

Am Mi., 20. Nov. 2019 um 20:45 Uhr schrieb Linus Jahn : > Also the 'blocking command' way isn't so flexible. Ideally I would like to > send one request to the > server to receive all updates of all of my implicitly subscribed nodes after > logging in. (I'm not > entirely sure whether this is cur

Re: [Standards] MIX-PAM: private PEP node for joined channels

On Tue, 19 Nov 2019 09:51:00 + Daniel Gultsch wrote: > Am Sa., 16. Nov. 2019 um 17:48 Uhr schrieb Linus Jahn : > > > I'm currently working on XEP-0405 / MIX-PAM. I'm replacing the roster > > mechanism by a private PEP node. The basics are working now, but I'm > > not sure what's the best way

Re: [Standards] MIX-PAM: private PEP node for joined channels

Am Sa., 16. Nov. 2019 um 17:48 Uhr schrieb Linus Jahn : > I'm currently working on XEP-0405 / MIX-PAM. I'm replacing the roster > mechanism by a private PEP node. The basics are working now, but I'm > not sure what's the best way to make presence sharing with the channel > configurable. > > The ro

Re: [Standards] MIX-PAM: private PEP node for joined channels

Am Sat, 16 Nov 2019 18:45:12 +0100 schrieb Linus Jahn : > Hello, > > I'm currently working on XEP-0405 / MIX-PAM. I'm replacing the roster > mechanism by a private PEP node. The basics are working now, but I'm > not sure what's the best way to make presence sharing with the channel > configurable

[Standards] MIX-PAM: private PEP node for joined channels

Hello, I'm currently working on XEP-0405 / MIX-PAM. I'm replacing the roster mechanism by a private PEP node. The basics are working now, but I'm not sure what's the best way to make presence sharing with the channel configurable. The roster mechanism allowed the client to disable presence sharin

Re: [Standards] MIX: Join protocol flow

I have made a PR for XEP-405, in line with this message Steve > -Original Message- > From: Standards On Behalf Of Steve Kille > Sent: 18 September 2019 16:42 > To: 'XMPP Standards' > Subject: Re: [Standards] MIX: Join protocol flow > > > Jonas has

Re: [Standards] MIX: Roster entries -> private PEP node (or something)

> -Original Message- > From: Standards On Behalf Of Daniel Gultsch > Sent: 17 June 2019 17:21 > To: XMPP Standards > Subject: [Standards] MIX: Roster entries -> private PEP node (or something) > > Hi, > > at the last summit we sort of came to the conc

Re: [Standards] MIX: Join protocol flow

äfer > Sent: 16 September 2019 13:03 > To: standards@xmpp.org > Subject: [Standards] MIX: Join protocol flow > > Hi folks, > > I have some time at my hands, and with the MIX implementation in recent > ejabberds, I thought I’d give it a shot. > > However, I’m alrea

Re: [Standards] MIX: Join protocol flow

On Dienstag, 17. September 2019 18:07:28 CEST Steve Kille wrote: > Jonas, > > I'm thinking about this. > > You note: "2. XEP-0369 uses the @id attribute and the @jid attribute on > ." > > I can only see use of can you point out where @id is used? Sorry, that wasn’t clear. I was referring t

Re: [Standards] MIX: Join protocol flow

eptember 2019 13:03 > To: standards@xmpp.org > Subject: [Standards] MIX: Join protocol flow > > Hi folks, > > I have some time at my hands, and with the MIX implementation in recent > ejabberds, I thought I’d give it a shot. > > However, I’m already running into

[Standards] MIX: Join protocol flow

Hi folks, I have some time at my hands, and with the MIX implementation in recent ejabberds, I thought I’d give it a shot. However, I’m already running into issues with the join flow. The specification is inconsistent there between different examples in XEP-0369, between XEP-0369 and XEP-0405,

Re: [Standards] MIX: Roster entries -> private PEP node (or something)

On Sonntag, 15. September 2019 13:21:17 CEST Linus Jahn wrote: > On Mon, 17 Jun 2019 16:20:53 + > > Daniel Gultsch wrote: > > Hi, > > > > at the last summit we sort of came to the conclusion that we want to > > get rid of MIX roster entries and instead place 'joined channels' into > > a priv

Re: [Standards] MIX: Roster entries -> private PEP node (or something)

On Mon, 17 Jun 2019 16:20:53 + Daniel Gultsch wrote: > Hi, > > at the last summit we sort of came to the conclusion that we want to > get rid of MIX roster entries and instead place 'joined channels' into > a private PEP node or some other (non roster) place. > > The arguments in favor of r

Re: [Standards] MIX: Roster entries -> private PEP node (or something)

On Montag, 17. Juni 2019 18:20:53 CEST Daniel Gultsch wrote: > Hi, > > at the last summit we sort of came to the conclusion that we want to > get rid of MIX roster entries and instead place 'joined channels' into > a private PEP node or some other (non roster) place. > > The arguments in favor of

Re: [Standards] MIX: Roster entries -> private PEP node (or something)

On 17.06.19 18:20, Daniel Gultsch wrote: > So could we (as a community) reconfirm that we actually want to move > mix entries out of the roster and then define where we want to store > them again? +1 - Florian signature.asc Description: OpenPGP digital signature ___

[Standards] MIX: Roster entries -> private PEP node (or something)

Hi, at the last summit we sort of came to the conclusion that we want to get rid of MIX roster entries and instead place 'joined channels' into a private PEP node or some other (non roster) place. The arguments in favor of roster were that it can be used to automatically send presence; However th

Re: [Standards] MIX Implementation (Prosody module)

On Mon, Apr 1, 2019 at 12:03 PM, Tedd Sterr wrote: somewhat working MIX implementation! Apr 1 :/ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org

Re: [Standards] MIX Implementation (Prosody module)

Your cat has skills! On Mon, 1 Apr 2019 at 11:04, Tedd Sterr wrote: > I wasn't at the Berlin sprint, so I held my own mini-sprint - at home, > pair-programming with my cat - which mainly involved me coding and her not > paying any attention. After an extended weekend, too much caffeine, and > me

[Standards] MIX Implementation (Prosody module)

I wasn't at the Berlin sprint, so I held my own mini-sprint - at home, pair-programming with my cat - which mainly involved me coding and her not paying any attention. After an extended weekend, too much caffeine, and meals consisting mainly of unhealthy snacks, I present to you a somewhat worki

Re: [Standards] MIX

> * Old participants never die, they're merely removed from the pubsub > node and require endless searching through MAM, or having all their data > copied to the outgoing messages. [..] I don't understand what this is about. Can you expand? Given a message, (some/many/rare) clients nee

Re: [Standards] MIX

On Mon, 18 Mar 2019 at 18:08, Ralph Meijer wrote: > In general, I think that explicit is usually better than implicit. While > I can see how a sensible default might be useful. It brings up some > issues with users that use multiple different clients. > Yeah, and bots, and so on. I'm convinced w

Re: [Standards] MIX

Ralph, > -Original Message- > From: Standards On Behalf Of Ralph Meijer > Sent: 18 March 2019 18:07 > To: standards@xmpp.org > Subject: Re: [Standards] MIX > > Hi, > > I started working on this reply last week, I still need to fully address the > PubSub/M

Re: [Standards] MIX

Dave, Comments below, in red. From: Standards On Behalf Of Dave Cridland Sent: 18 March 2019 17:43 To: XMPP Standards Subject: Re: [Standards] MIX Have removed and added reference to XEP-0359 That would, mind, be a breaking change - so I hope you're bumping the name

Re: [Standards] MIX

Hi, I started working on this reply last week, I still need to fully address the PubSub/MAM/MIX thing, but that'll have to be a separate message. The rest is below. On 12/03/2019 13.00, Dave Cridland wrote: Hi all, I've been writing a quick and dirty implementation of MIX. > > [..] > * Se

Re: [Standards] MIX

On Mon, 18 Mar 2019 at 17:07, Steve Kille wrote: > Dave, > > > > Thanks for all this input. Let me go over it. > > > > > > *From:* Standards *On Behalf Of *Dave > Cridland > *Sent:* 12 March 2019 12:01 > *To:* XMPP Standards > *Subject:* [Sta

Re: [Standards] MIX

Dave, Thanks for all this input. Let me go over it. From: Standards On Behalf Of Dave Cridland Sent: 12 March 2019 12:01 To: XMPP Standards Subject: [Standards] MIX Hi all, I've been writing a quick and dirty implementation of MIX. So far, I've started wi

[Standards] MIX

Hi all, I've been writing a quick and dirty implementation of MIX. So far, I've started with an even quicker and dirtier PubSub, and glued in the MIX stuff on top. There's no MAM etc yet. The following are comments I've had so far, in no particular order: * is sent to the sender for correlatio

Re: [Standards] MIX: Getting hold of your own participant ID

Am Fr., 7. Dez. 2018 um 17:36 Uhr schrieb Ralph Meijer : > > On 2018-12-07 10:27, Daniel Gultsch wrote: > > [..] However it would be nice to also figure out by looking at the JID if > > that message might be a reflection or a message from ourself. > > Isn't this case covered by the inclusion of th

Re: [Standards] MIX: Getting hold of your own participant ID

On 2018-12-07 10:27, Daniel Gultsch wrote: [..] However it would be nice to also figure out by looking at the JID if that message might be a reflection or a message from ourself. Isn't this case covered by the inclusion of the as per example 30 (XEP-0369) and the prose just above it? The

[Standards] MIX: Getting hold of your own participant ID

Hi, so quoting from the MIX spec > MIX messages are distributed by the channel with the from using the JID of > the channel, with the Stable Participant ID of the sender in the resource. > This enables a receiving system to distinguish messages based on sender using > only the JID. It is clear

Re: [Standards] MIX (XEP-0369) channel discovery

I will make time to do a MIX spec edit next week Steve > -Original Message- > From: Standards On Behalf Of Daniel Gultsch > Sent: 06 December 2018 16:00 > To: XMPP Standards > Subject: Re: [Standards] MIX (XEP-0369) channel discovery > > Hi, > > I ran into

Re: [Standards] MIX (XEP-0369) channel discovery

Hi, I ran into the same problem today and I support removing node=mix from the disco#info. Maybe with the filter aspect that Florian suggested. But querying a JID should reveal whether or not that JID is a mix channel without having to make two IQs. As for disco#items that could potentially stil

Re: [Standards] MIX: Random (editorial) feedback

More feedback; Thanks to zinid for catching this. XEP 405 2.4 Client Determines MIX Capability of Local Server First of all I think that the feature should be announced on the account not on the server because we make all requests to the account as well. Second of all the example 3 isn’t correc

[Standards] MIX channel info and xml:lang. Was: Re: MIX (XEP-0369) post-summit update to 0.8

On 20/02/2017 04.32, Steve Kille wrote: On 16 February 2017 19:51, Jonas Wielicki wrote: I’m having trouble with § 3.9.7 and Example 4. The text says: The name and description values MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are prov

Re: [Standards] MIX: Random (editorial) feedback

Daniel, Thanks. I'm going to do an update quite soon Steve > -Original Message- > From: Standards On Behalf Of Daniel > Gultsch > Sent: 30 November 2018 08:09 > To: XMPP Standards > Subject: [Standards] MIX: Random (editorial) feedback > > Hi, > &

[Standards] MIX: Random (editorial) feedback

Hi, As promised in the other thread here are some notes in no particular order > A Nick MAY be associated with a participant, which provides a user-oriented > description of the participant. The nick associated with the user is stored > in a child element of the element. The nick for each >

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

On 30 Nov 2018, at 07:54, Daniel Gultsch wrote: > > Am Fr., 30. Nov. 2018 um 08:29 Uhr schrieb Kevin Smith >: >> >> On 29 Nov 2018, at 20:41, Daniel Gultsch wrote: >>> >>> Hi Steve, >>> >>> Am Do., 29. Nov. 2018 um 20:22 Uhr schrieb Steve Kille >>> : First

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

Am Fr., 30. Nov. 2018 um 08:29 Uhr schrieb Kevin Smith : > > On 29 Nov 2018, at 20:41, Daniel Gultsch wrote: > > > > Hi Steve, > > > > Am Do., 29. Nov. 2018 um 20:22 Uhr schrieb Steve Kille > > : > >> First, the Avatar for a MIX channel is an associated with the channel, not > >> with individual

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

On Fri, Nov 30, 2018 at 10:10 AM, Ненахов Андрей wrote: in our group chat protocol we did the following So we now have muc light, muc sub, xabber muc, original muc and mix. Who is next? ___ Standards mailing list Info: https://mail.jabber.org/mailma

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

On 29 Nov 2018, at 20:41, Daniel Gultsch wrote: > > Hi Steve, > > Am Do., 29. Nov. 2018 um 20:22 Uhr schrieb Steve Kille > : >> First, the Avatar for a MIX channel is an associated with the channel, not >> with individual participants. So an XSF MIX channel might have an XMPP logo >> as the av

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

For anyone's interested, in our group chat protocol we did the following (and it's already working!): - Every user is assigned an id valid only for this group chat, this id does not carry any semantic value and are to be unique - Chats can be in regular or incognito mode. In regular mode

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

> -Original Message- > From: Standards On Behalf Of Daniel > Gultsch > Sent: 29 November 2018 20:41 > To: XMPP Standards > Subject: Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity > Crisis (TM) > > Hi Steve, > > Am Do., 29. Nov. 2018

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

Hi Steve, Am Do., 29. Nov. 2018 um 20:22 Uhr schrieb Steve Kille : > First, the Avatar for a MIX channel is an associated with the channel, not > with individual participants. So an XSF MIX channel might have an XMPP logo > as the avatar. This would be very stable. I was talking about user avat

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

Daniel, I've been observing dialogue. A few points. First, the Avatar for a MIX channel is an associated with the channel, not with individual participants. So an XSF MIX channel might have an XMPP logo as the avatar. This would be very stable. It feels like you want to have unique identif

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

Am Do., 29. Nov. 2018 um 13:36 Uhr schrieb Ralph Meijer : > So instead of every room, you could potentially register the nick with > the service, not every channel. Also, I don't think there's a > requirement for them to be unique from a protocol point of view. What does 'protocol point of view'

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

Am Do., 29. Nov. 2018 um 13:36 Uhr schrieb Ralph Meijer : > > On 29/11/2018 13.09, Daniel Gultsch wrote: > > Hi, > > > > [..] > > > > So let me paint you a picture of my use case. In WhatsApp the user > > creates an account; usually tied to a phone number - but that’s not > > the point; and sets a

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

On 29/11/2018 13.09, Daniel Gultsch wrote: Hi, [..] So let me paint you a picture of my use case. In WhatsApp the user creates an account; usually tied to a phone number - but that’s not the point; and sets a Name and an Avatar. That name isn’t unique. It would be pretty stupid if WhatsApp woul

[Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

Hi, I’ve been reading (parts of) MIX again. I might share some stray observations at some point (Like why isn’t the submission-id not reusing the origin-id) but those are all rather insignificant. Today I want to discuss something else that has been worrying me for quite a while. I have mentioned

Re: [Standards] MIX (XEP-0369) channel discovery

On Wed, 10 Oct 2018 at 09:28, Ralph Meijer wrote: > Hi Dave, > > This seems to assume that all results from a disco#items request are > uniform. This doesn't jive with my idea of how XMPP in general, and > especially Service Discovery, should work. XEP-0030 clearly explains > that after getting t

Re: [Standards] MIX (XEP-0369) channel discovery

Hi Dave, This seems to assume that all results from a disco#items request are uniform. This doesn't jive with my idea of how XMPP in general, and especially Service Discovery, should work. XEP-0030 clearly explains that after getting the items, you have to send a separate request to find out

Re: [Standards] MIX (XEP-0369) channel discovery

Dave, From: Standards On Behalf Of Dave Cridland Sent: 25 September 2018 21:32 To: XMPP Standards Subject: Re: [Standards] MIX (XEP-0369) channel discovery Ralph, As I vaguely recall, the problem wasn't disco#info clashing between MUC and MIX - as you say, those shouldn&#x

Re: [Standards] MIX (XEP-0369) channel discovery

Ralph, As I vaguely recall, the problem wasn't disco#info clashing between MUC and MIX - as you say, those shouldn't clash. The problem is disco#items, where MIX and MUC use disco#items to yield entirely different information. MUC will respond with room occupants, whereas MIX responds with channe

Re: [Standards] MIX (XEP-0369) channel discovery

On 9/25/18 10:58 AM, Steve Kille wrote: > Ralph, > > >> -Original Message- >> From: Standards On Behalf Of Ralph Meijer >> Sent: 20 September 2018 08:43 >> To: XMPP Standards >> Subject: [Standards] MIX (XEP-0369) channel discovery >>

Re: [Standards] MIX (XEP-0369) channel discovery

Ralph, > -Original Message- > From: Standards On Behalf Of Ralph Meijer > Sent: 20 September 2018 08:43 > To: XMPP Standards > Subject: [Standards] MIX (XEP-0369) channel discovery > > Hi, > > Recently I have been looking at discovery of entities to determ

Re: [Standards] MIX (XEP-0369) channel discovery

On 20.09.2018 09:43, Ralph Meijer wrote: > Hi, > > Recently I have been looking at discovery of entities to determine what > kind of thing it is, knowing nothing more than its JID. The starting > point is a client that shows a list of entities, based on past > conversations (MAM), ordered by last

Re: [Standards] MIX (XEP-0369) channel discovery

Hi, even it's a bit more complicated in the context of MAM and MIX because you are storing conversations which could belongs to users who are not in the system anymore. I mean, if you created a bot, for example, that's an account with specific features, and it's registered to a MIX channel an

[Standards] MIX (XEP-0369) channel discovery

Hi, Recently I have been looking at discovery of entities to determine what kind of thing it is, knowing nothing more than its JID. The starting point is a client that shows a list of entities, based on past conversations (MAM), ordered by last interaction. Entities could be regular user acco

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

On 02.06.2018 14:47, Kevin Smith wrote: > On 2 Jun 2018, at 13:01, Florian Schmaus wrote: >> >> On 02.06.2018 13:46, Kevin Smith wrote: On 2 Jun 2018, at 11:44, Florian Schmaus wrote: I think I'm currently in the - messages from channel@service/nick - IQs to/from and presence

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

On 2 Jun 2018, at 13:01, Florian Schmaus wrote: > > On 02.06.2018 13:46, Kevin Smith wrote: >>> On 2 Jun 2018, at 11:44, Florian Schmaus wrote: >>> I think I'm currently in the >>> - messages from channel@service/nick >>> - IQs to/from and presence from channel@service/nick/client-id >>> (where

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

On 02.06.2018 13:46, Kevin Smith wrote: >> On 2 Jun 2018, at 11:44, Florian Schmaus wrote: >> I think I'm currently in the >> - messages from channel@service/nick >> - IQs to/from and presence from channel@service/nick/client-id >> (where client-id is a random unique string not containing '/') >>

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

On 2 Jun 2018, at 09:25, Steve Kille wrote: > > We've been talking about a number of variants to deal with the problem of > encoding four pieces of information in a JID structure that only allows > encoding of three. > > Here is an approach to avoid the problem. > > These JIDs are mostly (excep

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

> On 2 Jun 2018, at 11:44, Florian Schmaus wrote: > > On 02.06.2018 10:25, Steve Kille wrote: >> We've been talking about a number of variants to deal with the problem of >> encoding four pieces of information in a JID structure that only allows >> encoding of three. >> >> Here is an approach

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

On 2 Jun 2018, at 10:22, Steve Kille wrote: > >>> The only problem to address is when in a JID Hidden channel, the recipient >>> wants to address a specific client (PM or vCard lookup). A solution here is >>> to is to use the channel@domain/stable-participant-id addressing to the >>> channel, a

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

On 2 Jun 2018, at 10:10, Dave Cridland wrote: >> On 2 June 2018 at 09:25, Steve Kille wrote: >> We've been talking about a number of variants to deal with the problem of >> encoding four pieces of information in a JID structure that only allows >> encoding of three. >> >> Here is an approach to

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

On 2 Jun 2018, at 09:25, Steve Kille wrote: > > We've been talking about a number of variants to deal with the problem of > encoding four pieces of information in a JID structure that only allows > encoding of three. > > Here is an approach to avoid the problem. > > These JIDs are mostly (excep

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

On 02.06.2018 10:25, Steve Kille wrote: > We've been talking about a number of variants to deal with the problem of > encoding four pieces of information in a JID structure that only allows > encoding of three. > > Here is an approach to avoid the problem. > > These JIDs are mostly (exceptions di

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

The only problem to address is when in a JID Hidden channel, the recipient wants to address a specific client (PM or vCard lookup). A solution here is to is to use the channel@domain/stable-participant-id addressing to the channel, and include the anoymized resource as an extension attribute

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

On 2 June 2018 at 09:25, Steve Kille wrote: > We've been talking about a number of variants to deal with the problem of > encoding four pieces of information in a JID structure that only allows > encoding of three. > > Here is an approach to avoid the problem. > > These JIDs are mostly (exception

[Standards] MIX - an approach to JIDs that avoids the four into three problem

We've been talking about a number of variants to deal with the problem of encoding four pieces of information in a JID structure that only allows encoding of three. Here is an approach to avoid the problem. These JIDs are mostly (exceptions discussed below) used in the "from" of stanzas coming fr

Re: [Standards] MIX Addressing

> -Original Message- > From: Standards On Behalf Of Kevin Smith > Sent: 01 June 2018 14:37 > To: XMPP Standards > Subject: Re: [Standards] MIX Addressing > > On 1 Jun 2018, at 11:37, Steve Kille wrote: > > 1. Use variant 2 for messages.Messages

Re: [Standards] MIX Addressing

On 01.06.2018 18:27, Kevin Smith wrote: > On 1 Jun 2018, at 17:19, Florian Schmaus wrote: >> >> On 01.06.2018 17:57, Kevin Smith wrote: >>> On 1 Jun 2018, at 16:47, Florian Schmaus wrote: On 31.05.2018 13:45, Kevin Smith wrote: > We’ve had some discussions recently about whether pre

Re: [Standards] MIX Addressing

On 1 Jun 2018, at 17:19, Florian Schmaus wrote: > > On 01.06.2018 17:57, Kevin Smith wrote: >> On 1 Jun 2018, at 16:47, Florian Schmaus wrote: >>> >>> On 31.05.2018 13:45, Kevin Smith wrote: We’ve had some discussions recently about whether presence should come from the channel’s JID

Re: [Standards] MIX Addressing

On 1 June 2018 at 17:19, Florian Schmaus wrote: > On 01.06.2018 17:57, Kevin Smith wrote: > > On 1 Jun 2018, at 16:47, Florian Schmaus wrote: > >> > >> On 31.05.2018 13:45, Kevin Smith wrote: > >>> We’ve had some discussions recently about whether presence should come > from the channel’s JID, t

Re: [Standards] MIX Addressing

On 01.06.2018 17:57, Kevin Smith wrote: > On 1 Jun 2018, at 16:47, Florian Schmaus wrote: >> >> On 31.05.2018 13:45, Kevin Smith wrote: >>> We’ve had some discussions recently about whether presence should come from >>> the channel’s JID, the user’s proxy JID, or be encoded in pubsub. Similarly

Re: [Standards] MIX Addressing

On 1 Jun 2018, at 16:47, Florian Schmaus wrote: > > On 31.05.2018 13:45, Kevin Smith wrote: >> We’ve had some discussions recently about whether presence should come from >> the channel’s JID, the user’s proxy JID, or be encoded in pubsub. Similarly >> whether messages should be coming from the

Re: [Standards] MIX Addressing

On 31.05.2018 13:45, Kevin Smith wrote: > We’ve had some discussions recently about whether presence should come from > the channel’s JID, the user’s proxy JID, or be encoded in pubsub. Similarly > whether messages should be coming from the channel’s JID or the user’s proxy > JID. I think the ar

Re: [Standards] MIX Addressing

On 1 Jun 2018, at 11:37, Steve Kille wrote: > 1. Use variant 2 for messages.Messages will come from bare JID of > channel, with resource being stable ID indicating the sender. Sender JID > and Nick in the message.This works right for MAM, and I think it is > reasonably natural for me

Re: [Standards] MIX Addressing

I'd really much rather use the same identifier for both messages and presence if at all possible. On 1 June 2018 at 11:37, Steve Kille wrote: > A proposal: > > > 1. Use variant 2 for messages.Messages will come from bare JID of > channel, with resource being stable ID indicating the sender.

Re: [Standards] MIX Addressing

A proposal: 1. Use variant 2 for messages.Messages will come from bare JID of channel, with resource being stable ID indicating the sender. Sender JID and Nick in the message.This works right for MAM, and I think it is reasonably natural for messages to always come from the channel

Re: [Standards] MIX Addressing

> On 1 Jun 2018, at 09:36, Jonas Wielicki wrote: > > On Freitag, 1. Juni 2018 09:21:45 CEST Kevin Smith wrote: >> On 31 May 2018, at 20:12, Jonas Wielicki wrote: >>> On Donnerstag, 31. Mai 2018 13:45:06 CEST Kevin Smith wrote: We’ve had some discussions recently about whether presence sho

Re: [Standards] MIX Addressing

On 1 Jun 2018, at 09:20, Jonas Wielicki wrote: > > On Freitag, 1. Juni 2018 09:29:15 CEST Kevin Smith wrote: >>> So here’s a straw-man proposal, Variant 3 (because, creating many variants >>> is what we’re good at!): >>> >>> An occupant is identified by an occupant-identifier. The occupant JID i

  1   2   3   >