13 Sep
2025
13 Sep
'25
5:10 p.m.
On Tue, 9 Sept 2025 at 09:26, Goffi <goffi(a)goffi.org> wrote:
Hello,
I'm forwarding this old message, as it has never been answered, and the
author
(namely Dwd) is more active these days.
PAM is very useful in Pubsub toolbox, and I would like to see this
specification in a better state :).
Thanks!
Goffi
---------- Message transmis ----------
Objet : [Standards] XEP-0376 (Pubsub Account Management): some feedbacks
Date : vendredi 15 avril 2022, 10:41:49 heure d’été d’Europe centrale
De : Goffi <goffi(a)goffi.org>
À : standards(a)xmpp.org
Hi,
I'm currently implementing XEP-0376 both client and service side, and here
are
my feedbacks.
# Form:
- a small typo in example 1, it's "xmlns" ("s" is missing)
Thanks!
- § 3.3 Unsubscribing: even if it's obvious, an
explicit example would be
welcome for unsubscribe too
Yes, happy to do this.
- there are a lot of questions on this XEP, I'm
not sure if it's the best
location for that, IMHO discussing this on standard@ would be more
appropriate.
I think the questions are concentrated into sections 3.5 and 3.6 - these
are areas where we need this protocol to have a solution, but I didn't know
what the solution should be - at least at the time.
I think handling PEPish +notify would be really useful in this spec,
because it solves a lot of existing problems with +notify, such as it not
actually working the way you think with presence subscriptions.
- § 5 XMPP Registrar Considerations: even if it made
me smile a bit, I
don't
think that XEP (beside humourous ones) is a location for this kind of
jokes.
It's not a big deal for experimental XEPs though.
I mean, I can buy whoever's the XMPP registrar a tea cosy, if that'd help?
# Substance:
* § 3.5 auto-subscriptions and § 3.6 Filtering
I don't really understand the sentence "this implies that servers would
gradually acrue any node type which the user has had a capable client at
any
time.". Could you formulate it more clearly or at least explain it?
Let's pretend you have two clients, Foo and Bar. Foo is interested in
location, Bar is not. Foo tells the server that Location interests it
whenever it connects. Bar doesn't, of course. After a while, Foo becomes
unmaintained, or you just change your mind about it, and in any event stop
using Foo. Now you just have Bar. How does the server know it can stop
subscribing to Location at the account level?
I think we have more tools to deal with this now, since we have things like
SASL2's device identifiers and (to some extent) FAST to track what clients
are considered active.
Regarding auto-subscription, XEP-0060 is not great
itself about it as it's
mentioning "root collections" and "subsciption_depth" which are
notions of
XEP-0248 (and I don't think that there are many complete implementations
of
it, if any). But that's a topic which should be discussed on a different
thread.
I'm pretty sure there's multiple XEP-0248 implementations, but none of
them
are very widespread. But as you note, not the point at hand.
That put aside, I'm not sure that XEP-0376 should
take care at all of auto-
subscription regarding that we have already the filtering with +notify.
This is done on a per-client basis, and if client wants to get says OMEMO
public keys or user mood because it supports those features, I don't see
the
need to keep track of it at the server level.
Sure it's broadcast. To my experience this is not a problem: I use +notify
to
auto-subscribe when I want update from all users to which I'm presence
subscribed, and if I want only events for a specific user/node, I use an
explicit subscription (in which case PAM is useful).
Thus I would remove entirely § 3.5 and § 3.6, or replace them by a text
indicating that PAM service ignores them and they work as usual with
XEP-0060/
XEP-0163 auto-subscription and filtering.
This would make the whole thing simpler, but please explain me with a
clear
use-case if I'm missing something.
So - I'll say Georg's name three times and he'll appear and explain
better
- but if I want your OMEMO keys (for example) or Location, I need to
subscribe to your presence. That's how the PEP node permissions work. But
to get the +notify, you need to subscribe to my presence. So to get updated
notifications, we need a mutual presence subscription. Which is weird. This
has always been a weirdly broken bit of XMPP, and the result is that many
modern clients make an assumption about always-mutual presence
subscriptions, and so a slightly odd protocol wart has ended up influencing
the UX, which is very definitely the wrong way around.
* § 3.7 interaction with MAM
I guess events should be archived normally by MAM (at least to be sure
that
all clients receive them correctly), and I really don't see the need to
filter
them out (that's only events about explicit (un)subscription to nodes, the
traffic should not be high).
[this par below is forwarded from a follow-up email]
I was thinking about the XEP-0060 items events, indeed, not subscriptions.
I'm not really sure what ought to happen with events received while the
client is offline, and I suspect - with several years of distance - that
it's not best addressed by MAM, but this really depends on the type of node
we're talking about.
For some nodes - like microblogs - we might want all the events, whereas
for other (like user mood) we almost certainly don't.
And of course this might change on a per-client basis.
* § 3.7 interaction with MAM
I guess events should be archived normally by MAM (at least to be sure
that
all clients receive them correctly), and I really don't see the need to
filter
them out (that's only events about explicit (un)subscription to nodes, the
traffic should not be high).
Second thought: are you talking about the (un)subscribe notification as
explained at § 3.2, or XEP-0060 items events? In the later case yes,
filtering
is probably desirable: if my client doesn't handle blogging, it probably
doesn't want all the XEP-0277 items notifications.
That's it for now. It's a useful addition to pubsub in XMPP, and I hope to
see
more implementation in close future.
I think 3.5/3.6/3.7 are projects worthwhile to solve - but, we could easily
enough split those out into a different feature (or, even XEP) if it meant
people wanted to implement the rest now.
But the bulk of pubsub interaction is via PEP, so it'd be nice to address
these.
Dave.