[Standards] Re: XEP-0163 (Personal Eventing Protocol) Allow multiple publishers; XEP-0045 (Multi-User Chat) Allow PEP

Good evening! Regardles to the reference from Mr. JC Brand (XEP-0316), which I did not read yet. Concerning to adding a PubSub service to an MUC (XEP-0045) group chat (henceforth: "MUC-PubSub"). It might be preferable to connect/link/relate an MUC to a PubSub node or even to multiple PubSub nodes, and it might be a better practice, because it would involve multiple sources from any server. Why not to add a PubSub node to an MUC? ======================================= Or "Why not to add a PubSub node as a service item?" From my observation, namely with Service Discovery (XEP-0030), it seems that MUC is built of pseudo (service) items, each item is allocated to a respective JID which is connected to the group chat. Each item appears as a resource (i.e. room(a)conference.jabber.org/alias). *** The resource is the problem of the subject matter. *** Suppose an XMPP server has added support to MUC-PubSub, people who use clients that have realized MUC-PubSub would either see (1) an associated feed; or (2) messages posted by the group chat itself. * Depends on the implementation of the visual interface. And suppose that the MUC-PubSub node is also a PEP (or PubSub) node urn:xmpp:microblog:0, then people who use clients that have not implemented MUC-PubSub, might see additional participants that is called "urn:xmpp:microblog:0 or might not even have an alias. I could be wrong. I do not know. Maybe it is achievable, and that my basic understanding of the available options was too limited. P.S. I recall seeing a configuration form of an MUC which suggests to connect an MUC to a PubSub, yet I do not know what its functionality is. Please. Correct me if I wrong. Regards, Schimon On Sat, 5 Oct 2024 21:12:45 +0300 Schimon Jehudah &lt;sch(a)fedora.email&gt; wrote: > Is MucSub "Multi-User Chat Subscriptions" relevant? > > <feature var="urn:xmpp:mucsub:0" /> > > https://docs.ejabberd.im/developer/xmpp-clients-bots/extensions/muc-sub/ > > Schimon > > On Wed, 25 Sep 2024 15:43:47 +0100 > Dave Cridland &lt;dave(a)cridland.net&gt; wrote: > > > On Tue, 24 Sept 2024 at 09:39, Schimon Jehudah > > &lt;sch(a)fedora.email&gt; wrote: > > > > > On Tue, 24 Sep 2024 07:35:54 +0200 > > > JC Brand &lt;lists(a)opkode.com&gt; wrote: > > > > > > > On 23 September 2024 11:59:43 GMT+02:00, Schimon Jehudah > > > > &lt;sch(a)fedora.email&gt; wrote: > > > > > > > > >Is there any document about MEP? > > > > > > > > Yes, there's this: > > > > > > > > https://xmpp.org/extensions/xep-0316.html > > > > > > > > > > Thank you, JC, for the reference. > > > > > > > > I'd completely forgotten that existed. :-) > > > > > > > > Other potential use cases for this could be pinning a > > > > particular message to the top of a MUC or providing custom > > > > user actions. > > > > > > I, too, was thinking of pinning messages as a use-case. > > > > > > > For example in a previous project, we used MEP messages to > > > > announce tips between MUC users. > > > > > > > > I would love it if the open source servers added support for > > > > MEP. > > > > > > > > Regards > > > > JC > > > > > > Despite MEP, I think, that a new XEP, as suggested by Dave, is > > > still needed for what I want. > > > > > > > You'll need to specify "how" you're using MEP, yes. So if you > > want to do message pinning, you'd specify the MEP node name, > > payload formats, etc, but all the lower-level MEPpy bits you'll > > just refer to. > > > > Dave. > _______________________________________________ > Standards mailing list -- standards(a)xmpp.org > To unsubscribe send an email to standards-leave(a)xmpp.org