[Standards] Inbox and Other Stories
flo at geekplace.eu
Mon Jun 24 19:43:17 UTC 2019
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'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
> 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.
> 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?
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.
Additionally, if we design it well, then this allows to perform lookups
- 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 618 bytes
Desc: OpenPGP digital signature
More information about the Standards