XSF Discussion - 2017-10-30

Hi guys, while reading the MIX spec, I'm wondering how the roster item for the MIX channel is added to the user joining the channel if it's an external MIX server? Is the user's server supposed to scan the MIX join/leave stanzas in order to determine if the user successfully joined the channel?

thomas_, yes

the server needs MIX support

(that is, the users server)

you may note that the join is a command sent to the users account, not to the channel the user wants to join

see Example 22

jonasw, oh okay, I missed that bit of information

jonasw, thanks for clarifying this!

you’re welcome!

Is there a xep for, probably wording this wrong, a client sending messages to itself and other resources (mam/carbons) from other domains?

Basically spoofing from, but only to itself

Forwarding?

moparisthebest, why would you do that?

Ok so jmp.chat gives you a phone number for sending/receiving sms with xmpp

Basically thinking the same thing as a conversations plugin

i.e. a local transport for SMS <-> XMPP?

I don’t think there’s a XEP for that, but I think that’s not the worst idea.

Why not treat it as another account?

Zash, replication to other devices

moparisthebest, question though: how would you intercept messages sent to those SMS JIDs?

essentially you want a component, but only for the account.

Ie my phone gets SMS from 5555, I see it in conversations and all my other xmpp clients as from 5555@some.specific.fake.domain

If I respond in conversations it sends it over sms, if I respond in other clients conversations sends sms when it gets the carbon?

Oh dear, is this leading to an argument for uploading into your archive?

... like 136 has? ✏

So this would need a server plugin too

moparisthebest, that carbons trick there would kindof work, but it would also create some strain on the server for error handling of stanzas it doesn’t even need to s2s-route

Basically to allow a client to spoof from for a certain domain but only for that account

But, there's the forwarding xep (used for encapsulation by carbons and mam)

That might work have a xep number handy?

297 maybe? (wild guess)

297

https://xmpp.org/extensions/xep-0297.html

Bunneh: xep forwarding

Zash: XEP-0297: Stanza Forwarding (Standards Track, Draft, 2013-10-02) See: https://xmpp.org/extensions/xep-0297.html

it doesn’t magically give you the kind of handling you want though

Because yea I'd want carbons and mam etc

it only defines an encapsulation protocol (as re-used by carbons etc.)

This would work as a separate component of course but that had issues like this

Not encrypted, different connection, separate component for each account etc etc

The architecture with transports as server components kinda breaks down when clients are also transports

to have things well defined, you have to use this on one account only anyways

Yes

so user components are an interesting concept

like a component, but the domain is only visible to the user

(and other users may have the same domain)

Yes that

but that’s not specified yet

Forwarding wouldn't work I think

No real great way to respond and such I think

Can clients send carbons to other resources?

yes, but those must ignore them

Bunneh: xep carbons

moparisthebest: XEP-0280: Message Carbons (Standards Track, Proposed, 2017-02-16) See: https://xmpp.org/extensions/xep-0280.html

You probably want to invent some new protocol

There /was/ that {xep remote control}

Zash: XEP-0146: Remote Controlling Clients (Informational, Active, 2006-03-23) See: https://xmpp.org/extensions/xep-0146.html

I'll have to abuse gajims XML console later and play around

I feel like maybe carbons from other resources would be safe right?

Broadcast is the kind of thing you want your server to help you with

I think jonasw 's description is closest to what I'm looking for, user or client components

True Zash

Hmm then you could use the phone's dialer to jingle call through it too...

Leave your cell at home and sms/call through it wherever you have an xmpp client and internet

Anyone interested in working with me on something like that? :)

moparisthebest, maybe I didn't get your idea but why not using a transport with <phonenumber>@transport for each phone contact?

I think it could be as simple as the server advertising that the client can send messages to itself from *@*.somedomain then the server not doing s2s for *. somedomain and allowing that

thomas_: the transport is per user account and runs on one of their clients is why

moparisthebest, why does the transport run on a client?

