Good day. I am in favour of standardizing storage of settings.
I am currently doing a similar thing with project Blasta, to store settings per account. Kind regards, Schimon On Tue, 09 Sep 2025 10:25:40 +0200 Goffi <[email protected]> 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 <[email protected]> > À : [email protected] > > 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) > - § 3.3 Unsubscribing: even if it's obvious, an explicit example > would be welcome for unsubscribe too > - 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. > - § 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. > > > # 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? > > 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. > > 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. > > * § 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] > > > * § 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. > > Cheers > Goffi _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
