XEP-0163 (Personal Eventing Protocol) Allow multiple publishers; XEP-0045 (Multi-User Chat) Allow PEP
Good day! I am the developer of Slixfeed news bot, which is a syndication feed reader (Atom/RDF/RSS). This matter is also related to Morbot. See https://codeberg.org/TheCoffeMaker/Morbot/issues/13 Concern ------- I have to attempted experiment with PEP nodes, and my attempt has failed due to: XEP-0045 service-unavailable The feature requested is not supported by the conference XEP-0163 forbidden You're not allowed to create nodes Proposal -------- I suggest to enable PEP nodes for MUC JIDs too. I suggest to change the approach "One publisher per node.". See https://xmpp.org/extensions/xep-0163.html#approach-publisher
There is no need for multiple publishers to a PEP service, since by definition the service generates information associated with only one entity. The owner-publisher for every node is the bare JID of the account owner.
In order to allow a secondary "channel" interface for people and group chats, and also for other reasons (see further), it would be useful to: 1) Allow multiple publishers. 2) Allow PEP for MUC JIDs. By a "channel" interface, I mean, that should a news bot be included for a group chat, the updates would be sent to a PEP node of the group chat JID instead to the chat itself, which would keep the chat view cleaner. Example use cases: Number #3 represents the use of Morbot and Slixfeed, and is useful for forwarding of news journals. 1) Use : Inbox Affiliation : Publish-Only Publishers : JIDs which Presence is shared with or in Roster 2) Use : Collaboration (e.g. Pad, Whiteboard etc.) Affiliation : Publisher Publishers : Determined manually 3) Use : Updates Affiliation : Publish-Only Publishers : Determined manually Note ---- Slixfeed can use its own PEP nodes named after its subscribers respectively, albeit that would be more demanding on the server of which Slixfeed is operated on, than publishing to PEP nodes of other JIDs, and yet it would not be practical for group chat JIDs, which the bot also supports. Please advise. Kind regards, Schimon
On Mon, 23 Sept 2024 at 08:27, Schimon Jehudah <sch@fedora.email> wrote:
I suggest to enable PEP nodes for MUC JIDs too.
Technically this wouldn't be PEP, just "Pubsub on a MUC JID". We've previously called such things MEP, but never specified them fully. That said, they're not exactly unspecified either - if all you wanted was PubSub on a MUC JID, that's pretty much a one-liner. If you do want the rest of PEP - the same smart defaults, and presence-based autosubscriptions - you'd need to specify how those worked.
I suggest to change the approach "One publisher per node.". See https://xmpp.org/extensions/xep-0163.html#approach-publisher
There is no need for multiple publishers to a PEP service, since by definition the service generates information associated with only one entity. The owner-publisher for every node is the bare JID of the account owner.
On this, PEP is a minimal profile of PubSub. I think most modern servers now just implement full pubsub on a personal Jid - which, being a proper superset of PEP's profile, is sufficient. This has been referred to before as "Pubsub-onna-Jid". POJ, anyone? (Please no). Anyway, PEP doesn't mandate only one publisher per node; it just says there's no need for anything else. But... PEP gives the minimum profile needed - and indeed early PEP support was a bespoke system on servers, which implemented just that minimum (and sometimes even less - I seem to recall servers that wouldn't allow multiple items). It also gives smart defaults and the presence-autosubscribe. I suspect it's not unreasonable to just require full PubSub (or at the very least much more than PEP) in a new XEP. And I suspect what you want to do here is just write a XEP for what SlixFeed does (and/or what it wants to do). Dave.
Greetings, Dave! Thank you for your respond! Please see further comments. On Mon, 23 Sep 2024 09:28:49 +0100 Dave Cridland <dave@cridland.net> wrote:
On Mon, 23 Sept 2024 at 08:27, Schimon Jehudah <sch@fedora.email> wrote:
I suggest to enable PEP nodes for MUC JIDs too.
Technically this wouldn't be PEP, just "Pubsub on a MUC JID". We've previously called such things MEP, but never specified them fully.
That said, they're not exactly unspecified either - if all you wanted was PubSub on a MUC JID, that's pretty much a one-liner. If you do want the rest of PEP - the same smart defaults, and presence-based autosubscriptions - you'd need to specify how those worked.
Is there any document about MEP?
I suggest to change the approach "One publisher per node.". See https://xmpp.org/extensions/xep-0163.html#approach-publisher
There is no need for multiple publishers to a PEP service, since by definition the service generates information associated with only one entity. The owner-publisher for every node is the bare JID of the account owner.
On this, PEP is a minimal profile of PubSub. I think most modern servers now just implement full pubsub on a personal Jid - which, being a proper superset of PEP's profile, is sufficient. This has been referred to before as "Pubsub-onna-Jid". POJ, anyone? (Please no).
Is there any document about POJ?
Anyway, PEP doesn't mandate only one publisher per node; it just says there's no need for anything else. But...
PEP gives the minimum profile needed - and indeed early PEP support was a bespoke system on servers, which implemented just that minimum (and sometimes even less - I seem to recall servers that wouldn't allow multiple items). It also gives smart defaults and the presence-autosubscribe.
Your summary and your further suggestion for an XEP, have convinced me to refer for a new XEP.
I suspect it's not unreasonable to just require full PubSub (or at the very least much more than PEP) in a new XEP.
By "full PubSub", do you mean to a fully functional PubSub?
And I suspect what you want to do here is just write a XEP for what SlixFeed does (and/or what it wants to do).
I think I am interested to write an XEP for this feature, and I would be delighted to collaborate with you or anyone else who would want to instruct me. P.S. I am a lawyer, not an expert engineer, so help is essential to me.
Dave.
Schimon
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: https://xmpp.org/extensions/xep-0316.html Other potential use cases for this could be pinning a particular message to the top of a MUC or providing custom user actions. 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
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.
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. Kind regards, Schimon
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.
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.
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
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? 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. 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
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
I forgot to answer to a matter. On Mon, 23 Sep 2024 09:28:49 +0100 Dave Cridland <dave@cridland.net> wrote:
That said, they're not exactly unspecified either - if all you wanted was PubSub on a MUC JID, that's pretty much a one-liner. If you do want the rest of PEP - the same smart defaults, and presence-based autosubscriptions - you'd need to specify how those worked.
I want to populate PubSub node urn:xmpp:microblog:0 with items. Though, I think I might want to dedicate a different Node Name for this proposed situation. Schimon
I suggest to enable PEP nodes for MUC JIDs too.
This isn't a standards/spec issue, but simple a lack of any existing implementation. We know how to have a PubSub service be on any arbitrary JID (that is one of the few parts of actual PEP still remaining in the wild) but servers haven't happened to implement this against JIDs that happen to be MUCs also.
On Mon, 23 Sept 2024 at 14:52, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
I suggest to enable PEP nodes for MUC JIDs too.
This isn't a standards/spec issue,
Not sure about that. Putting PubSub on any jid, including MUC jids, is fairly straightforward, and it's a single line in a spec that wants to use it. As I said, "not exactly unspecified either". Still a standards/spec issue, just a very very small one, and not one that needs its own XEP. If you wanted PEP on MUC, that's a bit more involved, since we need to decide how the autosubscription might work, for example, and whether the smart defaults that PEP requires would be the same, different, or not there at all. I wouldn't swallow this into another dependent specification, but specify it in its own XEP. Dave.
participants (4)
-
Dave Cridland -
JC Brand -
Schimon Jehudah -
Stephen Paul Weber