It's a phone?

thomas_: conversations on your phone is the only thing with access to send/recieve sms

You wanna pretend that the native SMS functionality is a component

Oh, I though you have a device with your SIM card somewhere and want to connect via XMPP

thomas_, the component protocol is insecure

that’s one reason why you don’t want to run that $somewhere

second, if you don’t run your own server / the server is shared with multiple entities, you don’t want them to access your transport

Plus it's per server not per account

that’s what I mean, essentially

ah okay

Hmm you could run a component that you register with and send arbitrary messages to your own account through...

Then no server changes needed

kind of an echo component? ✏

that would work.

Essentially yes

a meta-component

Done extra rules but yea

a component to create per-user components :D

Some*

that’s quite fancy, actually, because you get stream management etc. "for free"

Yep I like simple

You could also register a normal account and send yourself messages via that

Zash, you’d need one account for each phone number you text?

Zash: no you need from to be multiple accounts based on phone number

Yes

Abuse resources! :D

resource abuse will wreak havoc with message routing 2.0

Can't add them to your contacts though

(also, one connection per peer, really? ;-))

With jmp.chat it's phonenumber@cheogram.com

moparisthebest, you should write a XEP for this echo component with the given use-case.

This component could even be public and require no local server support

the only thing I don’t like about it is that you can only have N components per user, where N is the number of server-side components :/

it doesn’t even need to be a component

you should probably not reference any component-specific protocol

only that it is a domain-JID entity which implements that protocol

which means that servers could also offer you *@*.local for example.

I'll give it a try jonasw , I'm the type to code/test first and write specs later :)

right

happy to proof-read if you want to before submission.

<message to=self><forwarding><message from="number@actually.sms.invalid" to="self"><body>hi</body><////>

Thing gets wrapped in seven layers of carbons and forwarded to all your clients.

Zash, that’s the easy part -- the tricky part is to be able to send messages to number@actually.sms.invalid

jonasw: <message to="me@self/phone"><forward><message to="number@sms"><body>HELLO<///>

But being able to do component and avoid lua or erlang makes it something I can do myself at least (sorry server devs...)

Add some caps and call it a day!

jonasw: does your Python lib do components?

I've only ever used the ancient first Python lib for components

no

Zash, right

that’d work but ...

but it would also require client support on the clients which are not the component

Yes

simple clients!

(also, I’m not entirely sure how serious your proposals are)

I don't think clients are simple anymore

jonasw: On a scale from dead serious to trolling? Usually somewhere in the middle.

> But being able to do component and avoid lua or erlang makes it something I can do myself at least pussy detected

jonasw: "That's my secret. I'm always joking." :D

zinid: I prefer the word 'sane' :)

moparisthebest: writing in python is sane?

not writing everything in Lua is sane???

Hoping to use rust if there are component libs, but yea point taken about Python :)

moparisthebest, there is xmpprs or so

not sure if it can do components

Yea I've used it for a client

yeah, rust...

the component will be dead simple in any language

the client will have to decide whether or not to send new SMS on carbon/mam etc, ew

next ridiculous question, is there anything defined in jingle for one resource to make a call through another resource?

same account, resource A is connected to a phone line, resource B is not

B wants to make a phone call, any current way to do that?

I don't think there's anything special about that

The problem with Jingle is that it works exactly like that

One arbitrary JID calls another arbitrary JID.

As opposed to one account calling another account.

that's not exactly what I mean though

So I don't think anything in the Jingle spec prevents two resources of the same account from establishing calls

not a call between A and B, a call between B and +1-555-555-5555 THROUGH A

so the jingle session would be between A and B, but A would be, uh, forwarding through the PSTN

There's a thing, hold on

-xep dtmf

Zash: XEP-0181: Jingle DTMF (Standards Track, Deferred, 2009-10-02) See: https://xmpp.org/extensions/xep-0181.html

lovely

so you’d start a jingle call through A and send DTMF to actually dial a number

