XEP-0163 (Personal Eventing Protocol) Allow multiple publishers; XEP-0045 (Multi-User Chat) Allow PEP
23 Sep
2024
23 Sep
'24
1:26 a.m.
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
23 Sep
23 Sep
2:28 a.m.
On Mon, 23 Sept 2024 at 08:27, Schimon Jehudah <sch(a)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
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.
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.
3:59 a.m.
Greetings, Dave!
Thank you for your respond!
Please see further comments.
On Mon, 23 Sep 2024 09:28:49 +0100
Dave Cridland <dave(a)cridland.net> wrote:
Is there any document about POJ?
On Mon, 23 Sept 2024 at 08:27, Schimon Jehudah
<sch(a)fedora.email>
wrote:
Is there any document about MEP?
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
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).
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.
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
11:35 p.m.
On 23 September 2024 11:59:43 GMT+02:00, Schimon Jehudah <sch(a)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
24 Sep
24 Sep
2:39 a.m.
On Tue, 24 Sep 2024 07:35:54 +0200
JC Brand <lists(a)opkode.com> wrote:
On 23 September 2024 11:59:43 GMT+02:00, Schimon
Jehudah
<sch(a)fedora.email> wrote:
Thank you, JC, for the reference.
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.
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
25 Sep
25 Sep
8:43 a.m.
On Tue, 24 Sept 2024 at 09:39, Schimon Jehudah <sch(a)fedora.email> wrote:
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.
On Tue, 24 Sep 2024 07:35:54 +0200
JC Brand <lists(a)opkode.com> wrote:
I'd completely forgotten that existed. :-)
On 23 September 2024 11:59:43 GMT+02:00, Schimon
Jehudah
<sch(a)fedora.email> wrote:
Thank you, JC, for the reference.
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.
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.
5 Oct
5 Oct
12:12 p.m.
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(a)cridland.net> wrote:
On Tue, 24 Sept 2024 at 09:39, Schimon Jehudah
<sch(a)fedora.email>
wrote:
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.
On Tue, 24 Sep 2024 07:35:54 +0200
JC Brand <lists(a)opkode.com> wrote:
I'd completely forgotten that existed. :-)
On 23 September 2024 11:59:43 GMT+02:00, Schimon
Jehudah
<sch(a)fedora.email> wrote:
Thank you, JC, for the reference.
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.
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.
27 Oct
27 Oct
12:51 p.m.
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 <sch(a)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(a)cridland.net> wrote:
On Tue, 24 Sept 2024 at 09:39, Schimon Jehudah
<sch(a)fedora.email>
wrote:
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 On Tue, 24 Sep 2024 07:35:54 +0200
JC Brand <lists(a)opkode.com> wrote:
I'd completely forgotten that existed. :-)
On 23 September 2024 11:59:43 GMT+02:00, Schimon
Jehudah
<sch(a)fedora.email> wrote:
>Is there any document about MEP?
Yes, there's this:
https://xmpp.org/extensions/xep-0316.html
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.
23 Sep
23 Sep
4:14 a.m.
I forgot to answer to a matter.
On Mon, 23 Sep 2024 09:28:49 +0100
Dave Cridland <dave(a)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
7:51 a.m.
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.
8:39 a.m.
On Mon, 23 Sept 2024 at 14:52, Stephen Paul Weber <singpolyma(a)singpolyma.net>
wrote:
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.
I suggest to
enable PEP nodes for MUC JIDs too.
This isn't a standards/spec issue,
21
days inactive
55
days old
11 comments
4 participants
participants (4)
-
Dave Cridland -
JC Brand -
Schimon Jehudah -
Stephen Paul Weber