[Standards] Inbox and Other Stories

Dave Cridland dave at cridland.net
Mon Jun 24 21:17:55 UTC 2019

On Mon, 24 Jun 2019 at 20:43, Florian Schmaus <flo at geekplace.eu> wrote:

> On 18.06.19 13:05, Dave Cridland wrote:
> > On Mon, 17 Jun 2019 at 17:09, Florian Schmaus <flo at geekplace.eu
> > <mailto:flo at geekplace.eu>> wrote:
> >
> >     The solution back then was PEP, which is based on PubSub. Why would
> you
> >     want to build a publish-subscribe mechanism not on XEP-0060 PubSub?
> >
> >
> > It's possible to put everything into XEP-0060 - indeed, XEP-0207
> > discusses exactly this, and shows examples of putting the roster and
> > presence notifications into PubSub.
> If XEP-0207 tries to deliver a message within a humorous XEP, then I am
> not sure which message that is. Of course no one would seriously want to
> base the Roster on PubSub/PEP at this stage. But if we where to
> completely design it from scratch in a clean room scenario, then using
> existing building blocks is always an option (and IMHO a desirable one).
I don't think you mean clean room, do you? In any case, it's not clear that
you'd use PEP to build a roster on (especially given that PEP depends on
the roster).

At best, you'd have to have a code-as-a-node PEP node for the roster.
That's achievable, but I suspect it's a bit of a pain in most servers.

> > I'm not going that route because the additional semantics of the roster
> > are useful here - but if you're open to replacing the roster entirely
> > with a more scalable design, I'm totally open to that.
> I am curious what additional semantics that are, besides the coupling of
> some data to a JID and roster pushes (which would probably do more harm
> than good).
The roster is a fundamental control structure within XMPP, and is also well
understood. The semantics that exist are that this is a list of contacts -
we tend to use it for contacts for which we have a presence subscription,
but note that the original design - still available - allows one to insert
any Jid at all into the roster manually. The subscription state is simply
some automatically tracked metadata. There is also other metadata (name,
groups) which is traditionally under the user's direct and exclusive
control (though in practise, not always).

As such, I think it's a natural place to consider adding more metadata.

You're quite right, of course, that we cannot simply force additional data
in without careful thought.

> >     What about entries which are not in the roster?
> >
> >
> > Put them in, and mark them as ad-hoc entries.
> This could potentially cause UX issues for users with a lot of
> non-roster chats and clients unaware of the marker.
Not a problem.

Firstly, we understand how to do extensions etc. Secondly, even if we
didn't, the roster can contain arbitrary jids. At worst, this would be
additional clutter (and at best, it'd give users ephemeral entries in the
roster for ad-hoc chats).

>     What about entities
> >     which are not interested in the additional roster metadata?
> >
> >
> > This one is really easy - we really do know how to negotiate extensions
> > these days. If a client doesn't want to know, we'll just not tell it.
> And how does it affect roster versioning? Will there be two versions of
> the roster, one for the clients which did not request the additional
> metadata and one for the clients which did? Is there a roster push every
> time some metadata changes? If so, does it contain all the other metadata?

Lots of questions, so lots of answers:

a) For additional jids, it actually doesn't matter how it affects roster
versioning. If a client asks for version X of the roster without ad-hoc
entries, and there are subsequent changes which only affect the non-visible
roster entries, the client will see no difference. If a change happens to
move the roster version to Y, it'll just work.

b) Hence, probably not. But that said, servers can do so if they wish, I
don't think it matters.

c) Not for the metadata we've been discussing (unread, last message, etc)

d) Again, I don't think we include most metadata in the roster pushes.

This all said, I have to admit I think that outside some very specialist
cases, we shouldn't be worrying over roster versioning beyond the "no
change" case. Perhaps that view might change if we consider adding
substantially to the roster though.

> I do not believe that this is a desirable approach for the same reason I
> don't want MIX channels in the roster.
> Instead we should probably consider creating a generic way to retrieve
> (and store) arbitrary metadata linked to (bare) JIDs. That metadata
> could include unread count, which would be server generated. It could
> act as 'kind' marker for bare JIDs, marking e.g. MIX channels. And could
> also be used to store user-provided per-jid settings.
So you're suggesting that rather than use the roster - a listing of jids
and various metadata, some of which is user controlled (and note the
"arbitrary XML children of roster item" discussion back in RFC 6121 days)
and some of which is server managed - we should use a newly designed
generic method of the same?

> Additionally, if we design it well, then this allows to perform lookups
> like:
> - Return all my MIX channels bare JIDs
> - Return N bare JIDs with an unread count >0 sorted by last activity
> - Return N bare JIDs with an unread count >0 sorted by most unread messages
> I fear that if we would bend the roster into such a thing, we will end
> up with a very complicated protocol, which causes error prone
> implementations.
Wherever we put what you're describing, we'll end up with the same
complexity, I think by definition.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190624/e35fe97b/attachment.html>

More information about the Standards mailing list