XSF Discussion - 2020-01-12

moparisthebest, Daniel just needs to vote "on-list"

Ge0rG: XEP-0280 #6.1 now says: > A <message/> is is eligible for carbons [...] if [...] it contains payload elements typically used in IM ... and then mentions Delivery Receipts and CSN. I guess those two are meant to be examples rather than an exhaustive list? Then again, not having a definitive list might reduce the value of the guarantee #6.2 is trying to give for carbons:rules:0, no?

Apart from that, I guess this rule should mention that it still only applies to type={chat,normal}?

we should really follow up on im routing 2

Daniel, implementations are where it’s at at the moment, I think

Holger [12:22]: > ... and then mentions Delivery Receipts and CSN. I guess those two are meant to be examples rather than an exhaustive list? Then again, not having a definitive list might reduce the value of the guarantee #6.2 is trying to give for carbons:rules:0, no? You are right in those points. I'd love to have an exhaustive list of "IM payloads", but that means significant effort to compile it

Holger [12:23]: > Apart from that, I guess this rule should mention that it still only applies to type={chat,normal}? I'm not 100% sure on that.

are there any known problems with im routing ng?

I think I sent some feedback to the list, not sure if that was addressed. but it’s all theoretical at the moment

Daniel, No, although that's primarily because nobody's tried to implement it yet AFAIK. ✏

it seems way easier than adding to an endless list of rules and exceptions to carbons

or maybe i'm missing something…

it’s still a bit unclear how IM Routing 2.0 and non-2.0 domains interact

Ge0rG: I guess clients don't really want to receive carbons of outgoing 0184 receipts?

I’m not sure about that

Holger, They don't?

*requests*

Dammit.

ah, requests makes sense

Sorry.

well requests are tied to actual messages?

Still not sure I understand.

Ah.

and they are getting those anyway?

(What Daniel says)

Yeah, ignore me, thx.

We could, of course, just drop a "<traditional-im xmlns='...' this-message-is-for-im='boolean/>" into every message.

i'm not sure what i would do with copies of outgoing receipts though

but in the interest of making things simplier on the server i'd just ignore them

Yeah I can't think of a use-case either but I'd prefer to avoid even more special-casing unless there's a strong reason to do so.

Daniel: copies of outgoing receipts tell you that you don't need to send a receipt any more

Ge0rG: You're not sure whether type={chat,normal} needs mentioning or whether the rule should only apply to those? Dunno about headline but you certainly don't want to apply the rule to groupchat, no?

Daniel: I'm using that in MAM sync to reduce the number of receipts to send after sync

Holger: message types are a mess

Holger: I agree on groupchat though, and I suppose we need to make headline ephemeral+no-store

> it’s still a bit unclear how IM Routing 2.0 and non-2.0 domains interact Maybe routing ng needs to honor no-copy and maybe private (the latter would be weird). Other than that I don't see any big interop problems

Ge0rG: for mam agreed. Conversations will do that as well

For live messages you will race anyway

Daniel: yeah, can't do anything about that

Except maybe on 0198 resume

I think I might even have code for sm resume. But meh

Could it be that IM Routing 2.0 is just a tidied-up Carbons without the cCarbon wrapping?

I wouldn't optimize for that

dwd: yes. That's why writing clients and servers should be fairly easy

Recycle existing code and get rid of the rule mess

Unless I'm missing something major

Plus it always reflects

dwd: we still might need the wrapping for outgoing Carbons

Which is a good thing imho

OTOH, we don't get that in MAM

I don't think you can do without wrapping of some kind for reflection, can you?

If you require clients to include origin ids you could

Daniel: what for?

If you wanted to optimize things further you could have the reflection strip out everything but the origin id and the server added elements

Ge0rG: to identify a reflection

You can identify a reflection on from being your JID and to being a different JID

Daniel: just use message @id for that?

That could also be a message from another client

Ge0rG: same same

(but different unique Ness properties)

Daniel: your reflection will have your full JID as the from

Daniel: we can finally fix @id uniqueness for IM 2.0

(but then again im routing could also require uniqueness)

Ge0rG: will it?

Daniel: what else should be the from?

Not saying should. But it could be the bare jid

In any case I think the story is that we can make that work without wrapper

I mean we can just embed everything into forwarded, but why?

What about (direct) MUC invitations? Carbon-copy only incoming?

Holger: do invitations to self count as incoming?

Yes.

Sounds good then

FWIW, the IM-NG discussion also brought up the notion that full-jid messages are ephemeral (non-archived) by default, while bare jid messages are persistent (archived) by default

Ge0rG, any comments on the proposal? We submit it tonight.

plus flow and DebXWoody

Thanks to emus, everyone found your idea for inviting an AI-expert to the XMPP-Sprint extremely good. So we added that.

AI-expert?

We will hand in a research proposal tonight with some AI stuff. So emus idea was to add that to the planned XMPP-sprint to. jonas’

what kind of AI stuff?

I can send you the proposal in case you are interested,

I’d like a two-line summary instead

It is machine translation and language learning with XMPP clients.

ok, thanks

oneliner ;-P

Many scucess for your proposal!

Thank you very much :). emus ✏

mpparisbest

do you know something new sslh.

https://wiki.mattrude.com/SRV_records_for_XMPP_over_TLS is thia gonna gelp

help for what?

ssh show localhost in apache

neshtaxmpp: the only thing I'm gonna say about it is the option you are looking for is https://github.com/yrutschle/sslh/blob/master/doc/config.md#transparent-proxy-support and there are great docs there

moparisthebest: again the same ?

It's the only thing to say so yes

maybe we didnt sprak woth you from 1 year... and the same old depreceated doculentations that lie.

ri tbink to try tgis: https://wiki.mattrude.com/SRV_records_for_XMPP_over_TLS

is ot gonna sgow real ip ?

The official docs are correct, I'm not going to review some other docs for correctness

moparisthebest: the old are incorrect. they dont show how to 127. can be solved...

Nope they are up to date and you are wrong, now seriously I'm not discussing it anymore

i speak woth developer and he comment use iptables... it is danger... as newbies... dont want touch it

moparisthebest: you are wrong. if im writing you again ot is becouae. 127 ia not solved.

neshtaxmpp: wait lol did you just say you talked to the dev who said you must use iptables but don't want to use iptables? Hahaha

You have to if you want it to work, just like the docs I linked say, it works and I know it because it works on my machine

(that's usually not the only sign to look for proof of work though, but nvm :p)

Yes well everyone else's machines also who follows the simple instructions :)

Not people who go "but I want to skip parts and have it still work" though

moparisthebest: you are wrong, now seriously I'm not discussing it anymore

Excellent