ha you could I guess, maybe, not sure what android phone API looks like

Like, whatever it's called when you call somewhere and go into an answering machine that you type more numbers into to get passed on

moparisthebest, but I don’t think you need special protocol for that. you’d contact the gateway client at its pseudo-JID at the component and it would re-write the jingle connection negotiation messages accordingly so that the call is routed through it

Maybe you need to find/invent some way to tell the other end to proxy you

But, isn't that basically how PSTN works (or used to, way back in the analog era)?

don’t need to, it’s already proxied through the pseudo-JID magic

hmm not sure I kind of imagined them seperately

that would probably be best, have to think about it

-xep rayo

Zash: Multiple matches: Rayo https://xmpp.org/extensions/xep-0327.html Rayo Fax https://xmpp.org/extensions/xep-0342.html Rayo CPA https://xmpp.org/extensions/xep-0341.html Rayo Clustering https://xmpp.org/extensions/xep-0349.html

Uh, maybe anything in those have anything usable?

I’m not sure if I was understood

hmm possibly

jmp.chat neatly bypasses all this by 'if you want voice, connect to this SIP account:'

Neatly solve this problem by putting your phone next to your server and writing a component that connects over USB or somesuch :)

anyway one step at a time, SMS is much simpler

if I'm sending a message to a JID but need to encode 1 seperate piece of info, what's the best way to do that?

<foo/>?

a new element inside <message> or inside <body> or a new attribute on something?

NOT INSIDE BODY

ahem

never ever mix elements and text

yea but where and what should I do about namespaces?

(unless you’re doing XHTML or something)

"choose" a namespace

don’t add attributes to any existing elements, make your own element and put it an <message/>

but inside message is fine?

think about what happens if your peer doesn’t understand it

great thanks

what's the precedent for naming these things with multiple words, for example, <echo-from xmlns="urn:xmpp:echo-self">+15555555555</echo-from> ?

Metadata in attributes and content in text nodes :)

Most things are just one word afik

ah so I could go

<echo xmlns="urn:xmpp:echo-self" from="+15555555555" />

looks cleaner anyhow probably

and urn:xmpp is technically not something anyone can just use without going through the XSF

yea I'll make something else for testing

Zash, sure you can, it just breaks things.

(or may break due to conflict etc.)

Do we have any recommendations for these things, or do they exist anywhere?

yea that's what I was asking about

doesn't matter at this point but would be nice to see

Stuff like {urn:example:foo}foo usually annoy me slightly

