Pardon for the writing errors. I will rephrase the message. On Sun, 8 Dec 2024 11:54:24 +0200 Schimon Jehudah <sch@fedora.email> wrote:
Greetings.
Would someone of understanding kindly response to linking of PubSub nodes to group chats (using group chat condiguration form) instead of implementing PEP to group chats?
Would someone of understanding kindly response to *the matter of* linking of PubSub nodes to group chats (using group chat configuration form) instead of implementing PEP to group chats?
I think of this as a crucial concern, and therefore I want to read and understand more on that matter, especially from people of XMPP.
Schimon
Best regards, Schimon
On Sun, 27 Oct 2024 20:51:13 +0200 Schimon Jehudah <sch@fedora.email> wrote:
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@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 <sch@fedora.email> 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 <dave@cridland.net> wrote:
On Tue, 24 Sept 2024 at 09:39, Schimon Jehudah <sch@fedora.email> wrote:
On Tue, 24 Sep 2024 07:35:54 +0200 JC Brand <lists@opkode.com> wrote:
On 23 September 2024 11:59:43 GMT+02:00, Schimon Jehudah <sch@fedora.email> wrote:
>Is there any document about MEP?
Yes, there's this:
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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org