[Standards] Feedback: XEP-0409: IM Routing-NG

Jonas Schäfer jonas at wielicki.name
Tue Jan 21 16:08:55 UTC 2020

On Montag, 20. Januar 2020 12:38:41 CET Daniel Gultsch wrote:
> Hi,
> I’ve read IM Routing-NG again over the last couple of days and I think
> we would be better of migrating to IM Routing-NG short term and
> deprecate Carbons instead of trying to refine its rules again and
> again (and not being able to make it Draft).


> What I like about IM Routing NG is that it is simple enough that both
> client and server implementations should be relatively easy to do
> (possibly by converting an existing mod_carbon) and that, due to its
> reflection, a client will learn the stanza-id; making the next catchup
> a lot easier.
> At this point I would like to offer to write a client side
> implementation on relativ short notice if I can get a server developer
> to do the same.

If the Prosody folks don’t have the capacity, but would have the capacity to 
mentor someone into their codebase, I’d be happy to give this a shot and also 
provide a test domain.

> One thing that I’m currently missing from IM Routing NG is the
> interaction with private MUC messages.

That’s true. I could’ve sworn that this was taken into account in earlier 
drafts, but I see a huge gap around archiving those messages in the text as 

I’m not quite sure what a sensible way to address this would be; One way I can 
think of is making the <{muc}x/> element on MUC-PMs mandatory for both sides, 
but that’ll lead to awkward interactions with legacy MUC services (which we 
could simply ignore).

Alternatively, servers already have to track muc joinedness to some extent to 
get corner cases of nickname changes etc. right, so maybe requiring that would 
be also an option.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200121/bfde68db/attachment.sig>

More information about the Standards mailing list