-
thomas_
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?
-
jonasw
thomas_, yes
-
jonasw
the server needs MIX support
-
jonasw
(that is, the users server)
-
jonasw
you may note that the join is a command sent to the users account, not to the channel the user wants to join
-
jonasw
see Example 22
-
thomas_
jonasw, oh okay, I missed that bit of information
-
thomas_
jonasw, thanks for clarifying this!
-
jonasw
you’re welcome!
-
moparisthebest
Is there a xep for, probably wording this wrong, a client sending messages to itself and other resources (mam/carbons) from other domains?
-
moparisthebest
Basically spoofing from, but only to itself
-
Zash
Forwarding?
-
jonasw
moparisthebest, why would you do that?
-
moparisthebest
Ok so jmp.chat gives you a phone number for sending/receiving sms with xmpp
-
moparisthebest
Basically thinking the same thing as a conversations plugin
-
jonasw
i.e. a local transport for SMS <-> XMPP?
-
jonasw
I don’t think there’s a XEP for that, but I think that’s not the worst idea.
-
Zash
Why not treat it as another account?
-
jonasw
Zash, replication to other devices
-
jonasw
moparisthebest, question though: how would you intercept messages sent to those SMS JIDs?
-
jonasw
essentially you want a component, but only for the account.
-
moparisthebest
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
-
moparisthebest
If I respond in conversations it sends it over sms, if I respond in other clients conversations sends sms when it gets the carbon?
-
Zash
Oh dear, is this leading to an argument for uploading into your archive?
-
Zash
... like 136 hasq✎ -
Zash
... like 136 has? ✏
-
moparisthebest
So this would need a server plugin too
-
jonasw
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
-
moparisthebest
Basically to allow a client to spoof from for a certain domain but only for that account
-
Zash
But, there's the forwarding xep (used for encapsulation by carbons and mam)
-
moparisthebest
That might work have a xep number handy?
-
Zash
297 maybe? (wild guess)
-
jonasw
297
-
jonasw
https://xmpp.org/extensions/xep-0297.html
-
Zash
Bunneh: xep forwarding
-
Bunneh
Zash: XEP-0297: Stanza Forwarding (Standards Track, Draft, 2013-10-02) See: https://xmpp.org/extensions/xep-0297.html
-
jonasw
it doesn’t magically give you the kind of handling you want though
-
moparisthebest
Because yea I'd want carbons and mam etc
-
jonasw
it only defines an encapsulation protocol (as re-used by carbons etc.)
-
moparisthebest
This would work as a separate component of course but that had issues like this
-
moparisthebest
Not encrypted, different connection, separate component for each account etc etc
-
Zash
The architecture with transports as server components kinda breaks down when clients are also transports
-
jonasw
to have things well defined, you have to use this on one account only anyways
-
moparisthebest
Yes
-
jonasw
so user components are an interesting concept
-
jonasw
like a component, but the domain is only visible to the user
-
jonasw
(and other users may have the same domain)
-
moparisthebest
Yes that
-
jonasw
but that’s not specified yet
-
moparisthebest
Forwarding wouldn't work I think
-
moparisthebest
No real great way to respond and such I think
-
moparisthebest
Can clients send carbons to other resources?
-
jonasw
yes, but those must ignore them
-
moparisthebest
Bunneh: xep carbons
-
Bunneh
moparisthebest: XEP-0280: Message Carbons (Standards Track, Proposed, 2017-02-16) See: https://xmpp.org/extensions/xep-0280.html
-
Zash
You probably want to invent some new protocol
-
Zash
There /was/ that {xep remote control}
-
Bunneh
Zash: XEP-0146: Remote Controlling Clients (Informational, Active, 2006-03-23) See: https://xmpp.org/extensions/xep-0146.html
-
moparisthebest
I'll have to abuse gajims XML console later and play around
-
moparisthebest
I feel like maybe carbons from other resources would be safe right?
-
Zash
Broadcast is the kind of thing you want your server to help you with
-
moparisthebest
I think jonasw 's description is closest to what I'm looking for, user or client components
-
moparisthebest
True Zash
-
moparisthebest
Hmm then you could use the phone's dialer to jingle call through it too...
-
moparisthebest
Leave your cell at home and sms/call through it wherever you have an xmpp client and internet
-
moparisthebest
Anyone interested in working with me on something like that? :)
-
thomas_
moparisthebest, maybe I didn't get your idea but why not using a transport with <phonenumber>@transport for each phone contact?
-
moparisthebest
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
-
moparisthebest
thomas_: the transport is per user account and runs on one of their clients is why
-
thomas_
moparisthebest, why does the transport run on a client?
-
Zash
It's a phone?
-
moparisthebest
thomas_: conversations on your phone is the only thing with access to send/recieve sms
-
Zash
You wanna pretend that the native SMS functionality is a component
-
thomas_
Oh, I though you have a device with your SIM card somewhere and want to connect via XMPP
-
jonasw
thomas_, the component protocol is insecure
-
jonasw
that’s one reason why you don’t want to run that $somewhere
-
jonasw
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
-
moparisthebest
Plus it's per server not per account
-
jonasw
that’s what I mean, essentially
-
thomas_
ah okay
-
moparisthebest
Hmm you could run a component that you register with and send arbitrary messages to your own account through...
-
moparisthebest
Then no server changes needed
-
jonasw
simj✎ -
jonasw
kind of an echo component? ✏
-
jonasw
that would work.
-
moparisthebest
Essentially yes
-
jonasw
a meta-component
-
moparisthebest
Done extra rules but yea
-
jonasw
a component to create per-user components :D
-
moparisthebest
Some*
-
jonasw
that’s quite fancy, actually, because you get stream management etc. "for free"
-
moparisthebest
Yep I like simple
-
Zash
You could also register a normal account and send yourself messages via that
-
jonasw
Zash, you’d need one account for each phone number you text?
-
moparisthebest
Zash: no you need from to be multiple accounts based on phone number
-
moparisthebest
Yes
-
Zash
Abuse resources! :D
-
jonasw
resource abuse will wreak havoc with message routing 2.0
-
moparisthebest
Can't add them to your contacts though
-
jonasw
(also, one connection per peer, really? ;-))
-
moparisthebest
With jmp.chat it's phonenumber@cheogram.com
-
jonasw
moparisthebest, you should write a XEP for this echo component with the given use-case.
-
moparisthebest
This component could even be public and require no local server support
-
jonasw
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 :/
-
jonasw
it doesn’t even need to be a component
-
jonasw
you should probably not reference any component-specific protocol
-
jonasw
only that it is a domain-JID entity which implements that protocol
-
jonasw
which means that servers could also offer you *@*.local for example.
-
moparisthebest
I'll give it a try jonasw , I'm the type to code/test first and write specs later :)
-
jonasw
right
-
jonasw
happy to proof-read if you want to before submission.
-
Zash
<message to=self><forwarding><message from="number@actually.sms.invalid" to="self"><body>hi</body><////>
-
Zash
Thing gets wrapped in seven layers of carbons and forwarded to all your clients.
-
jonasw
Zash, that’s the easy part -- the tricky part is to be able to send messages to number@actually.sms.invalid
-
Zash
jonasw: <message to="me@self/phone"><forward><message to="number@sms"><body>HELLO<///>
-
moparisthebest
But being able to do component and avoid lua or erlang makes it something I can do myself at least (sorry server devs...)
-
Zash
Add some caps and call it a day!
-
moparisthebest
jonasw: does your Python lib do components?
-
moparisthebest
I've only ever used the ancient first Python lib for components
-
jonasw
no
-
jonasw
Zash, right
-
jonasw
that’d work but ...
-
jonasw
but it would also require client support on the clients which are not the component
-
Zash
Yes
-
jonasw
simple clients!
-
jonasw
(also, I’m not entirely sure how serious your proposals are)
-
Zash
I don't think clients are simple anymore
-
Zash
jonasw: On a scale from dead serious to trolling? Usually somewhere in the middle.
-
zinid
> But being able to do component and avoid lua or erlang makes it something I can do myself at least pussy detected
-
Zash
jonasw: "That's my secret. I'm always joking." :D
-
moparisthebest
zinid: I prefer the word 'sane' :)
-
zinid
moparisthebest: writing in python is sane?
-
Zash
not writing everything in Lua is sane???
-
moparisthebest
Hoping to use rust if there are component libs, but yea point taken about Python :)
-
jonasw
moparisthebest, there is xmpprs or so
-
jonasw
not sure if it can do components
-
moparisthebest
Yea I've used it for a client
-
zinid
yeah, rust...
-
moparisthebest
the component will be dead simple in any language
-
moparisthebest
the client will have to decide whether or not to send new SMS on carbon/mam etc, ew
-
moparisthebest
next ridiculous question, is there anything defined in jingle for one resource to make a call through another resource?
-
moparisthebest
same account, resource A is connected to a phone line, resource B is not
-
moparisthebest
B wants to make a phone call, any current way to do that?
-
Zash
I don't think there's anything special about that
-
Zash
The problem with Jingle is that it works exactly like that
-
Zash
One arbitrary JID calls another arbitrary JID.
-
Zash
As opposed to one account calling another account.
-
moparisthebest
that's not exactly what I mean though
-
Zash
So I don't think anything in the Jingle spec prevents two resources of the same account from establishing calls
-
moparisthebest
not a call between A and B, a call between B and +1-555-555-5555 THROUGH A
-
moparisthebest
so the jingle session would be between A and B, but A would be, uh, forwarding through the PSTN
-
Zash
There's a thing, hold on
-
Zash
-xep dtmf
-
Bunneh
Zash: XEP-0181: Jingle DTMF (Standards Track, Deferred, 2009-10-02) See: https://xmpp.org/extensions/xep-0181.html
-
jonasw
lovely
-
jonasw
so you’d start a jingle call through A and send DTMF to actually dial a number
-
moparisthebest
ha you could I guess, maybe, not sure what android phone API looks like
-
Zash
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
-
jonasw
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
-
Zash
Maybe you need to find/invent some way to tell the other end to proxy you
-
Zash
But, isn't that basically how PSTN works (or used to, way back in the analog era)?
-
jonasw
don’t need to, it’s already proxied through the pseudo-JID magic
-
moparisthebest
hmm not sure I kind of imagined them seperately
-
moparisthebest
that would probably be best, have to think about it
-
Zash
-xep rayo
-
Bunneh
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
-
Zash
Uh, maybe anything in those have anything usable?
-
jonasw
I’m not sure if I was understood
-
moparisthebest
hmm possibly
-
moparisthebest
jmp.chat neatly bypasses all this by 'if you want voice, connect to this SIP account:'
-
Zash
Neatly solve this problem by putting your phone next to your server and writing a component that connects over USB or somesuch :)
-
moparisthebest
anyway one step at a time, SMS is much simpler
-
moparisthebest
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?
-
jonasw
<foo/>?
-
moparisthebest
a new element inside <message> or inside <body> or a new attribute on something?
-
jonasw
NOT INSIDE BODY
-
jonasw
ahem
-
jonasw
never ever mix elements and text
-
moparisthebest
yea but where and what should I do about namespaces?
-
jonasw
(unless you’re doing XHTML or something)
-
jonasw
"choose" a namespace
-
jonasw
don’t add attributes to any existing elements, make your own element and put it an <message/>
-
moparisthebest
but inside message is fine?
-
jonasw
think about what happens if your peer doesn’t understand it
-
moparisthebest
great thanks
-
moparisthebest
what's the precedent for naming these things with multiple words, for example, <echo-from xmlns="urn:xmpp:echo-self">+15555555555</echo-from> ?
-
Zash
Metadata in attributes and content in text nodes :)
-
Zash
Most things are just one word afik
-
moparisthebest
ah so I could go
-
moparisthebest
<echo xmlns="urn:xmpp:echo-self" from="+15555555555" />
-
moparisthebest
looks cleaner anyhow probably
-
Zash
and urn:xmpp is technically not something anyone can just use without going through the XSF
-
moparisthebest
yea I'll make something else for testing
-
jonasw
Zash, sure you can, it just breaks things.
-
jonasw
(or may break due to conflict etc.)
-
Zash
Do we have any recommendations for these things, or do they exist anywhere?
-
moparisthebest
yea that's what I was asking about
-
moparisthebest
doesn't matter at this point but would be nice to see
-
Zash
Stuff like {urn:example:foo}foo usually annoy me slightly
-
Zash
*ahem* {http://jabber.org/protocol/pubsub}pubsub/action *hrr*
-
jonasw
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
-
jonasw
at least for the communication between the component and the user component implementation
-
jonasw
(not for component<->normal resources)
-
moparisthebest
I think this might be the only thing the server component needs
-
moparisthebest
basically that would mean 'send me this message from that JID'
-
moparisthebest
the component ignores everything else, carbons handles that
-
jonasw
so the user component implementation on the phone client would send <message to=component><body>...</body><echo xmlns="..." ...>...</echo></message>?
-
moparisthebest
yes
-
jonasw
please wrap the message once
-
moparisthebest
I was going to include the no-copy and no-carbons stuff
-
jonasw
no
-
moparisthebest
why wrap it so I wouldn't have to do that?
-
jonasw
because it makes things explicit
-
jonasw
something like <message><echo send-from="..."><forwarded><message ...>...</message></forwarded></echo></message>
-
jonasw
re-uses XEP-0297 even though the naming is a bit off
-
jonasw
has the advantage that this won’t be picked up by MAM or carbons
-
jonasw
(because of type="normal" on the outer and no <body/>)
-
moparisthebest
jonasw, that seems harder
-
moparisthebest
right now the entire logic of the component is this:
-
moparisthebest
if msg.find('{urn:moparisthebest:echo-self}echo') is not None: to = msg['to'] msg['to'] = msg['from'] msg['from'] = to msg.send()
-
moparisthebest
done
-
jonasw
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
-
moparisthebest
ignores everything without <echo>, if it has echo, swaps to/from and sends it back?
-
jonasw
that’s not what you want though
-
jonasw
what you’re doing requires all involved clients to know the echo protocol
-
jonasw
I’d avoid that
-
moparisthebest
no it's working exactly right without any clients knowing it
-
moparisthebest
except the one sending it that is
-
moparisthebest
(currently gajim xml console)
-
jonasw
how would I reply to a message from somenumber@thatcomponent.domain?
-
dwd
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.
-
jonasw
what is an SDO?
-
dwd
moparisthebest, For example, I could use xmlns="xmpp:dwd@dave.cridland.net/some-proto"
-
dwd
jonasw, In this context, a Standards Development Organisation
-
jonasw
ah
-
moparisthebest
before today I've happily lived completely ignoring xmlns
-
moparisthebest
oh how I yearn for 10 minutes ago
-
dwd
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?
-
dwd
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.
-
jonasw
dwd, which ones exactly?
-
jonasw
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.
-
moparisthebest
also, how dare dwd assume I'm not a Standards Development Organization :)
-
dwd
jonasw, I happened to notice XEP-0286, but there might be others.
-
dwd
moparisthebest, Actually the best definition I have for an SDO is whether they can register a urn prefix.
-
jonasw
dwd, https://github.com/xsf/xeps/blob/master/xep.ent#L924 is this up-to-date?
-
moparisthebest
:'(
-
dwd
jonasw, Yes.
-
jonasw
dwd, okay, will update the XEPs not using that entity definition.
-
dwd
jonasw, Thanks. Much appreciated.
-
jonasw
(there are two)
-
jonasw
(XEP-0376 is the other one)
-
jonasw
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>
-
jonasw
this has the advantage that the protocol between user component and the server-side component is explicit
-
jonasw
the interaction between the component and other clients is like with any other domain
-
jonasw
which is nice
-
jonasw
wrapping the actual payload saves it from being archived etc.
-
moparisthebest
then the component has a state
-
jonasw
moparisthebest, why would it need state for that?
-
moparisthebest
and there is, registering stuff involved
-
moparisthebest
<!-- Component to User component -->
-
jonasw
right, it needs to know that anyways?
-
moparisthebest
I don't think so
-
jonasw
how would it not need that?
-
jonasw
it does have to know where to deliver messages sent by other clients to the component?
-
moparisthebest
the user's server handles it for them, with carbons
-
moparisthebest
and/or mam etc
-
jonasw
ugh, you’ll simply ignore them and rely on carbons? :/
-
jonasw
I see
-
moparisthebest
exactly :)
-
jonasw
I don’t like that approach :)
-
jonasw
it relies on carbon rules which are super-foggy
-
moparisthebest
it has the advantage of the component being potentially the simplest xmpp component of all time
-
jonasw
I can also see the use-case of <iq/> and other stanza types for user components.
-
jonasw
but it’s not really re-usable
-
moparisthebest
true it only works for carbon'd things
-
moparisthebest
still that seems like an additional xep for non-message things that don't get carboned, might as well keep this super simple
-
jonasw
but consistency.
-
moparisthebest
does message have to have a body ?
-
jonasw
no
-
jonasw
carbons for example do not have bodies
-
moparisthebest
I don't know if it's sleekxmpp or prosody, but one is refusing to deliver it
-
jonasw
care to show some XML traces?
-
moparisthebest
no errors, just doesn't go through until I add a body
-
jonasw
I suspect that might not be the only difference. there are a lot of use-cases for non-body messages.
-
jonasw
(chat state notifications for example)
-
moparisthebest
no I'm pasting into the gajim xml console and that's the only difference :)
-
jonasw
how are you trying to receive the message?
-
moparisthebest
it's sleekxmpp
-
moparisthebest
if I turn on COMM level logging it logs it, but doesn't send it to my app
-
moparisthebest
well that's a bug I'm not dealing with now
-
moparisthebest
will mess with <forwarded> later meh