*ahem* {http://jabber.org/protocol/pubsub}pubsub/action *hrr*

moparisthebest, I’m not entirely sure what you need that element for, but I suggest that you orient your wire-format on what XEP-0280 (Message Carbons) does

at least for the communication between the component and the user component implementation

(not for component<->normal resources)

I think this might be the only thing the server component needs

basically that would mean 'send me this message from that JID'

the component ignores everything else, carbons handles that

so the user component implementation on the phone client would send <message to=component><body>...</body><echo xmlns="..." ...>...</echo></message>?

yes

please wrap the message once

I was going to include the no-copy and no-carbons stuff

no

why wrap it so I wouldn't have to do that?

because it makes things explicit

something like <message><echo send-from="..."><forwarded><message ...>...</message></forwarded></echo></message>

re-uses XEP-0297 even though the naming is a bit off

has the advantage that this won’t be picked up by MAM or carbons

(because of type="normal" on the outer and no <body/>)

jonasw, that seems harder

right now the entire logic of the component is this:

if msg.find('{urn:moparisthebest:echo-self}echo') is not None: to = msg['to'] msg['to'] = msg['from'] msg['from'] = to msg.send()

done

moparisthebest, given that <no-store/> and <no-copy/> are from XEP-0334 which is in limbo since Council rejected its advancement, it seems like the more future-proof approach

ignores everything without <echo>, if it has echo, swaps to/from and sends it back?

that’s not what you want though

what you’re doing requires all involved clients to know the echo protocol

I’d avoid that

no it's working exactly right without any clients knowing it

except the one sending it that is

(currently gajim xml console)

how would I reply to a message from somenumber@thatcomponent.domain?

moparisthebest, You're not an SDO - don't use "urn:...". Just use an http scheme URI to your domain. Or an xmpp scheme one, like your jid.

what is an SDO?

moparisthebest, For example, I could use xmlns="xmpp:dwd@dave.cridland.net/some-proto"

jonasw, In this context, a Standards Development Organisation

ah

before today I've happily lived completely ignoring xmlns

oh how I yearn for 10 minutes ago

jonasw, You're an XSF Editor, right? I noticed some of "my" XEPs are using old contact info - what's the best way to update that?

moparisthebest, They're strings. Mostly without meaning, except the ones that do have meaning. But we're supposed to know how to use them properly.

dwd, which ones exactly?

or rather: have you checked whether your info in xep.ent is up-to-date? if it isn’t, that’d be a great way to start.

also, how dare dwd assume I'm not a Standards Development Organization :)

jonasw, I happened to notice XEP-0286, but there might be others.

moparisthebest, Actually the best definition I have for an SDO is whether they can register a urn prefix.

dwd, https://github.com/xsf/xeps/blob/master/xep.ent#L924 is this up-to-date?

:'(

jonasw, Yes.

dwd, okay, will update the XEPs not using that entity definition.

jonasw, Thanks. Much appreciated.

(there are two)

(XEP-0376 is the other one)

moparisthebest, I was thinking something like this: <!-- User component to Component --> <message to="component.domain" from="account@domain/user-component-client"> <echo xmlns="foo"> <forwarded> <message from="phonenumber@component.domain" to="account@domain" id="xyz"> <body>Hi there!</body> </message> </forwarded> </echo> </message> <!-- Component to account --> <message from="phonenumber@component.domain" to="account@domain" id="xyz"> <body>Hi there!</body> </message> <!-- Some client from the account replies --> <message from="account@domain/resource" to="phonenumber@component.domain" id="abc"> <body>Hi yourself!</body> </message> <!-- Component to User component --> <message from="component.domain" to="account@domain/user-component-client"> <echo xmlns="foo"> <forwarded> <message from="account@domain/resource" to="phonenumber@component.domain" id="abc"> <body>Hi yourself!</body> </message> </forwarded> </echo> </message>

this has the advantage that the protocol between user component and the server-side component is explicit

the interaction between the component and other clients is like with any other domain

which is nice

wrapping the actual payload saves it from being archived etc.

then the component has a state

moparisthebest, why would it need state for that?

and there is, registering stuff involved

<!-- Component to User component -->

right, it needs to know that anyways?

I don't think so

how would it not need that?

it does have to know where to deliver messages sent by other clients to the component?

the user's server handles it for them, with carbons

and/or mam etc

ugh, you’ll simply ignore them and rely on carbons? :/

I see

exactly :)

I don’t like that approach :)

it relies on carbon rules which are super-foggy

it has the advantage of the component being potentially the simplest xmpp component of all time

I can also see the use-case of <iq/> and other stanza types for user components.

but it’s not really re-usable

true it only works for carbon'd things

still that seems like an additional xep for non-message things that don't get carboned, might as well keep this super simple

but consistency.

does message have to have a body ?

no

carbons for example do not have bodies

I don't know if it's sleekxmpp or prosody, but one is refusing to deliver it

care to show some XML traces?

no errors, just doesn't go through until I add a body

I suspect that might not be the only difference. there are a lot of use-cases for non-body messages.

(chat state notifications for example)

no I'm pasting into the gajim xml console and that's the only difference :)

how are you trying to receive the message?

it's sleekxmpp

if I turn on COMM level logging it logs it, but doesn't send it to my app

well that's a bug I'm not dealing with now

will mess with <forwarded> later meh