Version 0.2.0 of XEP-0503 (Server-side spaces) has been released.
Abstract:
This document defines an XMPP protocol to cluster several groupchat
rooms together.
Changelog:
Rewrite using pubsub semantics. (nc)
URL: https://xmpp.org/extensions/xep-0503.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
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)
- § 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
I have setup the XSF membership application Wiki page for the
application period Q4-2025
Applications are encouraged from developers and others who are involved
in the Jabber/XMPP community.
To apply, create a page about yourself on the Wiki here:
https://wiki.xmpp.org/web/Membership_Applications_Q4_2025
If you don't have a wiki account, send your full name, preferred
nickname and email address to me or one of the other Sysops:
https://wiki.xmpp.org/web/Sysops
When you need help with your application then don't hesitate to contact
me directly
Apply now!!!
Thanks,
Alex
Good day.
About
=====
I have recently suggested at project Movim to add navigational
instructions to Atom entries (i.e. posts).
I am still experimenting it, and it currently seems useful.
Technicality
============
The idea is realized in a similar fashion to the classification of
comments node with rel='replies' and title='comments'.
https://xmpp.org/extensions/xep-0277.xml#comments
Navigation
==========
I advise to enable navigational instructions with rel='navigation' and
title='previous' and title='proceed', and perhaps also title='index'.
At the bottom of this page there are proceed or previous links to
navigate and are generated from the instructions proposed above.
https://journal.woodpeckersnest.eu/posts/2024-11-05-xmpp-as-the-internet/
Advantages
==========
Navigational instructions would conveniently facilitate the creation of
a CMS even over a single PEP node, without a compulsory need of having
a PubSub service with multiple nodes to do so, by relating from post to
post from within each posts.
Navigational instructions would also incentivise the creation of
articles that are segmented into parts of a series of posts, and
portability thereof.
Kind regards,
Schimon
Good afternoon.
I am interested to know of a valid URI for XEP-0248.
Would this be a valid URI?
xmpp:comments.hostname?;node=node_collection/node_leaf;item=item_id
Kind regards,
Schimon
Good day.
Previously, we have discussed about comments node over PEP.
https://xmpp.org/extensions/xep-0277.html#comment_add
> Note: A comments node SHOULD be located at a generic
> publish-subscribe node that is not attached to a user's IM account,
> but MAY be located at a personal eventing (PEP) node.
While PEP nodes are only accessible to the account owner, it is desired
to have people to post items to PEP comments node.
I would advise to utilize XLink as a mean of references to moderators
and by that, it would be possible to create a uniform comment
moderation mechanism for posting comments of Atom Over XMPP (XEP-0277
and XEP-0472).
https://www.w3.org/TR/xlink11/
Kind regards,
Schimon
Good day. Ladies and Gentlemen.
I am exploring the specification XLL (XLink).
XLink (XML Linking Language) allows to define links within an XML
document;
It provides a standard way for specifying relationships between
resources, such as documents or elements in those documents; and
This can be helpful when working with large and complex data sets, where
maintaining connections between different parts becomes crucial.
An excerpt from an article of Mr. Hank Simon.
> XLink, a language that dramatically extends the capabilities of
> linking documents well beyond the abilities of mere HTML internet
> pages.
> XLink enables bidirectional linking, multiway linking, and
> out-of-line linking. Bidirectional linking is simply the idea of
> visiting an internet page and returning to the starting point by
> clicking on the same link again. Multiway linking is the
> implementation of Web rings by using XLink.
I was wondering whether XLink could be utilized for forwarded messages
and perhaps for other purposes or situations that may require more
elaborated solutions such as bidirectional linking.
Kind regards,
Schimon
